15: Target Error from Commit Flash Write

[lpcware]

Content originally posted in LPCWare by ianholmes on Tue Jan 29 03:49:36 MST 2013
We are getting this problem with the LPC1778 160 pin device, and we have run out of things that we can think of given the limited amount of information found to date on what is going on.

The project is loaded and debug pressed. It compiles and then starts to download to the Flash- and then more often than not we see this error, however if we attempt to step the code after this we see it initialise and then go to main- and it will run. This depends on which laptop/server we use to debug the hardware.

Expresso 5.0.14 seems to achieve debug more often than 4.something (I don't have this to hand). Sometimes the application ends up screwed and we have to erase it to recover. USB works when the application is loaded-which suggests to me that the clocks etc are correct.

We have monitored the chip power voltage with a 100MHz scope during programming (looks fine) and provided a 1A aux power source to our regulator in case of lack of current for Flash write.

We have (painfully) traced a chunk of the SWD process commands on the wire to verify that it is in SWD mode correctly (it is).

I believe we have a hardware mistake as the same code compiled for the 1769 and run on the demo board (Xpresso 1769) seems reliable in this respect.

I'm out of ideas- can anyone suggest anything we may have overlooked in the design - pins that might be incorrectly terminated etc?

[lpcware]

Content originally posted in LPCWare by ianholmes on Fri Feb 01 13:07:22 MST 2013
:)Evening All,

We have identified the cause of our problem. SWD is working correctly as we determined by logging the data comms on it, and the error reported is correct, the FLASH write failed. The cause of this error (for us) was a read to the EEPROM in our software.

This process causes a flag to be set in the EEPROM ISR (Address 0x0020 0FE0 - called STAT in the manual, page 874). The flag bit 26 (END_OF_RDWR)  indicates the end of a Read or Write cycle to the EEPROM.
When this flag is set it causes the Flash programming to stall (in SWD and probably in IAP use too but we have not confirmed this).

Provided that we clear this flag after the read then the flash programming part of SWD is successful.

We have checked and rechecked this and are confident of the result. If anyone knows for definate that the IAP code checks this flag for clear before each write then we can be certain. However, it works for us and as it is not at all obvious of this inter-relation between these elements we hope this observation may help someone else too.

Thanks to everyone for their support

[lpcware]

Content originally posted in LPCWare by Ex-Zero on Fri Feb 01 03:46:53 MST 2013

---

Quote: ianholmes
[SIZE=2] We have also tried linking the jpg_reset and master resets. Master reset connects to pin 24. [/SIZE]

---

:confused:

Are we talking about SWD? Then you should of course connect your SWD connector to Reset and enable Vector catch :eek:

[lpcware]

Content originally posted in LPCWare by ianholmes on Fri Feb 01 03:06:17 MST 2013
We have confirmed that we are not using the debug pins as any other function- they're dedicated pins on this device (JTAG/SWD) so we don't get that option :-)

Debug logs below

WORKING 1769 download (this is code for the 1769)

[LEFT][SIZE=2]LPCXpresso Debug Driver v5.0 (Dec 18 2012 17:03:30 build 1101)[/SIZE]
[SIZE=2]Looked for chip XML file in C:/nxp/LPCXpresso_5.0.14_1109/lpcxpresso/bin/LPC1769.xml[/SIZE]
[SIZE=2]Looked for vendor directory XML file in C:/nxp/LPCXpresso_5.0.14_1109/lpcxpresso/bin/nxp_directory.xml[/SIZE]
[SIZE=2]Found generic directory XML file in C:/nxp/LPCXpresso_5.0.14_1109/lpcxpresso/bin/crt_directory.xml[/SIZE]
[SIZE=2]Emu(0): Conn&Reset. DpID: 2BA01477. Info: WIN64HS12[/SIZE]
[SIZE=2]SWD Frequency: 3000 KHz. RTCK: False. Vector catch: False.[/SIZE]
[SIZE=2]Packet delay: 0 Poll delay: 0.[/SIZE]
[SIZE=2]NXP: LPC1769 Part ID: 0x26113F37[/SIZE]
[SIZE=2]Connected: was_reset=false. was_stopped=false[/SIZE]
[SIZE=2]v Registered license, download limit of 128K[/SIZE]
[SIZE=2]Writing 43716 bytes to 0000 in Flash (assumed clock: 100.0MHz)[/SIZE]
[SIZE=2]Verified-same page 0-7 with 32768 bytes in 1820msec[/SIZE]
[SIZE=2]Erased/Wrote page 8-10 with 10948 bytes in 1155msec[/SIZE]
[SIZE=2]Flash write Done[/SIZE]
[SIZE=2]nSRST assert (if available)[/SIZE]
[SIZE=2]Executing in user flash.[/SIZE][/LEFT]

[SIZE=2]Stopped: Breakpoint #1[/SIZE]



[SIZE=2]NON WORKING (code for the 1778)[/SIZE]

[LEFT][SIZE=2][SIZE=2]LPCXpresso Debug Driver v5.0 (Dec 18 2012 17:03:30 build 1101)[/SIZE]
[SIZE=2]Looked for chip XML file in C:/nxp/LPCXpresso_5.0.14_1109/lpcxpresso/bin/LPC1778.xml[/SIZE]
[SIZE=2]Looked for vendor directory XML file in C:/nxp/LPCXpresso_5.0.14_1109/lpcxpresso/bin/nxp_directory.xml[/SIZE]
[SIZE=2]Found generic directory XML file in C:/nxp/LPCXpresso_5.0.14_1109/lpcxpresso/bin/crt_directory.xml[/SIZE]
[SIZE=2]Emu(0): Conn&Reset. DpID: 2BA01477. Info: WIN64HS12[/SIZE]
[SIZE=2]SWD Frequency: 150 KHz. RTCK: False. Vector catch: False.[/SIZE]
[SIZE=2]Packet delay: 0 Poll delay: 0.[/SIZE]
[SIZE=2]NXP: LPC1778 Part ID: 0x27193F47[/SIZE]
[SIZE=2]Connected: was_reset=true. was_stopped=false[/SIZE]
[SIZE=2]v Registered license, download limit of 128K[/SIZE]
[SIZE=2]Writing 47524 bytes to 0000 in Flash (assumed clock: 96.0MHz)[/SIZE]
[SIZE=2]Verified-same page 0-7 with 32768 bytes in 1758msec[/SIZE]
[SIZE=2][COLOR=#ff0000][SIZE=2][COLOR=#ff0000]15: Target error from Commit Flash write: Ef(1). Timed-out writing to flash.[/COLOR][/SIZE][/LEFT]
[/COLOR][/SIZE][SIZE=2]Stopped: VectorCatch:HardF (PC was 0xC9332020) (VectorCatch)[/SIZE]


Debug connections are shown in the attachment - not R12-15 are not fitted. The processor symbox is heirachical, so I've attached that too. We have also tried linking the jpg_reset and master resets. Master reset connects to pin 24. The device is LPC1778FBD144


An download after an ISP reset ( Reset -> 0V, NMI -> 0V, NMI -> open cct, Reset -> open cct) on the 1778 of the same code gives this log

[LEFT][SIZE=2]LPCXpresso Debug Driver v5.0 (Dec 18 2012 17:03:30 build 1101)[/SIZE]
[SIZE=2]Looked for chip XML file in C:/nxp/LPCXpresso_5.0.14_1109/lpcxpresso/bin/LPC1778.xml[/SIZE]
[SIZE=2]Looked for vendor directory XML file in C:/nxp/LPCXpresso_5.0.14_1109/lpcxpresso/bin/nxp_directory.xml[/SIZE]
[SIZE=2]Found generic directory XML file in C:/nxp/LPCXpresso_5.0.14_1109/lpcxpresso/bin/crt_directory.xml[/SIZE]
[SIZE=2]Emu(0): Conn&Reset. DpID: 2BA01477. Info: WIN64HS12[/SIZE]
[SIZE=2]SWD Frequency: 150 KHz. RTCK: False. Vector catch: False.[/SIZE]
[SIZE=2]Packet delay: 0 Poll delay: 0.[/SIZE]
[SIZE=2]NXP: LPC1778 Part ID: 0x27193F47[/SIZE]
[SIZE=2]Connected: was_reset=true. was_stopped=false[/SIZE]
[SIZE=2]v Registered license, download limit of 128K[/SIZE]
[SIZE=2]Writing 47524 bytes to 0000 in Flash (assumed clock: 12.0MHz)[/SIZE]
[SIZE=2]Verified-same page 0-7 with 32768 bytes in 1743msec[/SIZE]
[SIZE=2]Erased/Wrote page 8-11 with 14756 bytes in 1373msec[/SIZE]
[SIZE=2]Flash write Done[/SIZE]
[SIZE=2]nSRST assert (if available)[/SIZE]
[SIZE=2]Executing in bootloader.[/SIZE][/LEFT]

[SIZE=2]Stopped: Breakpoint #1[/SIZE]



NOTE that the 150kHz speed setting was set by us when we wondered if there was a timeout problem.
[/SIZE]

[lpcware]

Content originally posted in LPCWare by ianholmes on Fri Feb 01 02:43:16 MST 2013
Thanks for the replies. We are looking into this now. We have noted that a reset is not issued by the debug session in a normal connect. If we force a reset with the NMI set for force ISP we are always able to get the flash programmed ok. I realise that this suggests we've set something up wrong, but also that the SWD has been able to connect to the chip and download at least a page of code to the target (if we interpret the messages correctly) before the error (write verify fail).
We are not using the debug pins for any other function - intentionally anyway. So we will check the set up.

We have noticed that our USB dma set up seems to cause an AHB exception fault too- but if we disable USB via dma the programming problem doesn't get any better so this may not be relevant. Again the (ported) code from the xx69 does not have this problem. One of the key differences we are concerned with at the moment is that the xx78 has adjustable arbiter priorities whereas the xx69 does not. The value we read for the settings has the Icode at the same priority as the peripherals and the Dcode 1 higher. The databook reset value is not what we read. Could it be that we are not reliably reading the core too?

Thanks (and apologies for the additional info if its not relevant).

[lpcware]

Content originally posted in LPCWare by steventso92 on Fri Feb 01 00:13:03 MST 2013
There are two options:
1) I usually close LPCXpresso IDE and unplug the USB, then start LPCXpresso (wait until it completely loads) and replug the USB (in this order). I use OS X so it might be different so if your under windows, just basically "reset" the workstation

2) Do not use the debugging pins as anything else such as SWCLK. If you happen to do this, you will have to reprogram the board in a special way:
http://support.code-red-tech.com/CodeRedWiki/DebugAccessChip

Hope this helps :)

[lpcware]

Content originally posted in LPCWare by CodeRedSupport on Wed Jan 30 02:05:30 MST 2013
In the first place I suggest that you look at the following FAQ

http://support.code-red-tech.com/CodeRedWiki/HardwareDebugConnections

and if this doesn't bring inspiration, then post actual details of your debug and related circuitry, plus the debug log from both a working and non-working connection:

http://support.code-red-tech.com/CodeRedWiki/DebugLog

As an aside, you say that the same code works on LPC1769. You are aware that the 176x and 177x families have quite a few differences, aren't you?

Regards,
CodeRedSupport