2
votes

We used the LPC546xx family microcontroller in our project, currently, at the initial stage, we are finalizing the software and hardware requirements. The basic firmware size (which contains RTOS, 3rd party stack, library, etc...) currently is 480 KB. Now once full application developed than the size will exceed the internal flash size (512KB) and plus we needed storage which can hold firmware update image separately.

So we planned to use SPI flash (S25LP064A-JBLE, http://www.issi.com/WW/pdf/IS25LP032-064-128.pdf, serial flash memory) of 4MB\8MB to boot and run firmware.

is it recommended to run code from SPI flash? how can I map external flash memory directly to CPU memory space? Can anyone give an example that contains this memory mapping(linker script etc..) or demo application in which LPC546xx uses SPI FLASH?

1
It's not recommended to run code from any external memories, if you can avoid it. In order to run code from a serial memory, you'll need some manner of hardware support for that, or otherwise doing so will be painful - you'd have to DMA it to RAM and then run from RAM. I'd look at optimizing memory use before anything else. Or alternatively, re-program flash in run-time, which is very slow.Lundin
Up-voting question on the following grounds: 1) These things happen. As a way to save a project on the brink of collapse is may be viable. 2) In cases were highly specialised SoC:s are used, but where code requirements are exceeding limits, one may have to look at options like these.Michael Ambrus
Asking this strongly suggests that the project has gone off course; either inefficient code is wasting large amounts of the internal flash, or the wrong platform has been chosen. While there are rare exceptions, typically when "code" gets stored in an SPI NOR flash, it's either at rest there before being copied into RAM for execution, a very brief XIP stub to accomplish such a copy, or from the perspective of the hardware is actually "data" containing instructions for an interpreter rather than native code for the computation hardware itself.Chris Stratton

1 Answers

1
votes

Generally speaking it's not recommended, or differently put: the closer to the CPU the better. Both S25LP064A and LPC546xx however support XIP, so it is viable.

This is not a trivial issue as many aspects are affecting. I.e. issue is best avoided and should really have been ironed out in the planning stage. Embedded Systems are more about compromising than anything and making the right/better choices takes skill end experience.

  • Same question with replies on the NXP forum: link

512K of NVRAM is huge. There are almost certainly room for optimisations even if 3'rd party libraries are used.

On a related note this discussion concerning XIP should give valuable insight: link.

I would strongly encourage use of file-systems if not done already, for which external storage is much better suited. The further from the computational unit, the more relevant. That's not XIP and the penalty is copy-to-RAM either way you do it. I.e. performance will be slower. But in my experience, the need for speed has often-times not been thoroughly considered and at least partially greatly overestimated.

Regarding your mentioning of RTOS and FW-upgrade:

  • Unless it's a poor RTOS there's file-system awareness built in. Especially for FW upgrading (Note: you'll need room for 3 images, factory reset included), unless already supported by the SoC-vendor by some other means (OTA), it will make life much easier and less risky. If there's no FS-awareness, it can be added.

  • FW upgrade requires a lot of extra storage. More if simpler. Simpler is however also safer which especially for FW upgrades matters hugely. In the simplest case (binary flat image), you'll need at least twice the amount of memory you're already consuming.

All-in-all: I think the direction you're going is viable and depending on the actual situation perhaps your only choice.