LPC-LINK to my HW

[lpcware]

Content originally posted in LPCWare by cwpjr on Sun Apr 28 18:33:36 MST 2013
02: Failed on connect: Ee(07). Bad ACK returned from status - wire error.
Emu(0): Connected. Was: None. DpID:     EDB6. Info: WIN64HS12

I will be scoping out the swd signals on a NXP LPCXpresso board vs my HW,

I have continuity on all four SWD connections to target.

All online help does not illustrate the sequences I expect to see. And nowhere can I find info on the MI command that fails to execute sometimes.

Any doc I'm missing?

Thanks, Clyde

[lpcware]

Content originally posted in LPCWare by cwpjr on Thu May 02 18:03:06 MST 2013
Yes the RESET pin for the 1114 series has a bar over it indicating RESET is Active when Low.
http://www.nxp.com/documents/data_sheet/LPC111X.pdf

All boards being reported on HERE are the original NXP LPCXepresso 1114 board called OM11049

The uncut board that has reset low (ground) during the debug session is

The cut board has reset low (after plugging in micro usb) until the LPC-LINK USB init completes, when I request the first download/debug session, then it goes high. Doesn't matter if my board is plugged in or not.

[lpcware]

Content originally posted in LPCWare by R2D2 on Thu May 02 16:18:53 MST 2013

---

Quote: cwpjr
First is the uncut one - reset always low, never asserted during debug session.

---

Your LPC is in reset (low=active) during your debug session? Must be a new type of MCU.

[lpcware]

Content originally posted in LPCWare by cwpjr on Thu May 02 16:07:03 MST 2013
Want to post my original observations re SWD debug of my 1114 board.

I monitored the SWD reset line on an intack NXP LPCXpresso OM11049 board and then with LPC-LINK cut board to my board.

First is the uncut one - reset always low, never asserted during debug session.

Second is cut board - Reset goes high and remains high after USB LPC-Link init.
An initial command seems to be sent to my board, which see RESET HIGH.
I assume if it were not high they might talk. As the error message I posted shows up.

Reset is high on the cut LPC-Link board after USB iniy whether it is connected to my board or not.

[lpcware]

Content originally posted in LPCWare by MikeSimmonds on Tue Apr 30 01:20:22 MST 2013
[FONT=Tahoma][SIZE=1][SIZE=2]Clyde, see this excellent set of blogs on the LPCware site[/SIZE]

[/SIZE][/FONT][SIZE=1]http://www.lpcware.com/content/blog/introduction-cortex-serial-wire-debugging-part-one
http://www.lpcware.com/content/blog/introduction-cortex-serial-wire-debugging-part-two
http://www.lpcware.com/content/blog/introduction-cortex-serial-wire-debugging-part-three
http://www.lpcware.com/content/blog/introduction-cortex-serial-wire-debugging-part-four[/SIZE]
[FONT=Tahoma][SIZE=2]
Cheers, Mike

[/SIZE][/FONT][FONT=Tahoma][SIZE=1]

[/SIZE][/FONT]

[lpcware]

Content originally posted in LPCWare by R2D2 on Mon Apr 29 23:08:33 MST 2013

---

Quote: cwpjr
Or in the case of any custom HW - I have a factory new chip thats never been connected to. What is it's known state.:)

---

Empty. So there's no valid checksum entry and it's starting in ISP.

---

Quote: cwpjr
So All I can do is look at the signal;s and report what I see. Feels like I'm blinded asking for help.

---

First thing to do is to switch to ISP and enable Vector catch. Then check your hardware. That's not too difficult, because ISP doesn't need much.
With connected power, SWD and pullups for Reset and ISP, SWD is working.

If you leave ISP and start your code, there are a lot of other things which can disturb your SWD. But until now I don't know which MCU you are using and which hardware. Also I don't know what you've tried already. Feels like a blind asked for help.

[lpcware]

Content originally posted in LPCWare by TheFallGuy on Mon Apr 29 20:05:47 MST 2013
From your description, this looks like either a power problem or a signal integrity issue.

Not sure what information you are looking for on the 'protocol'. This is defined by ARM and will be described their  Cortex-Mx reference manual.

Failed MI command means that a command the debugger issued failed. Look in the GDB Traces log to find out which one. But I can guarantee that it won't help you.

As daniel said, this is a hardware problem in your design and the software can only report what is going wrong. It can't tell you what is wrong with your design.

[lpcware]

Content originally posted in LPCWare by cwpjr on Mon Apr 29 17:43:31 MST 2013
I have reviewed all the wiki links. I am waiting for a scope in the morning.

The thing is there is only hints as to what the protocol is. For example I expect the SWD lines to pulse Reset first, from hints seen in the debug sessions I've done with known good hw (like a nxp OM11049 board) where the debug console reports connected /reset.

Yet when that same console reports bad ack there is nothing about available about what the command is that was supposed to be ack'd,

Or what MI command failure means.

Or in the case of any custom HW - I have a factory new chip thats never been connected to. What is it's known state. Does it differ from a programmed part - hints say there are differences but nowhere is there a state diagram of this.

So All I can do is look at the signal;s and report what I see. Feels like I'm blinded asking for help.

Cheers, Clyde:)

[lpcware]

Content originally posted in LPCWare by daniel.widyanto on Sun Apr 28 19:23:41 MST 2013
Have you seen this: http://support.code-red-tech.com/CodeRedWiki/HardwareDebugConnections

[lpcware]

Content originally posted in LPCWare by R2D2 on Sun Apr 28 19:14:35 MST 2013
There are several threads about LPC-Link and own boards here. Usually it's a hardware problem.