I’ve been experimenting with NXP’s new LPC4350 dual-core microcontroller recently. It’s quite an intriguing part, sporting a Cortex-M4 and a Cortex-M0. The former has floating point and DSP instructions, while the latter is targeted at the control and housekeeping functions that so many embedded systems need.
One interesting feature is their SPI Flash Interface (SPIFI). The company introduced this on their LPC1800 series of processors a year or two ago. SPIFI is a mechanism that interfaces the CPU to external serial flash memory. The cool thing is that the serial flash appears in the microcontroller’s address space, and can be accessed in a standard random access fashion. That’s right: random access to serial flash .
There are a number of upsides. Serial flash is cheaper than parallel. And, far fewer pins are needed. The SPI connection requires just four pins (6 for quad flash devices). A serial flash device can have just a total of 8 pins, greatly shrinking PCB real-estate needs. In contrast, parallel devices need gobs of address, data and control connections.
There’s no software layer between the flash and the CPU. A SPIFI controller on-board the microprocessor connects the flash directly to the AHB bus (for some reason a lot of literature about ARM’s Application High-speed Bus put the redundant word “bus” after AHB). Eight registers control the SPIFI interface; once set up, any instruction can access the flash as if it were regular memory. So the system can use serial flash as bulk storage, access it via DMA, and even execute code directly from it.
The LPC43xx series are very complex parts with tons of features. They do an initial boot from an on-board ROM, which can configure the SPIFI registers and then initiate the application’s boot from SPIFI flash.
Being on the AHB means that either core can access the serial flash at any time. It’s a little freaky using these parts since the M4 and M0 share address space. Either can use the same peripherals and memory. While this is a powerful idea, it’s laden with reentrancy threats. There is an interprocessor communications strategy, though, so with a little care robust code isn’t too hard to write.
The obvious down side is transfer speed. Real random-access reads and writes will be quite slow, as the address and data have to be transferred over SPI. That’s probably not important for booting.
But one could copy the flash to RAM and execute from there. Block transfers are very fast. Some applications might take advantage of the on-board LCD controller, and store blocks of images in the flash, which will transfer quickly. The SPIFI controller can mediate these transfers so no CPU intervention is needed.
Presumably SPIFI will be an NXP-only feature, as the company is applying for a patent on the technology. But it’s a pretty cool idea.
Jack G. Ganssle is a lecturer and consultant on embedded development issues. He conducts seminars on embedded systems and helps companies with their embedded challenges. Contact him at . His website is .