JTAG Communication failure

[lpcware]

Content originally posted in LPCWare by bjorn1989 on Mon Jun 23 06:33:14 MST 2014
Hi,

I have a problem with JTAG, I am using a LPCLINK2 and a Mini4357 board. For the Mini4357 I have made a custom made pcb just for the JTAG connection and the power supply. I did made a mistake with the JTAG (switched some JTAG pins with each other) Now it is connected the right way, but I get the following message in Uvision 5. JTAG Communication failure. The first question: Is it possible that the LPC is broken? How can I check this?

If it is not broken, I did want to erase the chip with flash magic and a hart connection. But on the Mini4357 board are these pins not routed to the output. (boot settings and uart0 default ports) These pins are connected to external RAM. The IPC port is connected to the output of the board. Is there another way to set the processor back to the default settings?

I did test the LPCLINK2 with another board and that is working fine. (LPCXPRESSO LPC1769)

Thanks for your time!

Best regards,

Bjorn

[lpcware]

Content originally posted in LPCWare by bjorn1989 on Mon Jul 07 05:36:28 MST 2014
Thanks for your support, I did measure the JTAG signals and they are not floating somewhere in the middel of 3.3V. The signals are 3.3V and 0V.

The board uses 250mA and the processor is a little bit warm. I was hoping to erase the processor with Flashmagic. But this is not possible with the Mini4357 board.

I don't understand the way of testing what Pacman suggested, is there a easy way to deal with this problem?

[lpcware]

Content originally posted in LPCWare by bavarian on Mon Jun 30 06:02:45 MST 2014
Well, I won't exclude a damaged JTAG port. We have seen this effect sometimes, it is due to the different power supply domains of the board supply and the debugger supply. The voltage potential difference can be huge for a short time frame, high enough to destroy the JTAG input TDI under some circumstances.
The chip will still work fine, e.g. with the ISP mode, but the JTAG/SWD port is not longer working.
If you look at the JTAG signal(s) then you might see them floating somewhere in the middle of 3,3V

Regards,
NXP Software Support.

[lpcware]

Content originally posted in LPCWare by Pacman on Mon Jun 23 10:27:22 MST 2014
First of all: It's not very likely that you've broken your microcontroller - not at 3.3V. It's more likely that your JTAG connection still contains errors.

---

Quote: bjorn1989
But on the Mini4357 board are these pins not routed to the output. (boot settings and uart0 default ports) These pins are connected to external RAM.

---

It might be, that your RAM is holding the boot-pin low during reset, which means the microcontroller will run the boot-ROM code (and never start executing your program).

I just did something similar on the LPC812; I connected the boot-pin to a SD/MMC-card interface, and the pin was held low during reset; it took me a while to figure this out.

If you can, try measuring the voltage level on the boot-pin.

I do not think your microcontroller is broken. I've broken two myself...
[list=1]
  [*]I gave one too much heat while reflowing it.
  [*]One was zapped by a power-supply that broke down, thus it was exposed to over-voltage (13VDC).
[/list]

If you have OpenOCD, you might be able to check what's going on using the JTAG to diagnose the microcontroller.
I did something like this myself:
1: Start OpenOCD as server for port 4444.

2: Telnet into the server.

3: Type...

mdw 0 10

...That will display memory for address 0 as 32-bit words; 10 words will be displayed.

4: Type ...

reset halt

...That will stop the microcontroller from running.

5: Type ...

reg

...That will show you a list of registers. Look at the value for PC. If PC is in the boot-ROM section of your chip, then your boot-pin is most likely being held low.

6: Type ...

mdb 0x400f4047

... That will show the value of P2[7], which is the boot pin.
You can also check these pins (see UM10503, section 5.3):
[list]
  [*]0x400f4048  P2[8]
  [*]0x400f4049  P2[9]
  [*]0x400f4021  P1[1]
  [*]0x400f4021  P1[2]
[/list]...In short: 0x400f40Pp, where P is Port multiplied by 2, and p is pin.

7: You can also check the OTP word if necessary (see UM10503, section 4.4, table 13) by typing...

mdw 0x40045030

... Let's assume that you measure that your boot-pin is held low by your RAM.
How would you confirm that this is what happened ?
-There might be two options:
[list=1]
  [*]If you're using a LQFP package (either RAM or microcontroller), you might be able to lift a pin (gently!)
  [*]You might be able to cut a trace. You can repair the trace later.
[/list]-If you're using BGA packages for both RAM and microcontroller, you probably have a multi-layer PCB, and I do not know how to do the testing, if your boot-pin trace is not available on the top or bottom copper layer.