Flash driver operation failed - Program operation failed validation or readback compare

[lpcware]

Content originally posted in LPCWare by einsiek on Fri Mar 04 15:31:16 MST 2016
Hello,

After having used LPCXpresso with LPC4370 successfully for a few months, I have started to get a specific error during the Flash operation. This error has occurred on multiple boards (4 boards: 3 custom boards and 1 LPC-Link2 board), with different IDE version (v7.9, v8.0, v8.1), with different program (e.g. today it appears with the periph_blinky example program) and on different computer.

Here is the error message

op ProgramPage (0x14000000, 0x10081000, 0x4000) status 0x1 - driver reported driver error - EXTSPI driver rc 10 - Program operation failed validation or readback compare

This error occur apparently before the Flash driver writes the binary into the Flash, because the previous binary is still working after it. But then I'm not able to update new binaries or to debug the target anymore.

I have already tested the following operation:
[list]
  [*]Booting into ISP mode (ISP LOW, NRESET LOW, NRESET HIGH, ISP HIGH or Floating) => no effect
  [*]Enable Vector catch => no effect
  [*]Reduce the Wirespeed => no effect
  [*]Replace the Flash component on the board => no effect
[/list]


See below the Flash operation log message:

Ni: LPCXpresso RedlinkMulti Driver v8.1 (Feb 18 2016 18:44:09 - crt_emu_cm_redlink.exe build 650)
Pc: (  0) Reading remote configuration
Nc: Found chip XML file in D:/workdir/lpc_workdir/periph_blinky/Release/LPC4370.xml

Pc: (  5) Remote configuration complete
Nc: Probe Firmware: LPC-LINK2 CMSIS-DAP V5.147 (NXP Semiconductors)
Nc: Serial Number:  BYGWKSIS
Nc: VID:PID:  1FC9:0090
Nc: USB Path: \\?\hid#vid_1fc9&pid_0090&mi_00#7&1143ea45&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}
Pc: ( 30) Emulator Connected
Xs:
Xc:
Pc: ( 40) Debug Halt
Pc: ( 50) CPU ID
Nc: Emu(0): Connected&Reset. DpID: 2BA01477. CpuID: 410FC240. Info: <None>
Nc: Debug protocol: SWD. RTCK: Disabled. Vector catch: Disabled.
Nc: inspected v.2 External Flash Device on SPI C:\nxp\LPCXpresso_8.1.0_597\lpcxpresso\bin\Flash\LPC18_43_SPIFI_GENERIC.cfx
Nc: image 'LPC18/43 Generic SPIFI Feb 16 2016 09:19:36'
Nc: flash variant 'S25FL016K' detected (2MB = 32*64K at 0x14000000)
Nc: NXP: LPC4370  Part ID: 0x00000000
Pc: ( 65) Chip Setup Complete
Nt: Connected: was_reset=true. was_stopped=false
Cr:v LPCXpresso Free License - Download limit is 256K
Pc: ( 70) License Check Complete
Nt: Loading 'periph_blinky.axf' ELF 0x14000000 len 0x11A4
Nt: Writing 4516 bytes to address 0x14000000 in Flash
Pb: 1 of 1 (  0) Writing pages 0-0 at 0x14000000 with 4516 bytes
Ps: (  0) at 14000000: 0 bytes - 0/4516
Ec: op ProgramPage (0x14000000, 0x10081000, 0x4000) status 0x1 - driver reported driver error - EXTSPI driver rc 10 - Program operation failed validation or readback compare

Pb: (100) Writing Flash ended with an error.
Ed:05: File 'periph_blinky.axf' load failure: Ef(49): Flash driver operation gave error.
Pc: (100) Target Connection Failed

I am running out of ideas to solve this problem. Could you please help me to find out what I'm currently doing wrong. I hope that with your help guys, I will be able to bring those boards back to life.

Best regards,

[haraldsonntag]

Hi Rodri,

thank you so much too, your solution with lpclink2-config-tool works perfectly for me too!

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

As I already wanted to change to the next LPC Link II, I found your post.

I also had a look to your code "Test_LED" because I wanted to find-outwhat we have done both

to generate this error. We both use the USB stack and we both us a Timer Interrup And we both use the HSADC.

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

interrupt all together. The USB stack hangs-up and the error "no more programmable flash) occurs.

All further information I will write on

Flash Programming on LPC4370 SPIFlash failing (as suggested by Dave) to also avoid 2 threads.

Again thank you Rodri, you saved my day.

Harry

[lpcxpresso_supp]

Are you seeing this issue with LPCXpresso IDE and it's SPIFI flash driver or with LPCScrypt or both. And with which versions?

Can you provide a log of the actual output that you see?

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]

Folks,

For the purpose of avoiding two threads diverging and covering the same material, there is material related to this question (including a reply to the inquiry posted directly above) over at;

https://community.nxp.com/thread/434100 

[olivierswinkels]

Hi,

I'm having exactly the same issues with the LPC4370 and a W25Q64FVSSIG flash chip.

The only way I can get it unbricked is to solder a new flash chip on the board (currently on my 8th chip arg!). 

Does anyone have a real solution yet?

[lpcware]

bump

[lpcware]

Content originally posted in LPCWare by rodri on Thu Mar 17 08:49:04 MST 2016
Hi NXP,

If you test my code (release version) with "program device" option several times, changing a little bit the code between programs, other case verification process always will be sucessful even the memory is bricked, you will see that after 3 or 5 (may be more) program operations the device becomes locked.

regards

[lpcware]

Content originally posted in LPCWare by lpcxpresso-support on Thu Mar 17 04:49:02 MST 2016

---

Quote: einsiek
Could it be caused by the new SPIFI generic driver?

---

I think this is very unlikely - this driver is a variant of our previous drivers only differing in that it reads device information when invoked and dynamically configures. We test extensively with this driver on our test farm and we have never seen this problem. Furthermore the example supplied by 'Rodri' was configured to use a different driver.

The erase/program scheme you describe is standard and again tested routinely with a large number of boards.

I believe the answer lies within a 'bricked' device. If you still have such a device available for testing, please let us know.

Yours,

LPCXpresso-support

[lpcware]

Content originally posted in LPCWare by einsiek on Wed Mar 16 12:28:36 MST 2016
Could it be caused by the new SPIFI generic driver?

I use a Winbond Flash (W25Q80BVSSIG) with the LPC18_43_SPIFI_GENERIC.cfx. (C:\nxp\LPCXpresso_8.1.0_597\lpcxpresso\bin\Flash\LPC18_43_SPIFI_GENERIC.cfx).

Here is procedure that I use to program the Flash:
[list]
  [*] Click on "Program Flash" button (Program Flash using LPC-Link2 CMSIS-DAP V5.147)
  [*] use JTAG interface => unchecked
  [*] Reset target on completion => checked
  [*] Flash Driver => LPC18_43_SPIFI_GENERIC.cfx
  [*] Erase Options => Mass erase
[/list]

I hope this will help.

Best regards

[lpcware]

Content originally posted in LPCWare by lpcxpresso-support on Wed Mar 16 11:12:54 MST 2016
There are 3 questions posed by this thread:

1 - why are these devices becoming unresponsive to a program or erase operation within LPCXpresso IDE.

We have investigated and so far have been unable to reproduce the failure on an LPC4370 Link2 board target.

From the datasheet of the SPI flash part on this device we can speculate that write protection has been erroneously set, but it remains unclear why this has occurred.

2 - why is LPCScrypt unable to recover the device.

LPCScrypt is built on the LPCOpen SPIFI library (as are the flash drivers supplied with LPCXpresso IDE). The SPIFI initialisation performed by LPCScrypt will attempt to clear any block protection active on this device - and in local testing it is successful in doing so. 

However, from the information supplied on this thread, this does not appear to be successful for the 'frozen' devices.

3 - why is the LCT tool able to recover the device.

Again from the information supplied - it appears that the initialisation performed by LCT is able to clear whatever has blocked these devices.

We will continue to investigate this matter and will post to this thread will additional findings.

It would be most useful for us to get any more information on how the SPI flash parts can be put into this state.

Yours,

LPCXpresso-support

[lpcware]

Content originally posted in LPCWare by einsiek on Tue Mar 15 17:51:20 MST 2016
Hi Rodri,

Thank you sooooooo much....Your solution works perfectly! Thanks to you, I was able to unlock my dead boards.

@LPC Support
Do you have any feedback on the possible root cause of this issue?
Is it possible to do the operation described by rodri using LPCScript instead of the obsolete "LPC-Link2 Configuration Tool"?

Best regards,

[lpcware]

Content originally posted in LPCWare by rodri on Tue Mar 15 04:43:31 MST 2016
Hi Einsiek,

I think I found the solution. You need to download "LPC-Link 2 Configuration Tool", here: https://www.lpcware.com/lpclink2-config-tool

When you have it, connect a bricked link2 board to the PC, then will be automatically detected in Config tool.

1.- select Link2 CMSIS-DAP debuger with bridges, and then program images to the board. You must see that the red tabs become green.
2.- open LPCXpresso, and soft-load the debug image with linkserver.
3.- you have debricked the board, you can debug or program the flash another time.

Now the question is: why is our link2 bricking all the time?

Thanks and regards!!!

[lpcware]

Content originally posted in LPCWare by rodri on Mon Mar 14 03:51:03 MST 2016
Hi,

my program is based from examples of LPCopen, with some modifications. Basically I was testing HSADC, timers, wdt (init function commented for tests), and other modules.

Here I attach my project, can you take a look and tell me if there is some code that is causing errors?

thanks

Regards!

[lpcware]

Content originally posted in LPCWare by lpcxpresso-support on Fri Mar 11 12:39:40 MST 2016

---

Quote: rodri


Yesterday I bought 2 more boards, today I've locked one of these, taking care about don't repeat the same procedure that bricked my 2 boards last day. So this was not the problem.

---

We have LPC-Link2 boards here in our test system that have had their flash programmed literally thousands of times.

All I can suggest is that your issues might be down to the image that you are programming into them? What actually are you programming into your boards?

Regards,
LPCXpresso Support

[lpcware]

Content originally posted in LPCWare by rodri on Fri Mar 11 11:07:49 MST 2016
Hi NXP,

Yesterday I bought 2 more boards, today I've locked one of these, taking care about don't repeat the same procedure that bricked my 2 boards last day. So this was not the problem.

What about that error? I don't understand why there is not a solution apart of changing the flash memory.

I'm working at a high speed, so I need to be continously programming the memory, not debugging, I can ony make 4 program loads before the brick. I need a solution.

thanks and regards.

[lpcware]

Content originally posted in LPCWare by einsiek on Wed Mar 09 16:50:18 MST 2016
So, I have try to erase, re-program and verify my 4 locked boards using LPCScrypt. I was able to unlock one board. The 3 other boards are still locked.
FYI, the 3 locked boards are the one that I have locked during the same afternoon last week (So I share the same frustration than rodri). The one I manage to unlock was locked since a couple of months (apparently due to a different issue).

I observe exactly the same behavior than rodri during the SPIFI erase on the locked boards. The erase process is almost instantaneous but when I reset the board the old firmware is still there. When I erase a working board it usually takes a couple of seconds.

Here is the complete list of the LPCScrypt command that I have used:

C:\nxp\LPCScrypt>scripts\boot_lpcscrypt.cmd
Booting LPCScrypt target with "LPCScrypt_83.bin.hdr"
LPCScrypt target booted

C:\nxp\LPCScrypt>bin\lpcscrypt.exe erase SPIFI
Erasing SPIFI ... completed in 1.627s

C:\nxp\LPCScrypt>bin\lpcscrypt.exe program "d:\myproject\Release\myprogram.bin" SPIFI
.
Programmed 16296 bytes to 0x14000000 in 0.043s (369.879KB/sec)

C:\nxp\LPCScrypt>bin\lpcscrypt.exe verify "d:\myproject\Release\myprogram.bin" SPIFI
.
Verified 16296 bytes to 0x14000000 in 0.014s (1147.125KB/sec)

Those commands were executed on a working board. When executed on a locked board, the "verify" command fails.

I have then desoldered the Flash from one locked board in order to replace it by a brand new Flash component (W25Q80BVSSIG => same Part ID than the original).
After this Flash swapping the board was working perfectly.

So, it seems indeed that the Flash is either locked or dead.

In order to answer some of the question asked by LPCXpresso Support, I would like to precise that my application code did not interact with the SPIFI flash.
I have used the new project wizard to create my project. I haven't modified the default SPIFI settings (or at least not on purpose).

Is there a way to read/write the SPIFI Flash registers from either LPCXpresso or LPCScrypt?

Best regards,

[lpcware]

Content originally posted in LPCWare by rodri on Wed Mar 09 12:17:22 MST 2016
When I execute the Lpcscrypt batch "program LPC-link2 with CMSIS-DAP":

---

Quote:
LPCScrypt - CMSIS-DAP firmware programming script v1.7 Feb 2016.

Connect an LPC-Link2 or LPCXpresso V2/V3 Board via USB then press Space.

Press any key to continue . . .

.
Programming LPC-Link2 with "LPC432x_CMSIS_DAP_V5_147.bin.hdr"
Probe LPC-Link2 programming failed:
Error: <Command line>:1: Verify Error 0xb 0x14000000
   Script cmd:      program C:\nxp\LPCScrypt\probe_firmware\LPCLink2\LPC432x_CMS
IS_DAP_V5_147.bin.hdr SPIFI
   Last target cmd: =programPage 14000000 6b
Terminated with errors

Usage:
Connect a LPC-Link2 or LPCXpresso debug probe configured to DFU-Boot.
This script will program the probe with a CMSIS-DAP image.
The following arguments are accepted:
                [Programs Bridged CMSIS-DAP Image]
NB              [Programs Non Bridged CMSIS-DAP Image]
"path to bin"   [Programs the chosen binary]
Press any key to continue . . .

---

Link2 can work as a debuger, but can't be programmed, not seems broken. It is a problem of the memory write op.

when I try to erase:

---

Quote:

c:\nxp\LPCScrypt\bin>lpcscrypt erase SPIFI
Erasing SPIFI ... completed in 0.002s

---

It seems OK.

The first Link2 worked until the 3rd "program flash" operation, the second link2 worked until 15th program op, all bricks on the same day in a 2 hours lapse.
Please helpme, my intention is not to buy 500 link2 more in order to perform 1 or 2 tests.

thank you
regards.

[lpcware]

Content originally posted in LPCWare by lpcxpresso-support on Wed Mar 09 10:32:55 MST 2016
From memory, I'm not sure if the "incoming" debug connector on the LPC-Link2 board has the ISPreset pin connected to the LPC4370.

But if you ensure that JP1 is open before connecting your LPC-Link2 to your PC, then you may then be able to use LPCScrypt to erase whatever you have programmed into the SPIFI flash that has put the board into its current state.

https://www.lpcware.com/lpcscrypt

If that doesn't work, then it probably means that you have broken your LPC-Link2 board in a much more fundamental way.

Regards,
LPCXpresso Support

[lpcware]

Content originally posted in LPCWare by rodri on Wed Mar 09 08:27:27 MST 2016
Hi,

I'm having the same problem, "load failure: Ef(49): Flash driver operation gave error." with my LPC Link2. As Einsiek says, I tried (also without effect), to perform an ISP reset by software (with the script ISPResetConnect.scp and/or enabling vectorcatch) and by hardware by GNDing the TP-ISP of the board. But I can't write to memory or debug my program.

When I enable the vectorcatch option, i receive this other message on the console:

---

Quote:
Serial Number:  JQD4B0CR
VID:PID:  1FC9:0090
USB Path: \\?\hid#vid_1fc9&pid_0090&mi_00#7&1fdcfc99&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}
Vector catch on SYSRESETREQ signal
Cannot halt processor
Cannot halt processor
Emu(0): Connected&Reset. DpID: 4BA00477. CpuID: 410FC240. Info: <None>
Debug protocol: JTAG. RTCK: Disabled. Vector catch: Enabled.
Cannot halt processor
Failed on chip setup: Ep(04). Cannot halt processor.

---

What I can do?

I think that this is the procedure that causes memory bricks (in my case):
1. Write release version of the program to the memory with LPCXpresso using a 2nd link2. (JP1 removed)
2. Jumper on JP1 and remove JTAG wire.
3. Reset the board
4. When the firmware is running, remove JP1.
*Now the memory is bricked at the next reset

Wich are the procedures in order to debrick the memory? I have my 2 link2 bricked at this moment!

thank you!
regards.

[lpcware]

Content originally posted in LPCWare by lpcxpresso-support on Tue Mar 08 18:51:00 MST 2016
The problem is not CRP related. You have debug access to the target. Ensuring you have adequate power leaves the possibility the sector became protected, but the CRP has nothing to do with a protected sector on the external flash device. So, the question remains whether a (previously loaded) application has set the sector protect? Let us know if this is a possibility.

The external flash device is the Winbond W25Q80BVSSIG. Here is a link to the datasheet.

http://www.winbond.co.jp/resource-files/da00-w25q80bvh1.pdf

Thanks and regards,
LPCXpresso Support

[lpcware]

Content originally posted in LPCWare by einsiek on Tue Mar 08 17:52:04 MST 2016

I have discovered that I'm also unable to erase the flash. So it really looks like some/all sectors of the external SPIFI Flash are locked. It's surprising considering the fact that my program use the default CRP settings (generated by the new project wizard).

#if defined (__CODE_RED)
#include <NXP/crp.h>
// Variable to store CRP value in. Will be placed automatically
// by the linker when "Enable Code Read Protect" selected.
// See crp.h header for more information
__CRP const unsigned int CRP_WORD = CRP_NO_CRP ;
#endif

Could you please point me to a doc or an application note explaining how to check if Flash sectors are locked and more importantly, how to unlock them. I was not able to find such documentation. I found an application note (AN10851) about the Code Read Protection, but it uses Flash Magic which unfortunately doesn't support the LPC4370. FYI, currently I only have JTAG/SWD connections to load/debug the firmware. I hope that it is possible to modify the CRP mode without using the ISP.

By despair, I have tried, once again, all the method listed here => Regaining debug access to target MCU   
When I try to debug the MCU with vector Catch enabled, it give me a different error (see below):

15: Target error from Commit Flash write: Ef(34): Timed-out initializing flash.

This error seems to be also related to an issue during the verification of the Flash. Which apparently could be caused by an insufficient power being supplied to the target while programming the flash. I have tried to power up the target board with a dedicated power supply. Unfortunately it didn't have any effects.

Best regards,