05: File 'C2010ARM.axf' load failure: Ef(4). Flash write operation failed.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by LakeLover20 on Tue Mar 13 10:03:32 MST 2012
I'm trying to program a LPC1767 using Red Suite 3. I'm getting the following error message -
05: File 'C2010ARM.axf' load failure: Ef(4). Flash write operation failed.
Yet the device seems to be programmed. The load cycle goes up to 114%. What does all this mean? Is all my code getting programmed to the device? Any help would be appreciated.

side question- is there a document which lists all the error codes?

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Ex-Zero on Wed Mar 14 00:46:02 MST 2012
Starting a debug session (LPCXpresso 4.2 / LPC-Link / LPC1769) with enabled 'Vector catch' shows 2 resets here :eek:

I always thought that's a 'Vector catch' reset before SWD is started and a reset to start program after downloading :confused:

http://flic.kr/p/bq1DfJ

Note: LPC-Link doesn't use this external reset with other MCUs like LPC13XX or LPC11XX :rolleyes:

lpcware · ‎06-15-2016

Content originally posted in LPCWare by CodeRedSupport on Tue Mar 13 21:14:41 MST 2012

Quote: Zero
LPC-Link can toggle Reset, you should ensure that 'Vector catch' is enabled and you are using LPCXpresso 4:

To clarify, LPC-Link resets the part using the SYSRESETREQ and/or VECTRESET mechanisms, but does not toggle the external reset signal (SRST) connected to the debug header.

Regards,

CodeRedSupport

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Ex-Zero on Tue Mar 13 17:18:43 MST 2012

Quote: LakeLover20
...LPC-Link can not toggle RESET (SRST) if it detects a reset problem...

LPC-Link can toggle Reset, you should ensure that 'Vector catch' is enabled and you are using LPCXpresso 4:

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

lpcware · ‎06-15-2016

Content originally posted in LPCWare by LakeLover20 on Tue Mar 13 17:07:42 MST 2012
I found out from Code Red that the error "Ef(4). Flash write operation failed." means the debugger detected a problem either flashing the image, or completing a successful processor reset after flash. The probable cause is the LPC-Link that's being used to interface to the target board because the LPC-Link can not toggle RESET (SRST) if it detects a reset problem, whereas Code Red's Red Probe+ can.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by CodeRedSupport on Tue Mar 13 14:06:31 MST 2012
You didn't mention which emulator is being used, or whether you're able to connect to any known working board (e.g. LPCXpresso1768, etc.). Do you have an LPCXpresso board with you that you can test with the development environment? If you can, it suggests your there is a production or design problem with the board.

Also, it would be a good idea to recommend to your customer to upgrade to the latest RedSuite 4 release.

Regards,

CodeRedSupport

Edit: It may be there's nothing wrong with the flash operation itself. The flash may have successfully programmed, but the debugger is not able to reset the part (reported as a "Flash write operation" failure). Is there any indication code is running after power cycling the board?

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Ex-Zero on Tue Mar 13 11:54:40 MST 2012
That's not very informative at all :(

I would suggest to program a new board with FlashMagic via ISP (UART0). That's very reliable and wiring problems with SWD don't disturb this method.

Also it's a good idea to use a simple working program (like LED blinking).

If that's working, next step is to use SWD. That's what I'm doing with my new boards :)

lpcware · ‎06-15-2016

Content originally posted in LPCWare by LakeLover20 on Tue Mar 13 11:31:11 MST 2012
Hello Zero- I am a NXP FAE in TX, trying to help resolve a production issue. One of my customers is using Xytronics to manufacture a new board with a LPC1767. Xytronics is trying to use Red Suite 3 to program the customer’s binary into the device on the board. They are seeing the previously mentioned error message. To answer your questions--

#1 Is it a custom board? If so, did you check your SWD wiring?
*** It is a customer board. I don't know if Xytronics double checked the wiring.

#2 Did you ever manage to flash/debug the MCU?
*** No.

#3 Did you try to flash a standard sample?
*** No.

#4 Did you switch to ISP with enabled Vector catch already?
*** No.

#5 Could you post a debug log?
*** Are you talking about the log created while the programming is going on? (I'm thinking a debug log is created while an application is executing, not while a device is being programmed.)

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Ex-Zero on Tue Mar 13 10:18:02 MST 2012
Perhaps you can provide a few more informations :rolleyes:

#1 Is it a custom board? If so, did you check your SWD wiring?

#2 Did you ever manage to flash/debug the MCU?

#3 Did you try to flash a standard sample?

#4 Did you switch to ISP with enabled Vector catch already?

#5 Could you post a debug log?