ST or NXP

[zapta]

One nice feature in some NXP MCUs is the usb bootloader. You reset the MCU with a special pin pulled down and it mount itself on your computer as a removal USB hard drive. All it take to update the firmware is a drag and drop of the new binary file. No special cables, not special adapters, no need to install any software on the host. Perfect for field firmware updates.

[hamdi.tn]

And also, ST has free toolchain. It is called "System Workbench for STM32" (www.openstm32.org). But never have tried that. Is it worth a try? 

it's not an official ST toolchain, it's an other eclipce based IDE.
i tried it for a short time only to go back to IAR, so many problem some of them you end up heating you head into the wall, with not so good community support, starting with compatibility with st-link and that under-reset crap error , slow flashing and debugging ( few second more that IAR ), unpractical for debug ,you have to perform 4 to 5 mouse clic to enter or exit debug mode , NO RESET BUTTON ON DEBUG INTERFACE , i have to restart it all from the beginning, the target will stop running when exit debug mode , and so on.
The nice thing though is that it support standard peripheral library , so you can use same file you wrote with IAR under OpenSTM32 with no trouble, just put them on the workspace and you can compile them quite easily.

As i didn't use any NXP , can't help on this side, but for ST their uC are pretty awesome, but check erreta first. and avoid using HAL library ... the one who invented that HAL crap deserve a place in hell, standard peripheral library is much readable and easier to follow. 

[Howardlong]

You say that the flash cannot be fast enough to run at full speed. Did you ever reached the point where you must copy a function or group of functions to the RAM in order to execute them at full speed guaranteed?

In flashless devices like the LPC4370 that use external quad SPI flash, there is a proprietary and largely undocumented (publicly) flash cache/prefetch interface. Depending on what you're doing, you might suffer a 50% degradation in speed compared to running in a carefully selected RAM segment. Sometimes, you won't notice any problems at all. If you move your pinch points and ISRs to RAM segment(s) then you'll get up to zero wait state performance. I had to do this for some demo DSP code I wrote to demodulate RF direct into the chip's high speed ADC. There was barely 5% CPU left.

http://youtu.be/lD3WSCN-5u0

[MT]

QUAD SPI is interesting, also supported on new F446. I got an idea for a design that intentionally was to be used with F429 and SDRAM
but i figured after reading QUAD SPI can run code it could be done with a F446. I have to compare  ST and NXP devices.

446 quad spi spec:
• Three functional modes: indirect, status-polling, and memory-mapped
• Dual-flash mode, where 8 bits can be sent/received simultaneously by accessing twoFlash memories in parallel.
• SDR and DDR support
• Fully programmable opcode for both indirect and memory mapped mode
• Fully programmable frame format for both indirect and memory mapped mode
• Integrated FIFO for reception and transmission
• 8, 16, and 32-bit data accesses are allowed
• DMA channel for indirect mode operations
• Interrupt generation on FIFO threshold, timeout, operation complete, and access error

[nctnico]

I'd be wary of running code from RAM. Too much chance on memory corruption so you'd have to implement some kind of self-checking. Another fun fact: NXP's flash has error correction built in.

[Howardlong]

I'd be wary of running code from RAM. Too much chance on memory corruption so you'd have to implement some kind of self-checking. Another fun fact: NXP's flash has error correction built in.

Why would you get memory corruption (other than shit code!)?

[Howardlong]

QUAD SPI is interesting, also supported on new F446. I got an idea for a design that intentionally was to be used with F429 and SDRAM
but i figured after reading QUAD SPI can run code it could be done with a F446. I have to compare  ST and NXP devices.

446 spec:
• Three functional modes: indirect, status-polling, and memory-mapped
• Dual-flash mode, where 8 bits can be sent/received simultaneously by accessing twoFlash memories in parallel.
• SDR and DDR support
• Fully programmable opcode for both indirect and memory mapped mode
• Fully programmable frame format for both indirect and memory mapped mode
• Integrated FIFO for reception and transmission
• 8, 16, and 32-bit data accesses are allowed
• DMA channel for indirect mode operations
• Interrupt generation on FIFO threshold, timeout, operation complete, and access error

It's been a few months, but ISTR that the LPC4370 will run quad SPI flash at up to 102MHz DDR. While it's interesting, one problem is if you want to protect your IP. Newer "S" devices have built in AES fuses which you may be able to use in some kind of way, I don't think the chip directly supports encrypted images, you'd probably need a bootloader, sounds messy.

[MT]

Im not going to use encrypted material such as pictures so that's one stone off my chest i presume!
Thanks for the info!

[Howardlong]

One last thing about the Quad SPI is that NXP only certify a limited subset of devices, most of which I found were difficult to come by in non-production quantities.

[MT]

Ops! Do NXP mentions this officially somewhere?

[Howardlong]

Ops! Do NXP mentions this officially somewhere?

The specific devices they support are in the datasheet, but not that some of them are difficult to source!

[Howardlong]

Im not going to use encrypted material such as pictures so that's one stone off my chest i presume!
Thanks for the info!

By "images" I meant binary code blobs, not pictures!

[MT]

Yes! That was i thought you meant! Porn images!Binary code boobs! Stone off my chest!

[Jeroen3]

The spifi bootmode has seen some bugs requiring a double reset to work. Make sure you test this before sending the bom to assembler.
Generally, the lpc18/43 family has been suffering a lot of bugs in its early days. From corrupted ADC when using CAN (or vice verse can't remember) to non functional bootloaders.
Please read the errata sheet for these parts.

This does not make it a useless part. It's the only dual core arm cortex m on the market.

[Boomerang]

I'd be wary of running code from RAM. Too much chance on memory corruption so you'd have to implement some kind of self-checking. Another fun fact: NXP's flash has error correction built in.

This is from your experience or this is information from some other source? Flash ECC is reasonable, but if there is chance of memory coruption - why they don't make RAM ECC ?!? And the most interesing (for me) is how exactly runing code from RAM leads to memory coruptions?!? Is this limited to NXP or it's valid for all ARM MCUs?

[coppice]

I'd be wary of running code from RAM. Too much chance on memory corruption so you'd have to implement some kind of self-checking. Another fun fact: NXP's flash has error correction built in.

This is from your experience or this is information from some other source? Flash ECC is reasonable, but if there is chance of memory coruption - why they don't make RAM ECC ?!?

A dirty little secret (its not really secret, but few engineers bother to read the details) of the flash MCU business is that a very small percentage of flash cells will leak rapidly and loose their contents. The semiconductor physics people tell me this is unavoidable, and applies to everyone's flash MCU process. Depending on various factors, like the flash size, maybe 1 in 10k devices will suffer this failure. Some MCUs use error correcting flash to work around this issue. It adds to the cost, so only a limit number of devices are built this way. In the devices I have seen with error correcting flash, there is no similar protection for the RAM.

[andersm]

Running code from RAM is not an automatic performance improvement. Not all devices can fetch code and data from RAM simultaneously, and instead have to insert extra wait cycles.

[coppice]

Running code from RAM is not an automatic performance improvement. Not all devices can fetch code and data from RAM simultaneously, and instead have to insert extra wait cycles.

That depends on which performance parameter you are measuring. Running from RAM almost always reduces current consumption. Many of the cheat ULP demos are run from RAM, while running from flash on the same device might give very unimpressive power figures.

[Howardlong]

Running code from RAM is not an automatic performance improvement. Not all devices can fetch code and data from RAM simultaneously, and instead have to insert extra wait cycles.

In my note about running from RAM in the LPC4370, is stated "carefully selected RAM segment" for precisely this reason. 

[westfw]

Running from RAM almost always reduces current consumption.

Presumably because you can turn the flash section completely off, rather than running from RAM actually being more power efficient.
(P_ram + P_flash < P_ram + 0, for all real values of P_flash)

[coppice]

Running from RAM almost always reduces current consumption.

Presumably because you can turn the flash section completely off, rather than running from RAM actually being more power efficient.
(P_ram + P_flash < P_ram + 0, for all real values of P_flash)

During cycles when RAM isn't used its consumption in miniscule. During cycles when most types of flash are not read their consumption is very small. This isn't about the consumption from having these modules turned on. Its the energy per cycle from reading them which is important in ULP applications. The energy consumption of a read cycle from flash is bigger than the energy consumption of a read from RAM. For some ULP flash processes the ratio isn't too high. For other flash processes the difference is huge.

[hamdi.tn]

Flash news ...
Atollic just announced removal of code size limitation from Atollic TrueSTUDIO Lite. 

[nctnico]

I'd be wary of running code from RAM. Too much chance on memory corruption so you'd have to implement some kind of self-checking. Another fun fact: NXP's flash has error correction built in.

Why would you get memory corruption (other than shit code!)?

Just apply Murphy's law. It is not only bad code which can change memory but also Alpha radiation and other mayhem which is why servers usually have ECC memory. Google did quite a bit of research on this. IIRC MISRA rules also forbids to have anything in RAM which can affect program flow (like function pointers).

[coppice]

I'd be wary of running code from RAM. Too much chance on memory corruption so you'd have to implement some kind of self-checking. Another fun fact: NXP's flash has error correction built in.

Why would you get memory corruption (other than shit code!)?

Just apply Murphy's law. It is not only bad code which can change memory but also Alpha radiation and other mayhem which is why servers usually have ECC memory. Google did quite a bit of research on this. IIRC Misra also forbids to have anything in RAM which can affect program flow (like function pointers).

MISRA doesn't prohibit function calls, and the return address goes in RAM.

[nctnico]

IIRC MISRA only allows function pointers in ROM. There is a statistical probability as well. A return address is only stored briefly on the stack. A piece of code may have to reside in RAM for days up to decades so corruption due to radiation becomes a much more likely scenario (besides common problems such as stack and buffer overflows).