SPIFI read issues in quad mode and at higher clock speeds using lpcspifilib

[lpcware]

Content originally posted in LPCWare by avenuti on Fri Nov 20 14:39:07 MST 2015
Setup:
LPCXpresso v7.9.2_493

LPCOpen v2.12
lpclibspifi v1.03_68

NXP LPC1837FET256
Spansion S25FL512S

Workspace has my project, lpc_chip_18xx from LPCOpen, and spifilib_m3 from lpcspifilib.
I have followed the instructions in the SPIFIlib manual under "LPCSPIFILIB library use model", with the exception of speeding up the SPIFI base clock after initialization (I'll get to that in a moment).


Issue 1: When SPIFI is set to quad spi mode, data reads from flash are not correct, even though programming in quad spi mode works correctly.

I have two areas of flash, 0x14280000 and 0x142C0000, that are being used in testing. In both blocks I erase with spifiEraseByAddr and program with spifiProgram. Erasing and programming the first block is done with quad mode off, and the second with quad mode on. After programming I put the device in memory-mapped mode with spifiDevSetMemMode and check the data in the Memory window. When quad mode is off, the data shows correctly in the Memory window for both blocks. When quad mode is on, the data appears incorrectly for both blocks.

   spifi_result = spifiDevSetMemMode(gSpifiDeviceHandlePtr, true);

   spifi_result = spifiDevSetOpts(gSpifiDeviceHandlePtr, SPIFI_OPT_USE_QUAD, true);
   
   spifi_result = spifiDevSetOpts(gSpifiDeviceHandlePtr, SPIFI_OPT_USE_QUAD, false);

When the above is run (with quad mode initially off) the data appears correctly after the 1st line is stepped over, switches to be wrong after the 2nd line is stepped over, then switches back to correct after the 3rd line is stepped over.


Issue 2:

The maximum read speed for this device, according to the lpcspifilib, is 80 MHz. Whenever the SPIFI base clock is set above ~50 MHz, functions in the SPIFI library that use any read commands (such as spifiDevSetOpts which reads the device status) do not execute correctly. They seem to get stuck reading the device status inside spifi_HW_WaitCMD, which loops indefinitely.
According to the spec sheet for the Spansion chip, there is a maximum speed of 50 MHz for certain read functions, but it looks like the SPIFI library is always using fast-mode reads.

[lpcware]

Content originally posted in LPCWare by mc on Sun Jan 31 19:52:41 MST 2016
Did you probe signals to confirm that you really need delay? Are you just resetting Microcontroller?

[lpcware]

Content originally posted in LPCWare by avenuti on Thu Jan 21 10:13:31 MST 2016
NXP,

After seeing your comment I went back and enabled FBCLK, attempting to recreate the error I had before. I was unable to do so, however. Regardless, I did not have SPI mode 3 enabled.

I have made my code more stable by replacing spifiInit entirely, configuring the SPIFI control register separately (including setting both RFCLK and FBCLK). Part of my problem may have been attempting to use SPIFI and/or the flash too quickly after reset. I have added in a small delay after reset to ensure the reset completes correctly.

[lpcware]

Content originally posted in LPCWare by mc on Mon Dec 14 08:37:48 MST 2015
Hi avenuti,
Could you please check the SPIFI mode you were using? In MODE0  setting both RFCLK and FBCLK  should work. You may want to post you code here.

[lpcware]

Content originally posted in LPCWare by avenuti on Mon Nov 23 11:18:03 MST 2015
Okay, I think I'm finally making progress here.

Went back to the function spifiInit, which initially had been causing me problems. If I called that function with the reset flag set 'true', the library would not initialize correctly, causing spifiGetHandleMemSize to return 0 and spifiInitDevice to return NULL. Calling spifiInit with the reset flag set 'false' would fix this, and according to the documentation "in most cases, a reset isn't needed".
Curiously, spifiInit does nothing whatsoever if that reset flag is set 'false', so I figured I'd go through it line-by-line and figure out what inside spifiInit was causing problems.

It turns out that line 344 (of spifi_dev_common.c) was the culprit, setting the feedback clock to 1, or SPIFI_CTRL_FBCLK(0).

Not only did setting this to 0 allow me to run spifiInit with reset 'true', but doing so fixed my quad mode / high speed reading problem! I can now run at 180 MHz, with the SPIFI clock at 60 MHz, and both reads and writes are functioning properly.

It turns out that not setting SPIFI_CTRL_RFCLK(1) (by skipping the spifiInit reset completely) was the actual cause of my read problem. Setting SPIFI_CTRL_RFCLK(0) (with the feedback clock also 0) reintroduced my problem.

Can you please give me some insight as to what exactly is going on with RFCLK/FBCLK enabled or disabled? The documentation for these is clear but not meaningful.

[lpcware]

Content originally posted in LPCWare by lpcxpresso-support on Mon Nov 23 08:08:31 MST 2015
Avenuti,

I have taken a look at the issue you have raised using a Spansion S25FL512s on a dev board fitted with a SPI flash test socket. Despite this being a sub optimal connection scheme, I was not able to duplicate any of the issues you raised.

In my test case the board was running a 180MHz clock and the SPI device details report as below:

Device family = S25FL512S
Device size = 0x4000000
Erase Sector size = 0x40000
Write page size = 0x200
SPIFI final rate = 60000000

I am able to program and verify single, dual and quad speeds (1.16MB/s) and read at single, dual and quad (verifying the reads using a checksum) at speeds as below:

Flash Read in 8948 ms
Flash Read in 4474 ms
Flash Read in 2237 ms (approx 30MB/s)

When connected through LPCXpresso v7.9.2 [Build 493] [2015-09-14], I am able to see the memory window display the expected memory values.

Also I see no problem calling spifiDevSetOpts or spifiDevGetInfo at single, dual or quad settings.

Given that I am able to achieve reliable quad operation on this part (via a test socket on a daughter card), exploring the hardware side of your board might be productive.

Yours,
LPCXpresso-Support