LPC MicrocontrollersのトピックNeed clarification on Errata SPIFI.1.

Need clarification on Errata SPIFI.1.

lpcware — Wed, 15 Jun 2016 19:06:20 GMT

Content originally posted in LPCWare by DPeters on Thu Mar 08 09:50:13 MST 2012
I'm bootloading from a QSPI device using SPIFI and running the application on SRAM. If a reset is performed, Errata SPIFI.1 results in needing two successive resets before the image is successfully bootloaded via spifi. The work-around is to remove the QSPI device from no-opcode mode before resetting CPU. I haven't found any hints in the user manual or SPIFI_ROM_API.h files on how to do this. I'm guessing there's a bit in the SPIFIopers structure than can be set when initializing using the spifi_init() call. Has anyone done this?

Re: Need clarification on Errata SPIFI.1.

lpcware — Wed, 15 Jun 2016 19:06:21 GMT

Content originally posted in LPCWare by ktownsend on Sun Mar 11 18:37:31 MST 2012
DPeters:

I think until this errata is fixed, the most reliable means to work around this is probably a HW solution for the double-reset. You can configure the SPI flash before doing an intentional reset, but unfortunately that doesn't taken into account every situation.

Re: Need clarification on Errata SPIFI.1.

lpcware — Wed, 15 Jun 2016 19:06:21 GMT

Content originally posted in LPCWare by DPeters on Mon Mar 19 09:38:18 MST 2012
Yes, the unexpected reset is the concern, where I need to ensure the program is properly bootloaded. I've discovered a solution whereby all SPIFI operations are encapsulated in routines that have wrapper calls. Basically the SPIFI is enabled only during the routine, then disabled afterwards. As long as the reset happens outside of the SPIFI routine, the SPIFI will successfully bootload after the reset. To do this, add the following routine declarations to the spifi_rom_aph.h file:

void set_mem_mode (SPIFIobj *obj);
void cancel_mem_mode (SPIFIobj *obj);

Before any SPIFI operation, call set_mem_mode(). When done, call cancel_mem_mode().

NOTE: Memory mapped spifi address reads/writes are off-limits following a cancel_mem_mode() call, otherwise a hard-fault occurs.

There is still a chance a reset will happen between the time set_mem_mode() and cancel_mem_mode() are called, and thus a double reset would still be needed, but I think this is the best that can be done with the current errata.