Flash Programming on LPC4370 SPIFlash failing

[dmarples]

A few months back there was a question raised about SPI Flash programming failing on a LPCLink2 board used as a target. For the life of me I cannot find it on this new improved system and all the links on the old lpcware site point to here now, so that doesn't help.

UPDATE: Now found the old thread at Flash driver operation failed - Program operation failed validation or readback compare | www.LPCwar... 

I have a custom design board that we are programming with LPCLink2 via LPCExpresso and, once if a while, it borks the SPIFlash (A Spansion FL032PIF device). The end result of this borkage is that it does not seem to be possible to un-write-protect the SPIFlash for future flash sequences so you're left with whatever happens to be in the flash at the point where it goes AWOL.

Has anyone else experienced this? Here is a typical programming sequence that goes wrong (but I'm not sure this trace is from a Spansion chip). I'd format this as code but that doesn't appear to be possible any more;

LPCXpresso RedlinkMulti Driver v8.1 (Mar 11 2016 13:35:29 - crt_emu_cm_redlink build 672)
Found chip XML file in /home/dmarples/Develop/llb_v2/ofiles/LPC4370.xml
Probe Firmware: LPC-LINK2 CMSIS-DAP V5.147 (NXP Semiconductors)
Serial Number:  IQCYEVCR
VID:PID:  1FC9:0090
USB Path: /dev/hidraw7
Emu(0): Connected&Reset. DpID: 2BA01477. CpuID: 410FC240. Info: <None>
Debug protocol: SWD. RTCK: Disabled. Vector catch: Disabled.
inspected v.2 External Flash Device on SPI /usr/local/lpcxpresso_8.1.4_606/lpcxpresso/bin/Flash/LPC18_43_SPIFI_8MB_64KB.cfx
image 'LPC18/43 Generic SPIFI Feb 16 2016 09:19:36'
flash variant 'W25Q64FV' detected (8MB = 128*64K at 0x14000000)
NXP: LPC4370  Part ID: 0x00000000
( 65) Chip Setup Complete
Connected: was_reset=true. was_stopped=false
LPCXpresso Free License - Download limit is 256K
Writing 42836 bytes to address 0x14000000 in Flash
ProgramPage (0x14000000, 0x10081000, 0x4000) status 0x1 - driver reported driver error - EXTSPI driver rc 10 - Program operation failed validation or readback compare
Target error from Commit Flash write: Ef(49): Flash driver operation gave error.

[haraldsonntag]

Sorry,

forgot to say:

The LPC Link II I talked about is the target. I have a 2nd LPC Link II as debug/programmer which was not afected naturally.

Harald

[haraldsonntag]

Hi Dave and all others here,

I already sayed thanks to Rodri (the previous thread), because already his solution with lpclink2-config-tool works perfectly for me too!

Also let me say thank you to you Dave, because you further helped to find a solution.

I also had a LPC Link II and worked with it 3 month. This morning, the same error came-up.

But the basic question here is "Why the error flash programming impossible" does appear at all of us?

I have had a look at Rodri's code "Test_LED" because I wanted to find-out what we have done both.

We both do not access the flash from wqithin our code.

But we both use the USB stack and we both use a Timer Interrupt and we both use the HSADC.

My error came up (after months of no error) after I used the HSADC, the USB stack (HID device) and the SysTick.

I had to change the SysTick IRQ prio in NVIC because the LPC SysTick_Config changed SysTick's prio to lowest.

Unfortunately (blackout yesterday) I have sent a Bluetooth LE advistising packet from within (!!!) the SysTick IRQ handler and this takes some time and is repeated every 2 millisecs.

I have seen, that the USB stack is no more responding after 20-30 seconds. So I moved-out the BT packet sending code and wanted to program the device and the error came-up.

My opinion is, that my lengthy SysTick handler prevented the USB stack to continue (no USB response). My SysTick is at highest prio, so it can also interupt USB and for a "lengthy" time not return to USB.

And this might have caused the flash programming problem.

With the modified code (thanks to Rodri now in my board) the USB stack no more hangs, my adverstising packet is sent

from the main while loop (signaled by SysTick), the 80Msamples ADCHS values are transfered through USB and the board again can be re-programmed as often I want.

@NXP:

1. One more bug in USB stack?

2. The LPCScrypt can not solve the program, the old LPC_Link2_Config_tool_v1_11_1.zip (834KByte, no need for .NET) solved it.

3. The modified LPC18_43_SPIFI_GENERIC.cfx I could not test, because the error no more appears.

Could move the packet sending code again into the SysTick and check, wether it appears again.

Harry

[lpcxpresso_supp]

In response to the reports on this (and other) thread(s) and with particular thanks to the investigative work by Dave Marples... we have explored an issue that can impact the programming of Winbond SPIFI flash devices via the SPIFI flash drivers built around LPCSPIFI library - (i.e. those within LPCXpresso IDE and LPCScrypt).

As has been described on this thread, these flash parts incorporate a feature that if used compliments (inverts) the meaning of any internal write protection within the device. Therefore a typical device with no write protection enabled would become fully write protected if this Compliment (CMP) feature became enabled. As currently shipped, LPCSPIFI libraries support for Winbond part includes no test for this Compliment (CMP) feature and so any driver built using this library may fail to operate correctly should this feature become set.

The CMP feature is enabled by writing to a bit (bit 14) within the Winbond flash status register and is persistent once set. We do not believe this bit can become accidentally set by our flash drivers and the reason for this problem occurring in the field remains unknown. Furthermore we have never seen this problem occur within our test infrastructure (which makes heavy and regular use of these parts).

We have attached to this post an updated SPIFI driver for the LPC18/43 series of MCUs. This driver will clear this CMP bit (if set) on initialization.

To update an existing LPCXpresso IDE installation to use this driver browse to:

1. <LPCXpresso IDE Install Dir>/lpcxpresso/bin/Flash
2. locate the existing driver 'LPC18_43_SPIFI_GENERIC.cfx' and rename this e.g LPC18_43_SPIFI_GENERIC_old.cfx
3. Unzip and copy the attached driver to this folder

In use the new driver will identify itself within the debug log during a flash programming operation using an updated date as below:

inspected v.2 External Flash Device on SPI LPC18_43_SPIFI_GENERIC.cfx
image 'LPC18/43 Generic SPIFI Sep 27 2016 16:31:59'

We would appreciate any feedback on the use of this updated driver.

We have seen user references to problems occurring after OTP programming operations have been performed. For clarity, the built in OTP feature of the LPC43xx MCU is completely unrelated to external SPIFI flash and so we do not believe problems can occur when these bits are used.

Yours,

LPCXpresso-Support

[Ray_V]

Thanks, I had the same problem on a board that is not DFU bootable and this solved the problem.

I believe that the problem occurs when you try to program it while running code from flash.

It probably locks the flash while running code from it, and trying to program it interrupts the process and never unlocks the flash.

I set a function to run from RAM and have it stay in a loop for a minute. I call it (we have a UART interface) whenever I am going to update the program with SWD/JTAG and so far have had no issues.

I had a couple of boards locked previously and as I said this LPC18_43_SPIFI_GENERIC.cfx solved my problem.

[lpcxpresso_supp]

Dave,

Just to let you (and others) know that this issue has not dropped off our radar and we are continuing our investigations.

Yours,

LPCXpresso Support

[lpcxpresso_supp]

Dave,

Thanks for the additional information. We'll look into this, but in the meantime you can produce your own variant of the SPIFI flash driver for testing there - the source project is provided within the Examples directory of the LPCXpresso install directory. It sounds like you will probably want to tweak the Init() function inside the file FlashPrg.c.

For more details see : https://community.nxp.com/thread/389076 

Regards,

LPCXpresso Support

[dmarples]

OK, After a quick tramp through the code it looks like the CMP bit is carefully protected if it ever gets set (I'll leave it to you guys to figure out how it's getting set!) in which case my first guess at what's needed is something like;

Line 151 in spifilib_fam_standard_cmd.c --> ADD  #define STATUS_CMPMASK (1<<14)

Line 1011 in spifilib_fam_standard_cmd.c in spifiFamFxLockDeviceCmd --> CHANGE TO stat &= ~(STATUS_BPMASK|STATUS_CMPMASK)

Its probably also worth looking at;

spifiPrvCheckWriteState

spifiFamFxGetDeviceStatus

...just to make them respect the CMP bit too.

My main concern is that I'm no SPI memory expert and I have no idea how standard this CMP bit is....it should fix my problem, but I can't be certain it won't create another one without going through the datasheets for all the other serial flash you support.

I won't have the time to make & test these changes for at least a couple of days due to travel, so please PM me if you manage to get a build together you'd like testing in the meantime....I have about 4 dead chips I can test with.

Regards

DAVE

[dmarples]

OK, So I made the required changes in spifilib_fam_standard_cmd.c including the changes to spifiPrvCheckWriteState and spifiFamFxGetDeviceStatus.  When programming I now get a correct error back;

<SNIP>

Opening flash driver /usr/local/lpcxpresso_8.2.0_647/lpcxpresso/bin/Flash/LPC18_43_MARPLES_SPIFI_GENERIC.cfx
Writing 48116 bytes to address 0x14000000 in Flash
EraseSector (0x14000000, 0x0, 0x1) status 0x1 - driver reported driver error - EXTSPI driver rc 5 - Device was locked and a program/erase operation was attempted
Target error from Write Flash: Ef(49): Flash driver operation gave error.
(crt_emu_cm_redlink) terminating on communication loss: Pipe has been closed by GDB.

Great, so we now at least get it reported that the flash is locked.  So, question; Is there any facility in the IDE to perform the unlock?  All the code is now correctly in the driver (AFAIK) and it's behaving correctly, but we need to tell the flash driver to override the lock...I can cludge-fix it if need be and force the unlock, but if there's some magic incantation available to force the call to the unlocker then that would be a better solution since the ability to lock is there for a reason....

Modified file attached...this is the only one that needed changes.

[EDIT: File removed, since a more up to date one is in a post that follows].

DAVE

[denniscramm]

Hello,

We experienced the same problem with the LPC4370 on a custom board. Interestingly, the problem only seems to appear when we program the OTP-Memory so that the Controller boots from the external flash. We use the same software on older boards without the OTP programmed and the problem never appeared there.

Could it be possible that the boot routine for the external flash somehow sets the CMP sporadically without resetting it?

@Dave

Thanks to your investigations we were able to regain access to a dead flash. We also tried to include your routine to reset the CMP bit into our project, but in our case it leads to that we cannot debug the LPC anymore. We had to clear the flash via an external board while keeping the LPC in reset to get it running again. Could you tell us in which way you used your code? Did you also implement it into your program or is it a stand-alone-project (maybe placed in the internal ram)?

Regards,

Dennis

[dmarples]

Hi Dennis,

Your point about the OTP is interesting, as we also had that programmed on the boards that had a problem....@NXP: that might be a place to look for how this bit is getting set.

For my experiment I just built a RAM based program and ran that to reset the bit.  I've now folded the changes into the spifilib_fam_standard_cmd.c file in the Flash library and built a new flash cfx. Both the c file and the resulting cfx are attached to this mail. With this I have been able to 'resurrect' a few chips (not too many, as these boards are starting to get tired now) without problems.

Please give this cfx a go but it's warranty free so don't blame me if it electrocutes your cat, or worse....if you're nervous wait for an official release from NXP, but this was a stop-ship for us, so we had to create a fix, and this problem has been around since March so I had to give it some attention.

Copy the cfx file into your Flash directory (/usr/local/lpcxpresso_8.2.0_647/lpcxpresso/bin/Flash/ in my case) and then select it in the project (Project -> Properties ->C/C++ Build -> MCU Settings -> Edit -> Browse), stand well back and beware of fireworks.

Regards

DAVE

[denniscramm]

Hi Dave,

Your updated SPIFI-Driver worked perfectly with our board. Thanks a lot for that:)

Regards,

Dennis

[lpcxpresso_supp]

Please let us know once you receive the DFU bootable board with a "problem chip" fitted and we'll post details of LPCScrypt commands to try with it.

And thanks for the comment about the Chip_CREG_SetFlashAcceleration() function - we will look into this.

Regards,

LPCXpresso Support

[dmarples]

OK, I think I've got to the bottom of this, although I cannot tell you why the problem is occurring in the first place. I hacked up a bit of code to read the status registers on the W25Q64FV. On a faulty chip the values were;

SR0=0xE0, SR1=0x40

...the implication of these is that the write protection bits are inverted (the 0x40 is the CMP bit) and thus the whole of the flash is not available for programming.  I flipped the bit with code like;

    spifi_HW_SetCmd((LPC_SPIFI_CHIPHW_T *)LPC_SPIFI_BASE,
                    (SPIFI_CMD_OPCODE(0x6) |
                     SPIFI_CMD_DATALEN(0) |
                     SPIFI_CMD_FIELDFORM(SPIFI_FIELDFORM_ALL_SERIAL) |
                     SPIFI_CMD_FRAMEFORM(SPIFI_FRAMEFORM_OP)));
    spifi_HW_WaitCMD((LPC_SPIFI_CHIPHW_T *)LPC_SPIFI_BASE);

    spifi_HW_SetCmd((LPC_SPIFI_CHIPHW_T *)LPC_SPIFI_BASE,
                    (SPIFI_CMD_OPCODE(0x01) |
                     SPIFI_CMD_DATALEN(2) |
                     SPIFI_CMD_DOUT(1) |
                     SPIFI_CMD_FIELDFORM(SPIFI_FIELDFORM_ALL_SERIAL) |
                     SPIFI_CMD_FRAMEFORM(SPIFI_FRAMEFORM_OP)));

    spifi_HW_SetData8((LPC_SPIFI_CHIPHW_T *)LPC_SPIFI_BASE, 0xe0);
    spifi_HW_SetData8((LPC_SPIFI_CHIPHW_T *)LPC_SPIFI_BASE, 0);

    spifi_HW_WaitCMD((LPC_SPIFI_CHIPHW_T *)LPC_SPIFI_BASE);

(It's a bit untidy, but it did the job) resulting in;

SR0=0xE3, SR1=0

...the 3 in SR0 is just 'cos I left the chip in an untidy state.  Now, I can flash the chip again normally....and save myself a lot of unsoldering.

So, NXP guys, any chance of an experimental build of the flash burner firmware which resets CMP in SR1?  I've got a few more chips I can try it on....it's late, and there's more testing to be done, but certainly I've resurrected the chip that is on this specific board.

Regards

DAVE

[lpcxpresso_supp]

The LPCware thread you referenced was imported into the new NXP community, and has been updated recently : Flash driver operation failed - Program operation failed validation or readback compare 

It would be interesting to know whether you can program your board using LPCScrypt v1.8 (if your board is USB DFU bootable). Otherwise, can you comment on the contents of the response we posted in the above thread  on 1st Sept :

And how are you connecting the board to your PC - directly or through a hub? Have you tried a different USB port? A different USB cable? And does connecting through a powered USB hub make any difference (or direct to the PC if you are using a hub) ? Might be interesting to know if you see the same problem using a different PC as well. My best guess is that this is some marginal power issue.

Regards,

LPCXpresso Support

[dmarples]

The symptom is (intermittently) repeatable on multiple PCs. On my own personal machine the connection is via a USB3 hub but the target is independently powered anyway and the grounds are good. We have scoped the power during programming and do not see anything unusual.

I have seen the behaviour with the Spansion chips and my colleague (who is in NL and I'm in GB right now, so it's not _so_ easy to compare notes) is using a Winbond W25Q64FVSIG. I'm having some of the Winbond chips (and hopefully some borked ones too) shipped here so I can investigate further. A new board that is DFU bootable should also be in the same food parcel.

One thing that _might_ be interesting; We had an intermittent boot problem on the board that made no sense. After carefully reviewing the code we found some boilerplate code that had been integrated that made a call;

Chip_CREG_SetFlashAcceleration(MAX_CLOCK_FREQ);

Now, according to Section 11.1 of the User Manual the FlashAcceleration registers (FLASHCFGA, FLASHCFGB) are not implemented on flashless parts. Since removing this line the boot problem hasn't been further observed (which is not quite the same as saying it's fixed). Is it possible this is cache setting is somehow interacting with the flash process? Are the FLASHCFGx registers persistent over a soft reboot of the chip? To the other people who saw the problem...do you have this line (or equivalent) in your code?

Regards

DAVE

[dmarples]

...for completeness, here's a log of a second flash that's failed in the same way (different board & build environment, code is the same);

LPCXpresso RedlinkMulti Driver v8.2 (Jun 30 2016 17:49:07 - crt_emu_cm_redlink build 723)
Found chip XML file in V:/garonne/llb/scratch/am2/LPC4370.xml
Probe Firmware: LPC-LINK2 CMSIS-DAP V5.147 (NXP Semiconductors)
Serial Number:  JQDYMZCW
VID:PID:  1FC9:0090
USB Path: \\?\hid#vid_1fc9&pid_0090&mi_00#8&1fbb1906&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}
Emu(0): Connected&Reset. DpID: 2BA01477. CpuID: 410FC240. Info: <None>
Debug protocol: SWD. RTCK: Disabled. Vector catch: Disabled.
inspected v.2 External Flash Device on SPI C:\nxp\LPCXpresso_8.2.0_647\lpcxpresso\bin\Flash\LPC18_43_SPIFI_8MB_64KB.cfx
image 'LPC18/43 Generic SPIFI Jun 21 2016 11:54:07'
Opening flash driver C:\nxp\LPCXpresso_8.2.0_647\lpcxpresso\bin\Flash\LPC18_43_SPIFI_8MB_64KB.cfx
flash variant 'W25Q64FV' detected (8MB = 128*64K at 0x14000000)
NXP: LPC4370  Part ID: 0x00000000
Connected: was_reset=true. was_stopped=false
LPCXpresso Free License - Download limit is 256K
Opening flash driver C:\nxp\LPCXpresso_8.2.0_647\lpcxpresso\bin\Flash\LPC18_43_SPIFI_8MB_64KB.cfx
Writing 48352 bytes to address 0x14000000 in Flash
ProgramPage (0x14000000, 0x10081000, 0x4000) status 0x1 - driver reported driver error - EXTSPI driver rc 10 - Program operation failed validation or readback compare
Target error from Commit Flash write: Ef(49): Flash driver operation gave error.
(crt_emu_cm_redlink) terminating on communication loss: Pipe has been closed by GDB.