target error from Commit Flash write

lpcware · ‎06-15-2016

Content originally posted in LPCWare by burt on Thu Jun 02 12:57:15 MST 2011
I have a custom designed board with an lpc1754 and I get "target error from Commit Flash write" when I try to connect my lpc-link debugger. I know the power and lpc1754 are powered up, my 3.3V regulator can handle 1A and I don't see any fluctuations on the voltage line.

If I change the configuration option to NOT "load image", the lpc-link debugger connects fine. I download the code with UART ISP beforehand.

What else can cause the Commit Flash write error?

lpcware · ‎06-15-2016

Content originally posted in LPCWare by acno on Tue Aug 02 01:32:38 MST 2011

Quote: Rob65
This really looks like a power problem.
...... Rob

Thanks for your advice, but I have a long experience in this area, with several hundreds of microcontroller boards developed. I'm confident that the boards are correctly routed and the supply is correctly decoupled. Sure, there is always a better way to do things, but if you read the sequence of events on my original post, you can see that it is not possible that it is [B]"only"[/B] a supply problem.

On the board 2, powered at 3V from 2 batteries, if I use the front panel USB port (wich is routed from the mainboard to the panel with a very low quality cable), to reflash the board I must do 2 pass, systematically. I have several constraints on this board and I can tolerate this problems, but why the second try goes ok ?
Instead, if I use the rear USB port (which is directly soldered on the main board),
the error is very very rare.

The board 3, where until now I never had this problems, is the most complex. It uses the same layout and decoupling scheme (for the LPC1756 area) of the other boards with a fast I2C, ADC, DAC, PWM and an smps voltage booster to +100V/-100V. The only difference from board 2 is that when I debug it the LPC1756 is about 15cm far from the smps instead of 5cm of the other board.

The board 1 uses a fast I2C and 2 SPI and is powered by a remote board.
One of the SPI is connected to a daughter board with a MIFARE transceiver chip.
I rarely have flash programming errors on this board, but always when the daughter board (which generate a low power 13.56MHz field) is operating.

I'm sure that there is something critical in the communication path and it is influenced from EMI radiated noise. For me is not a big problem, the LPCXpresso board is very cheap and do its job completely, in the future, probably I will go with an upgrade, for examples with a RedProbe. I'm reporting this only because I think that there is room for improvements on the software management of this kind of errors, for example an automatic reset and retry would be nice instead of locking, leaving with only to unplug the USB and repeat all the debug entry steps.

Andrea

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Rob65 on Mon Aug 01 08:10:48 MST 2011

Quote: acno

1 - mains powered board (230V->12V->5V->3V)
2 - battery powered board with a step-up regulator (3V->5V->3V)
3 - battery powered board with a linear regulator (7.2V->5V->3V)

Board 1 rarely gives flash programming errors.
Board 2 is very prone to errors.
Board 3 never showed such errors.

I checked the supply line with a 200MHz scope and it is clean and in all the boards the supply section is far enough from the debug connector.

This really looks like a power problem.
During Flash programming the power requirements increase drastically.
You should really check the voltages on board 2 during Flash programming. It is most likely that you will see that there is a real problem with the 5V voltage on that board due to the fact that the step-up converter from 3V to 5V. The 5V to 3V converter (you don't tell us if that is a linear or a step-down converter) delivers an unstable output voltage due to this.

Swapping PCs may result in slower programming cycles and different power behaviour.

When developing a board always make sure there are decoupling capacitors close to the power pins (I have decoupling caps right next to the pins whenever possible) and also place proper electrolytic capacitors in your power supply.

Whenever possible use these capacitors:
[IMG]http://nl.farnell.com/productimages/farnell/standard/42264047.jpg[/IMG]
instead of these
[IMG]http://nl.farnell.com/productimages/farnell/standard/1754143-40.jpg[/IMG]

Also follow guidelines that are provided by the chip manufacturers. Switched mode converters require a specific PCB layout, there are some general guidelines to follow but most application notes contain valuable information regarding PCB layout.
This of course also goes for your complete board ...
Have a proper ground plane, make sure the 3v3 line to the controller is thick enough, place decoupling (and extra electrolytic cap.) close to the controller and always (and I mean always) route your power connections by hand.

If possible measure your 3v3 connections as close to the lpc1756 as possible and keep a close eye on the voltage during programming. When in doubt, place some extra capacitors (22 uF + 100 nF in parallel) close to the lpc1756.

On this page you'll find two photos of my latest board. On the top you see the capacitors on the left side of the lpc1754. The 3v3 line is 20 mill (0.5 mm) wide and runs all the way to the center of the lpc1754 and from there runs to the pins. The photo from the bottom of the board shows the 5 decoupling caps with extra large vias.
Up to now I have had no problems with this configuration, even ADC works fine this way.

Rob

lpcware · ‎06-15-2016

Content originally posted in LPCWare by acno on Mon Aug 01 05:23:50 MST 2011

Quote: acno

...........
I'm replying to this thread because I have a very similar issue. I develeoped three boards with the LPC1756 on them and very often I have this error

15: Target error from Commit Flash write: Et: Flash driver not ready.

I attached a log for reference, the versione of LpcXpresso is 3.6.3-317.
My application use the flash divided in two banks and the error happens while programming the second and bigger bank. On the frst try I almost always have this error, to proceed I must do this procedure:

[LIST=1]
[*]confirm the error
[*]leave the debugger active
[*]disconnect the LPC-Link from USB
[*]confirm the errors from debugger
[*]stop the debugger
[*]reconnect the LPC-Link from USB
[*]start again the debugger
[/LIST]
after this all works perfectly, until the next reprogramming.
I must add that in one of the board the supply of the microcontroller is 3.3V and this error happens rarely, on the others it is 3V and the error is systematic. I checked the LPC-Link schematic and seen that all the JTAG and SWD lines are buffered, the 0.3V difference shouldn't be an issue. I know that this difference may be the answer to my question, but therefore, why I can always reprogram the board with the above procedure ?
I even tried the mass erase with the flash programmer, but this very annoying problem is still there.
...........

Hello again!

After several tests I discovered that the original problem is not only related to the hardware of target board but to the PC used for debug too.

I used 3 different target boards all with an LPC1756 in QFP80, programmed with an LPCXpresso board connected to my desktop PC:

1 - mains powered board (230V->12V->5V->3V)
2 - battery powered board with a step-up regulator (3V->5V->3V)
3 - battery powered board with a linear regulator (7.2V->5V->3V)

Board 1 rarely gives flash programming errors.
Board 2 is very prone to errors.
Board 3 never showed such errors.

I checked the supply line with a 200MHz scope and it is clean and in all the boards the supply section is far enough from the debug connector.

But, if I use a notebook the errors disappear with only rare events on board 2. Even if I change the USB port on my desktop PC from the front to the rear the error rate drops significantly.

Probably, the USB communication quality is critical during flash programming and a switched mode supply can deteriorate it further. A good cable with a good USB hardware limit very much this problem, but I think that some improvements can be done.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by acno on Tue Jun 21 00:25:26 MST 2011
I have just developed a new board, I will make some checks on various configurations. Thanks.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by CodeRedSupport on Mon Jun 20 05:27:34 MST 2011
Your issues sound very much like power problems. When programming flash, the power requirements rise significantly. Suggest you attach a scope and see what is happening to the power during flash programming.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Ex-Zero on Mon Jun 20 04:09:39 MST 2011
Did you try Vector catch?

See:
http://support.code-red-tech.com/CodeRedWiki/DebugAccessChip?highlight=%28catch%29

lpcware · ‎06-15-2016

Content originally posted in LPCWare by acno on Mon Jun 20 02:47:03 MST 2011

Quote: CodeRedSupport
You appear to be running an older version of the tools (LPCXpresso 3.6.1 ?). In the first place, install the current tools release - LPCXpresso 3.6.3 - and see if you see the same behaviour

http://support.code-red-tech.com/CodeRedWiki/VersionInfo
http://support.code-red-tech.com/CodeRedWiki/MultipleInstallations

I would also suggest that you try doing a mass erase of the flash before you try carrying out your next debug connection - either using the flash programmer icon on the LPCXpresso icon bar, or else via flash magic (or whatever you are using to program via the UART ISP route).
...........
Regards,
CodeRedSupport

Hi,
my first post. First of all sorry for my english, it's not my native language.

I'm replying to this thread because I have a very similar issue. I develeoped three boards with the LPC1756 on them and very often I have this error

15: Target error from Commit Flash write: Et: Flash driver not ready.

I attached a log for reference, the versione of LpcXpresso is 3.6.3-317.
My application use the flash divided in two banks and the error happens while programming the second and bigger bank. On the frst try I almost always have this error, to proceed I must do this procedure:

[LIST=1]
[*]confirm the error
[*]leave the debugger active
[*]disconnect the LPC-Link from USB
[*]confirm the errors from debugger
[*]stop the debugger
[*]reconnect the LPC-Link from USB
[*]start again the debugger
[/LIST]
after this all works perfectly, until the next reprogramming.
I must add that in one of the board the supply of the microcontroller is 3.3V and this error happens rarely, on the others it is 3V and the error is systematic. I checked the LPC-Link schematic and seen that all the JTAG and SWD lines are buffered, the 0.3V difference shouldn't be an issue. I know that this difference may be the answer to my question, but therefore, why I can always reprogram the board with the above procedure ?
I even tried the mass erase with the flash programmer, but this very annoying problem is still there.

Thank You for the attention.
Andrea

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Ex-Zero on Fri Jun 03 10:23:48 MST 2011
Could help to post Power / Reset / SWD parts of your schematic :confused:

lpcware · ‎06-15-2016

Content originally posted in LPCWare by burt on Fri Jun 03 10:15:13 MST 2011
I tried enabling "Vector Catch" on, as per Zero, with no improvement in the results.

I used Flash Magic to erase the entire lpc1754 and then connect to the lpc-link with no improvement in the results.

I upgraded from lpcxpresso 3.6.2 to lpcxpresso 3.6.3 and ran lpc-link with no improvement in the results.

I tried a second lpc1754 board, virgin, never programmed, with no improvement in the results.

I am open to the possibility of an underlying hardware issue but I don't have a clue as to what that could be.

Burt.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by CodeRedSupport on Fri Jun 03 08:03:15 MST 2011
You appear to be running an older version of the tools (LPCXpresso 3.6.1 ?). In the first place, install the current tools release - LPCXpresso 3.6.3 - and see if you see the same behaviour

http://support.code-red-tech.com/CodeRedWiki/VersionInfo
http://support.code-red-tech.com/CodeRedWiki/MultipleInstallations

I would also suggest that you try doing a mass erase of the flash before you try carrying out your next debug connection - either using the flash programmer icon on the LPCXpresso icon bar, or else via flash magic (or whatever you are using to program via the UART ISP route).

But given that you also appear to be having problems running your USB code on this target - I can't help thinking that you perhaps have one underlying (hardware) issue here.

Regards,
CodeRedSupport

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Ex-Zero on Fri Jun 03 07:54:52 MST 2011
Which version are you using ?

Why is your 'Vector catch' off ?

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

lpcware · ‎06-15-2016

Content originally posted in LPCWare by burt on Fri Jun 03 07:28:00 MST 2011
I've attached a compressed file with 2 debug logs, one "normal" and one with the ISP pin grounded throughout the lpc-link process "zero".

Note that I still got the commit flash write error with the ISP pin grounded throughout the lpc-link process.

Burt.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Ex-Zero on Fri Jun 03 06:54:04 MST 2011

Quote:
I removed the ISP set signal after the board reset before connecting to the lpc-link

:confused::confused:

Ground ISP pin and don't release it before debugger is running (= initial breakpoint).

Then release ISP pin and use restart button. So your debugger resets MCU and starts debugging your new code.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by CodeRedSupport on Fri Jun 03 06:37:52 MST 2011
Please confirm what version of LPCXpresso you are running and post the debug log...

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

Regards,
CodeRedSupport

lpcware · ‎06-15-2016

Content originally posted in LPCWare by burt on Fri Jun 03 06:05:20 MST 2011
I reset my lpc1754 board with the ISP bit set, same scenario as when I download code through UART0. I removed the ISP set signal after the board reset before connecting to the lpc-link. I still get the same "target error from commit flash write". It does appear that the lpc-link actually starts the flash write before aborting.

Burt.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by CodeRedSupport on Fri Jun 03 05:15:54 MST 2011
As per the following FAQ, power issues are the most common cause of this error being seen:

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

Another possibility is that you may have managed to program some code into the flash that is preventing the debug tools fully gaining control of the system. I would suggest trying to boot into the ISP, and then seeing if you can connect successfully - as per the FAQ:

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

Regards,
CodeRedSupport