LPC-Link can't connect after target board is power cycled

[lpcware]

Content originally posted in LPCWare by nVideon on Sun Jun 29 15:46:57 MST 2014
I am trying to use crt_emu_cm3_nxp.exe to load a 12K program into the flash memory of a custom LPC1759 design. I boot LPC_LINK and then run crt_emu_cm3_nxp.exe with the appropriate arguments and it loads the program just fine. I can rerun crt_emu_cm3_nxp.exe time after time and it works every time. The program is loaded and runs properly every time.

When I power cycle the target board and try to run crt_emu_cm3_nxp.exe again it reports:

Xe:
Ed:02: Failed on connect: Ep(01). Target marked as not debuggable.
Et: Emu(0): Connected. Was: None. DpID:     EDB6. Info: HID64HS12
Error 0: (null)
Last sticky: 0. AIndex: 0
No MemAp selected
No Speed test
SWD Frequency: 50 KHz. RTCK: False. Vector catch: False.
Packet delay: 0  Poll delay: 0.

If I then unplug the LPC-Links USB cable and replug it and boot LPC_LINK again, it then programs the board again just fine. I have built a production test system around LPC-Link to load the production program and it will unacceptable to have the tester have to unplug and replug LPC-Link's USB cable for every board that is tested.

Is there any work around?!!!!!!!

[lpcware]

Content originally posted in LPCWare by nVideon on Wed Jul 02 11:06:05 MST 2014
The issue appears have to do with pulling NMI low on power up while LPC-Link is attached, booted, and has already performed one programming cycle.

We were using a sequence that pulled NMI low, powered the board on, then released NMI before attempting to use LPC-Link to program the flash. This forces the target MCU into ISP programming mode making sure that it does not execute any already programmed code.

If we do not pull NMI low during power up with LPC-Link attached and booted then there is no problem. This does not happen with Red Probe+.

We have also found that if the ISP mode is initialized through UART 0 after powering up as describe above, then an attached and booted LPC-Link is able to work properly after power cycle. If ISP is not initialized through UART 0, then LPC-Link will fail after this kind of power cycle.

So it appears that you either need to not pull NMI low during power up or you need to initialize the ISP interface through UART 0 in order for LPC-Link to work after a power cycle.

[lpcware]

Content originally posted in LPCWare by lpcxpresso-support on Wed Jul 02 09:40:51 MST 2014
As I said, on commercial, production, boards that we have here (such as the Keil MCB1700 and the Code Red RDB1768 boards), LPC-Link works perfectly between power cycles of the target board. These boards follow the design guidelines:
http://www.lpcware.com/content/faq/lpcxpresso/debug-design

Of course you can choose to ignore the guidelines, in which case you may well have problems.

Good luck with your modifications.

[lpcware]

Content originally posted in LPCWare by nVideon on Wed Jul 02 09:14:13 MST 2014
Since there is nothing but a connector involved in the debug interface and I am using the same 10 pin .05x.05 connector as appears on the demo board, I am not sure what "hardware" I can fix?!

It is obvious from Superfred's comment that there is a serious problem with LPC-Link and power cycling the target board if the pull-up resistors are used as is specified in the debug interface design document.

Anyone reading this post should be forewarned of this issue.

I am in the process of modifying my test system to use ISP programming instead of the JTAG interface. Luckily I include test pins to the UART0 interface on the target MCU so this is possible. Anyone building a production test system with LPC-Link should be aware of this issue and plan to use ISP programming instead of relying on LPC-Link attach to the JTAG pins to program the flash on the MCU.

And I would not recommend removing the pull-up resistors on production boards leaving the JTAG lines floating. This could lead to reliability issues in the field.

[lpcware]

Content originally posted in LPCWare by lpcxpresso-support on Tue Jul 01 05:20:44 MST 2014
Using your command lines, and a commercially available board, I am able to repeatedly download an application to the target, even if I power-cycle the target board between downloads. I can only conclude that you have a problem with your board.

I can only think of one thing that you could try that MAY help. Add the option "-vc" to the command line (without the quotes).

If this doesn't work, then I think you are going to need to fix your hardware...

[lpcware]

Content originally posted in LPCWare by nVideon on Tue Jul 01 04:53:18 MST 2014
First, thanks for the help from Superfred. Unfortunately, no changes can be made to the target board at this point as production has already been set and the pull-up resistors are part of a resistor pack and can not be removed individually.

In response to lpcxpresso-support:

I am using Win 7. The exact command I am using for Red Probe + is:

\nxp\LPCXpresso_7.1.1_125\lpcxpresso\bin\crt_emu_cm3_nxp.exe -pLPC1759 -flash-load-exec=target.axf

For PC-Link, I first boot PC-Link if it has not already been booted:

cd \nxp\LPCXpresso_7.1.1_125\lpcxpresso\bin\Scripts
bootLPCXpresso.cmd

Then I return to the directory containing the target program, then I use

\nxp\LPCXpresso_7.1.1_125\lpcxpresso\bin\crt_emu_cm3_nxp.exe -wire=hid -pLPC1759 -flash-load-exec=target.axf

As I indicated before, these commands work perfectly time after time unless I power cycle the target board then PC-Link (and only PC-Link) reports that the target is not debuggable. I cannot reboot PC-Link at that point unless I unplug its UCB cable. After rebooting PC-Link I can then program the board again until I power cycle the target again. Is there a way to "reset" PC-Link with some command line command without having to unplug and replug its USB cable (Or reboot the computer)?

[lpcware]

Content originally posted in LPCWare by lpcxpresso-support on Mon Jun 30 23:40:18 MST 2014
Please post the sequence of  crt_emu_* commands that you are actually using, both for Red Probe+ and LPC-Link.

Regards,
LPCXpresso Support

[lpcware]

Content originally posted in LPCWare by Superfred on Mon Jun 30 23:39:01 MST 2014
Hi nVideon,

I also use 1759 and had also some problems with the debug interface.
After checking the 1769 LpcXpresso Board I found that there are no JTAG Pullup/Pulldown resistors at all so I removed my too except Pullup Pin 4 & 14.
Try this and if you have still problems power up in ISP mode (Pin 41 low & Reset or new Powerup), this worked for me.

To get easier into ISP mode I modified the reset circuit: Pullup Pin 14 10K + "Pulldown" via two Diodes, one connected to the Reset Switch, the other to the JTAG Reset input. So I can reset while the JTAG cable is connected.

Fred

[lpcware]

Content originally posted in LPCWare by nVideon on Mon Jun 30 05:09:34 MST 2014
I had already read all the information you pointed to me too. There is no a lot to the design of the debug interface. Also this problem does not occur with Red Probe +. With Red Probe + I can both debug and use the flash program at any time. I can power cycle the target multiple times and still both debug and use the flash programmer. I can also use Red Trace with the target with no  problems with Red Probe+. I have been debugging code on this target for several years with no issues.

With LPC-Link I can also debug and flash program over and over as long as I do not power cycle the target once I have flashed or debugged it.

The LPC-Link card I had has a LPC1769 on it and I removed (unsoldered) the trace connecting the 3.3V supply to the LPC1769 and installed a jumper so I could try the same power cycle operation. Power cycle this target did NOT have any problems.

There is not much to the debug interface. My board uses the same 10 pin .05x.05 double row connector as is on the LPC1769 demo board. I do have 10K pull up resistors on my JTAG lines which the LPC1769 demo board does not. In fact, the demo board does not follow the design guide in that it does not have any pull up/down resistors.

My design pulls TMS_CLK high whereas the design guide suggests pulling it low. I monitored TMS_CLK with a 4GHz scope with single sweep trigger with a trigger voltage of 500MV in the positive direction. After programming the target the TMS_CLK is low. I then power cycled the target several times. The TMS_CLK always stayed low. So pulling up TMS_CLK instead of pulling it down can not be the problem.

My target has a LPC1759 rather than the LPC1769 on the demo board. The resistors and the processor type are the only two differences between the two interfaces.

Any suggestions as how the debug interface is "designed" wrong since it is exactly as specified in the references you pointed me to (except the pull-up rather than pull-down resistor)?

[lpcware]

Content originally posted in LPCWare by lpcxpresso-support on Mon Jun 30 01:34:55 MST 2014
We have no such problems with the commercial LPC17xx boards we have here. I therefore strongly suspect that you have a problem with your board design.

See
http://www.lpcware.com/content/faq/lpcxpresso/target-marked-not-debuggable
http://www.lpcware.com/content/faq/lpcxpresso/debug-design