LPCXpresso with RedProbe+ won't find Target

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

LPCXpresso with RedProbe+ won't find Target

454 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by 123456789 on Thu Jul 14 09:51:21 MST 2011
Hi there,

I've bought RedProbe+ and wanna use it with LPCXpresso V4.0 under Ubuntu 11.04 linux system.

I do have a own designed board with a LPC2134 (industry quality) and 12MHz crystal.

I've checked all JTAG connections at least ten times now. I do have clean Vcc (3.3V), all 7 JTAG signals are on the connector and correcly on the LPC, I even do have a 1k PD from RTCK to GND for enabling JTAG. There are no other devices on these signals. The lines are about 2" long (LPC to 20-pin board connector).

But I didn't get a connection throught the IDE, so I tried to evaluate the problem on console:

user@computer:/usr/local/lpcxpresso_4.0.5_113/lpcxpresso/bin$ ./crt_emu_a7_nxp -info-emu
Ni: LPCXpresso Debug Driver v4.0 (Jun 27 2011 18:30:56)
1 Emulators available:
0. FTU33IYRARed Probe+ A (Code Red - Red Probe+)


I think that's OK!

But when I try to scan all devices, I'll get that:

user@computer:/usr/local/lpcxpresso_4.0.5_113/lpcxpresso/bin$ ./crt_emu_a7_nxp -info-scan
Ni: LPCXpresso Debug Driver v4.0 (Jun 27 2011 18:30:56)
 8 Devices Found:
 0. ID: 0x00000000 IR Length: ?
 1. ID: 0x00000000 IR Length: ?
 2. ID: 0x00000000 IR Length: ?
 3. ID: 0x00000000 IR Length: ?
 4. ID: 0x00000000 IR Length: ?
 5. ID: 0x00000000 IR Length: ?
 6. ID: 0x00000000 IR Length: ?
 7. ID: 0x00000000 IR Length: ?


That can't be correct, I do only have one device (the LPC2134) on the chain). There should also be a valid ID I think.

And when I try to get a target info, I'll get that:

user@computer:/usr/local/lpcxpresso_4.0.5_113/lpcxpresso/bin$ ./crt_emu_a7_nxp -info-target -pLPC2134
Ni: LPCXpresso Debug Driver v4.0 (Jun 27 2011 18:30:56)
Nc: Looked for chip XML file in /usr/local/lpcxpresso_4.0.5_113/lpcxpresso/bin/LPC2134.xml

Nc: Looked for vendor directory XML file in /usr/local/lpcxpresso_4.0.5_113/lpcxpresso/bin/nxp_directory.xml

Nc: Found generic directory XML file in /usr/local/lpcxpresso_4.0.5_113/lpcxpresso/bin/crt_directory.xml

Ed:02: Failed on connect: Ee(08). Invalid ID code from DP - cannot connect.
Et: Emu(0): Connected. Was: None. DpID:        0. Info: FTU33IYRA
Error 0: (null)
Last sticky: 0. AIndex: 0
No MemAp selected
No Speed test
JTAG Frequency: 250 KHz. RTCK: False. Vector catch: False.
Packet delay: 0  Poll delay: 0.


Any other switch won't bring a correct solution, neither "-rctk" or slowing down JTAG speed.

The LPC is responsing correctly to "lpc21isp" via UART, I can sync and read out device data. But I wanna debug! :confused:

I even observed all JTAG signals with my oszilloscope, there is a good looking Clock on TCK, some switching on TDI, TMS and RESET, but no activity on TDO!

What else can I do? What's wrong???

Thank you very much!
0 Kudos
4 Replies

398 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by CodeRedSupport on Fri Jul 15 11:31:32 MST 2011
The ARM7 debug utility does toggle SRST as a side effect provided you specify vector catch in the debug configuration. I'm not convinced you want to use this option on the LPC2134. We suggest following the power-up procedure detailed yesterday to avoid a situation where RP+ pulls RTCK high while the LPC2134 boot loader determines whether to enable JTAG.

Regards,
CodeRedSupport


Quote: 123456789
Well, I can't replicate the behavior I posted some minutes ago...

RTCLK was securely held down while I tipped RESET low, then RB+ was connected to USB.

It seems it was the first shot today. Very strange.

But: Doesn't RB+ envoke a reset themself? It would be sensless to hold down RTCLK while powering up the board when RP+ does a reset an then RTCLK would probably be high again?

Please find attached also a snapshot of some JTAG signals (channel 1=TMS, 2=TCLK, 3=TDI, 4=TDO). Besides TDO without traffic I think everything looks good?

0 Kudos

398 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by 123456789 on Fri Jul 15 03:38:54 MST 2011
Well, I can't replicate the behavior I posted some minutes ago...

RTCLK was securely held down while I tipped RESET low, then RB+ was connected to USB.

It seems it was the first shot today. Very strange.

But: Doesn't RB+ envoke a reset themself? It would be sensless to hold down RTCLK while powering up the board when RP+ does a reset an then RTCLK would probably be high again?

Please find attached also a snapshot of some JTAG signals (channel 1=TMS, 2=TCLK, 3=TDI, 4=TDO). Besides TDO without traffic I think everything looks good?
0 Kudos

398 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by 123456789 on Fri Jul 15 03:02:32 MST 2011
Hi there,

I tried what you mentioned:


Quote: CodeRedSupport

Try this:

1. First make certain power is not applied to your target board, and the RedProbe+ is not connected via the USB cable.
2. Connect the RedProbe+ JTAG cable to your target board.
3. Apply power to your target board to allow it to complete power-on reset.
4. Connect the USB cable to power up the RedProbe+.
5. Last, verify the debug connection.



After that, I'll get slightly different results:

user@computer:/usr/local/lpcxpresso_4.0.5_113/lpcxpresso/bin$ ./crt_emu_a7_nxp -info-scan
Ni: LPCXpresso Debug Driver v4.0 (Jun 27 2011 18:30:56)
 0 Devices Found:


and

user@computer:/usr/local/lpcxpresso_4.0.5_113/lpcxpresso/bin$ ./crt_emu_a7_nxp -info-target -pLPC2134
Ni: LPCXpresso Debug Driver v4.0 (Jun 27 2011 18:30:56)
Nc: Looked for chip XML file in /usr/local/lpcxpresso_4.0.5_113/lpcxpresso/bin/LPC2134.xml

Nc: Looked for vendor directory XML file in /usr/local/lpcxpresso_4.0.5_113/lpcxpresso/bin/nxp_directory.xml

Nc: Found generic directory XML file in /usr/local/lpcxpresso_4.0.5_113/lpcxpresso/bin/crt_directory.xml

Ed:02: Failed on connect: Ee(08). Invalid ID code from DP - cannot connect.
Et: Emu(0): Connected. Was: None. DpID: FFFFFFFF. Info: FTU33IYRA
Error 0: (null)
Last sticky: 0. AIndex: 0
No MemAp selected
No Speed test
JTAG Frequency: 250 KHz. RTCK: False. Vector catch: False.
Packet delay: 0  Poll delay: 0.


It seems there's still a problem in the chain? :mad:
0 Kudos

398 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by CodeRedSupport on Thu Jul 14 10:54:14 MST 2011
One theory is the LPC2134 samples RTCK at reset to determine whether to enable JTAG. The RP+ can pull RP+ high, which would mean JTAG is never enabled.

Try this:

1. First make certain power is not applied to your target board, and the RedProbe+ is not connected via the USB cable.
2. Connect the RedProbe+ JTAG cable to your target board.
3. Apply power to your target board to allow it to complete power-on reset.
4. Connect the USB cable to power up the RedProbe+.
5. Last, verify the debug connection.

$ ./crt_emu_a7_nxp -info-scan
Ni: LPCXpresso Debug Driver v4.0 (Jun 27 2011 18:30:56)
1 Devices Found:
0. ID: 0x4F1F0F0F IR Length: 4

And

$ ./crt_emu_a7_nxp -info-target -pLPC2134
Ni: LPCXpresso Debug Driver v4.0 (Jun 27 2011 18:30:56)
Nc: Looked for chip XML file in /usr/local/lpcxpresso_4.0.5_113/lpcxpresso/bin/LPC2134.xml

Nc: Looked for vendor directory XML file in /usr/local/lpcxpresso_4.0.5_113/lpcxpresso/bin/nxp_directory.xml

Nc: Found generic directory XML file in /usr/local/lpcxpresso_4.0.5_113/lpcxpresso/bin/crt_directory.xml

Pc: (  5) Remote configuration complete
Pc: ( 30) Emulator Connected
Pc: ( 40) Debug Halt
Pc: ( 50) CPU ID
Nc: Emu(0): Conn&Reset. DpID: 4F1F0F0F. Info: FTTMPRROA
Nc: JTAG Frequency: 250 KHz. RTCK: False. Vector catch: False.
Nc: Packet delay: 0  Poll delay: 0.
Nc: NXP: LPC2134  Part ID: 0x0002FF12
Pc: ( 65) Chip Setup Complete
Chip=LPC2124, from NXP (formerly Philips), in family LPC21xx, version=unknown
Chip Description: NXP LPC2134
ClockFreq=12.0MHz (Inaccurate). Clock can be changed after reset.
.
.
0 Kudos