SPIFI Errata and Part Version Information

[lpcware]

Content originally posted in LPCWare by gregd on Mon Apr 01 12:32:43 MST 2013
We are working on a new design and trying to decide whether to use the LPC4330 or LPC4337. 

We currently have current board design that uses the LPC4350.  These boards were built using chips with the following markings:
    LPC4350FET256
    PFM906.04     15
    ESD1148ZRY

1) From the ES_LPC43X0_A.pdf errata document it looks like function problem SPIFI.1 exists on the rev "A" part but not on the rev "C" part.  Is this correct?

2) The part shown above definitely has the SPIFI.1 problem.  From the part marking and the ES_LPC43X0_A errata sheet, I can't tell what version part this is, it doesn't seem to match for format shown in the errata document.  Can anyone tell me what version it is?

3) For the LPC4337, from the ES_LPC435X_3X_2X_1X_FLASH.pdf errata document, the SPIFI.1 issue is not included.  Does this problem exist on any of the LPC4337 released versions?

4) Assuming that the answer is "yes" to question 1, does this mean that while the rev "C" part is executing code from the SPIFI, you can give it a hardware reset and the part will properly re-boot from the SPIFI without any issues and not require the 60 second delay as the Rev "A" part does?

5) What revision parts are available currently from suppliers?

6) I have seem many requests for this before but have never seen any answers:  Will the SPIFI library source code ever be publicly released?  Is it available through an NDA?

Thanks,
Greg Dunn

[lpcware]

Content originally posted in LPCWare by rgledhill on Tue Nov 12 01:31:18 MST 2013
Hi Noah,

Many thanks, this is very helpful!  I'm actually looking to use the SPIFI library as a file system though, not execute in place, with the Keil FileSystem.  I think this means the library has to implement functions to erase and program the chip but can otherwise just read the memory/spifi-mapped memory...

All help gratefully received!

Thanks
Richard

[lpcware]

Content originally posted in LPCWare by JAlvarez on Thu Aug 01 07:30:59 MST 2013
Maybe automatic was not a good choice of words. My intent was to imply the SPIFI interface simplifies logic significantly. Just handling framing and chip select transitions reduces code considerably. The continuous reads, address mapping for random access, speculative prefetch and caching in memory mode also provide significant functionality.

Your suggestion to temporarily turn off high speed mode could be an alternative to sending a dummy command. For tasks that don't operate on large amounts of data, such as a read ID or a block erase, the performance advantage of quad I/O should not be significant. Allowing a dummy read in command mode to cycle the SPI shift register would probably be more intuitive. Yet the SPIFI interface generates an exception if the data register is read without specifying it on a previous command. Sending a read status command and discarding the response is a simple workaround for this.

[lpcware]

Content originally posted in LPCWare by noahk on Wed Jul 31 17:17:03 MST 2013
Hi JAlvarez,

You are welcome. As a further clarification, the SPIFI doesn't intelligently differentiate between different types of commands. The registers indicates to the SPIFI exactly what it is supposed to do. For example, dummy clock cycles, data format, what to send, etc... are all specified through the registers.

As I tried to explain, the dummy command before a read of the device id is not required by the SPIFI. It is required by the SPI Flash device. If the software puts the SPI Flash into a "high speed mode", then there is a requirement by the SPI Flash to cancel that mode before sending an additional command to the SPI Flash. The SPIFI doesn't keep track of that mode. The software is required to know that it put the SPI Flash in "high speed mode" and the software is then required to cancel that mode before sending another opcode to the SPI Flash.

As a further note, if you bypass the activation of "high speed mode" by using this code when enabling memory mode, then you will not need the "dummy command":

// do not put part in high speed mode
LPC_SPIFI->DATINTM = 0; // 0 will not turn on high speed mode

LPC_SPIFI->MEMCMD =
(0xebul << 24) | // opcode 0xeb Quad IO High Performance Read for Spansion
(0x4 << 21) | // frame form indicating opcode and 3 address bytes
(0x2 << 19) | // field form indicating serial opcode and dual/quad other fields
(0x3 << 16); // 3 intermediate data bytes

But in this mode, every new address will cause a serial opcode to go out. This adversely affects performance (adds 8 clocks before read data arrives for a new non-sequential address). That is why my example does put the SPI Flash in "high speed mode".

Noah

[lpcware]

Content originally posted in LPCWare by JAlvarez on Wed Jul 31 17:14:17 MST 2013
Thanks for the clarification. It makes sense that in command mode some clock cycles are required to transition between very different SPI framing and field formats. On a typical SPI interface those transitions would need a dummy read to cycle the SPI shift register. The NXP SPIFI interface transparently manages several common transitions by specifying frame/field formats in its command register. In your example the loop sending write enable, quad program and read status commands, switches formats continuously without dummy commands. Yet it is not clear which transitions are not managed automatically. For example, reading the manufacturer/device IDs or erasing a block without programming appear to require sending a dummy command beforehand to execute properly. Possibly writing 0xff to the IDATA register would have a similar effect. As the SPIFI documentation evolves hopefully there will be a guideline to determine when additional steps are required, avoiding having to do it via trial and error.

Another important point shown in your example is that writing directly to SPIFI registers is a simple alternative to erase and program serial flash from applications. You get full control of SPIFI features with object code that is about ten times smaller than using the NXP SPIFI library. Using a binary library is also not an alternative for projects that require releasing source code.

Our boards use the Winbond W25Q32FV and W25Q64FV. Their command set seems compatible with Spansion (at least the common ones). One of their main advantages is support for 4K sector erase and program in the whole address space, which is not supported in newer Spansion parts. The buffer required to update partial sectors on serial flash with 64K or 256K sectors is too large for most LPC43xx applications (without external RAM).

[lpcware]

Content originally posted in LPCWare by noahk on Wed Jul 31 10:02:40 MST 2013
Hi JAlvarez,

I am very glad that the example has helped you.

Regarding your question sent to my inbox, the reason you are performing those extra commands is probably to get the SPI Flash out of "high speed mode (0xeb) command". The 0xeb allows for mode bits which indicate that subsequent chip select assertions will be followed by an address and will not require the 0xeb command. The reasoning for this is to enable XIP applications where the only requirement is getting at random data as fast as possible. The chip (I assume it is still Spansion S25FL129P) accepts only serial commands but allows for quad address and data. So "high speed mode" removes the 8 clocks required for sending the serial command. The code in my example that sends 0xff with IDATA as 0xff could be used to remove the chip from "high speed mode" (although I am pretty sure that is more clocks of 1's than is actually required). Once that is done the chip will respond properly to new commands.

Let me know if that makes sense or if you have any other questions,

Noah

[lpcware]

Content originally posted in LPCWare by JAlvarez on Tue Jul 30 16:11:23 MST 2013
Thanks for posting your SPIFI_XIP_Storage example. It clarifies the logic required for going in and out of SPIFI command mode. The need to disable the Cortex write buffer while updating flash should be mentioned in the LPC4350 user manual. NXP should consider evolving your SPIFI example into an application note.

The manual mentions that a SPIFI status reset is needed to change to either mode, but writing to the memory command register also switches to memory mode. Applications with ISRs in flash should also disable them while updating the flash contents. The basic logic to go to command mode and back is as follows:

void spifi_cmdmode(void) {
    __disable_irq(); // Disable IRQs
    SCnSCB->ACTLR &= ~2; // disable Cortex write buffer to avoid exceptions when switching back to SPIFI for execution
    if (LPC_SPIFI->STAT & 0x01) { // In memory mode?
        LPC_SPIFI->STAT = 0x10; // Go to command mode
        while(LPC_SPIFI->STAT & 0x10); // wait for reset to complete
    }
}

void spifi_memmode(void) {
    LPC_SPIFI->MEMCMD =
            (0xebul << 24) | // opcode 0xeb Quad IO High Performance Read for Spansion
            (0x6 << 21) | // frame form indicating no opcode and 3 address bytes
            (0x2 << 19) | // field form indicating serial opcode and dual/quad other fields
            (0x3 << 16); // 3 intermediate data bytes
    SCnSCB->ACTLR |= 2; // Enable Cortex write buffer
    __enable_irq();
}

[lpcware]

Content originally posted in LPCWare by noahk on Wed May 29 20:47:34 MST 2013

Hi Greg,

I can't speak much about the source code for the SPIFI Driver, but here's an example I wrote for the LPC4350 eval board from Hitex with the Spansion S25FL129P. The SPIFI registers are pretty easy to use once you get the hang of it. Hopefully this will help.

This is an imperfect example as this board uses an SPI Flash part that is not very suitable to execute in place. The reason is explained below. But the example code might be useful. It is an example that directly uses the registers of the SPIFI.

XIP (Execute in Place) Example

The biggest issue you will have is that the Spansion part that Hitex put on this board uses uniform 256 KB sectors. This means that attempting to write data will require a 256 KB scratch area, which I would imagine is too big a scratch area for these chips. I would recommend getting the same general SPI FLASH part but with the uniform 64 KB sectors which also has 4 KB parameter sectors. (The 256 KB part doesn’t support the 4 KB parameter sectors). Here is an example project to write to one word in SPIFI and continue execution. It is not using the spifi library. It uses the register interface directly.

*** The project uses the 256 KB erase command, but pretends that it only needs to store 4 KB. That of course is not correct for a standard application. Please make sure to get the appropriate 64 KB uniform sector part with the 4 KB parameter sectors in order to use this example code in a real application.

Note the disabling and re-enabling of the Cortex Write Buffer (SCnSCB-&gt;ACTLR bit 2). Without disabling the write buffer, the Cortex will prefetch from the SPIFI memory area before the SPIFI memory area is turned on, and that will cause an exception.

Note the usage of 0xd8 instead of 0x20 to perform the erase, see line 115 in spifi_functions.c.

***Note that the whole spifi_functions.c is put in IRAM. Please set the volatile go bit (from a watch window) to run the example.

Noah

[lpcware]

Content originally posted in LPCWare by starblue on Mon Apr 08 05:25:36 MST 2013

ESD1148ZRY is Rev A:

http://www.lpcware.com/content/forum/errata-situation-can-lpc4350-revision-esd1148zry#comment-2189