lpcware

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

Discussion created by lpcware Employee on Jun 15, 2016
Latest reply on Jun 15, 2016 by 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.

Outcomes