LPC4370 Cannot reliably enumerate JTAG TAPs

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

LPC4370 Cannot reliably enumerate JTAG TAPs

Jump to solution
1,936 Views
dmarples
Contributor IV

Folks,

Running LPCLink2/LPCXpresso 8.2.2 on OSX, I am trying to perform multi-core debugging of a LPC4370, but having some difficulty. If I try to configure a debug session and list the TAPs (Bug -> Debug Configurations -> Debugger -> Target Configuration -> Edit JTAG Configuration ) the first time I only see the two M0 cores, and no M4. The second time I perform the same process I only see one M0 and the third time I see no cores at all.  If I look at the logging output window the command 'CoreList 1' progressively returns less TAPs each time.

If I terminate and restart LPCXpresso I can repeat the process.  Anyone any advice please? Although I haven't tried many work-arounds yet I can't (easily) allocate TAPs to debug sessions at the moment, so I can't multi-core debug...the process above is the easiest way to highlight the problem, but it also seems to stop me being able to select the M4 for a JTAG Debug session.

DAVE

[Started server]
[Connected on port 3025]
redlink>ProbeList
Index = 1
Manufacturer = NXP Semiconductors
Description = LPC-LINK2 CMSIS-DAP V5.173
Serial Number = IQCYEVCR
VID:PID = 1FC9:0090
Path = USB_1fc9_0090_14100000_ff00
redlink>ProbeStatus
Index = 1
Manufacturer = NXP Semiconductors
Description = LPC-LINK2 CMSIS-DAP V5.173
Serial Number = IQCYEVCR
VID:PID = 1FC9:0090
Path = USB_1fc9_0090_14100000_ff00
IsOpen = FALSE
WireInitialized = FALSE
WireProtocol = JTAG
CoresConfigured = FALSE
PacketSize = 1024
Reference Count = 0
HasSWV = FALSE
HasETM = FALSE
HasJTAG = TRUE
HasSWD = TRUE
Probe Type = CMSIS-DAP
Probe Reference Count = 0
redlink>ProbeIsOpen 1
FALSE
redlink>ProbeOpenByIndex 1
Probe Handle 1 Open
redlink>WireIspReset 1
redlink>WireIsConnected 1
FALSE
redlink>WireJtagConnect 1
redlink>CoresConfigured 1
FALSE
redlink>CoreConfig 1
Number of CORES/TAPs = 3, Fully recognized: True
redlink>CoreList 1
TAP 1: 0BA01477 Core 0: M0   APID: Unknown
TAP 2: 0BA01477 Core 0: M0   APID: Unknown
redlink>ProbeList
Index = 1
Manufacturer = NXP Semiconductors
Description = LPC-LINK2 CMSIS-DAP V5.173
Serial Number = IQCYEVCR
VID:PID = 1FC9:0090
Path = USB_1fc9_0090_14100000_ff00
redlink>ProbeStatus
Index = 1
Manufacturer = NXP Semiconductors
Description = LPC-LINK2 CMSIS-DAP V5.173
Serial Number = IQCYEVCR
VID:PID = 1FC9:0090
Path = USB_1fc9_0090_14100000_ff00
IsOpen = TRUE
WireInitialized = TRUE
WireProtocol = SWD
CoresConfigured = TRUE
PacketSize = 1024
Reference Count = 0
HasSWV = FALSE
HasETM = FALSE
HasJTAG = TRUE
HasSWD = TRUE
Probe Type = CMSIS-DAP
Probe Reference Count = 0
redlink>ProbeIsOpen 1
TRUE
redlink>WireIspReset 1
redlink>WireIsConnected 1
FALSE
redlink>WireJtagConnect 1
redlink>CoresConfigured 1
TRUE
redlink>CoreList 1
TAP 1: 0BA01477 Core 0: M0   APID: Unknown
redlink>ProbeList
Index = 1
Manufacturer = NXP Semiconductors
Description = LPC-LINK2 CMSIS-DAP V5.173
Serial Number = IQCYEVCR
VID:PID = 1FC9:0090
Path = USB_1fc9_0090_14100000_ff00
redlink>ProbeStatus
Index = 1
Manufacturer = NXP Semiconductors
Description = LPC-LINK2 CMSIS-DAP V5.173
Serial Number = IQCYEVCR
VID:PID = 1FC9:0090
Path = USB_1fc9_0090_14100000_ff00
IsOpen = TRUE
WireInitialized = TRUE
WireProtocol = SWD
CoresConfigured = TRUE
PacketSize = 1024
Reference Count = 0
HasSWV = FALSE
HasETM = FALSE
HasJTAG = TRUE
HasSWD = TRUE
Probe Type = CMSIS-DAP
Probe Reference Count = 0
redlink>ProbeIsOpen 1
TRUE
redlink>WireIspReset 1
redlink>WireIsConnected 1
FALSE
redlink>WireJtagConnect 1
redlink>CoresConfigured 1
TRUE
redlink>CoreList 1

0 Kudos
1 Solution
1,145 Views
dmarples
Contributor IV

For interest I get the same result on a Linux host with CMSIS DAP V5.134 and V5.173.

HOWEVER, I've found something very interesting. We have both a 0.05" header and a 0.1" header on this board. The 0.05" goes to J7, the 0.1" to a custom header on J6.  Using J7 I CAN see all three cores....so this starts to look like a signal issue?  I've been using the 0.1" header for the past six months on variants of this board (via SWD) with no ill effects, so I have no idea what is going on, but it looks like it's something on my board rather than somewhere else.... I'll report back when I know more.

OK, update....the 0.1" header is only suitable for SWD. TDI is missing :-/ Not really sure how that created the symptoms, but it ain't going to work too well without it.

User error. Replace user and press any key.

Sorry for the WOLF!  I'll crawl back under my rock now.

DAVE

View solution in original post

0 Kudos
9 Replies
1,145 Views
lpcxpresso_supp
NXP Employee
NXP Employee

Dave,

We appreciate the update you've resolved the trouble.

Thanks and regards,

LPCXpresso Support

0 Kudos
1,144 Views
lpcxpresso_supp
NXP Employee
NXP Employee

Its unclear what you are actually trying to achieve here. You should not need to manually set things up like this.

I suggest that you delete your launch configurations in all projects, as well as the Debug/Release directories.

Then rebuild, and debug the M4 application using the Debug button in the Quickstart Panel. Choose JTAG as the connection method The latest IDE version will probably autodetect the M4 on the JTAG scan chain - but if not, select it.

Then after you have connected to the M4, debug each of the M0 applications in turn, again using the Debug button in the Quickstart panel. Make sure you pick the right M0 in each case. For more details see:  LPC43xx Cortex-M4 / M0 Multicore Applications 

All of the debug settings you make above should get saved for use in each project for the next time.

You may also find the similar FAQ for LPC54xxx parts useful, as this runs through creating multicore project and debugging them in a bit more detail (though note that this uses SWD for its connections, not JTAG : LPC541xx Cortex-M4 / M0+ Multicore Applications 

Regards,

LPCXpresso Support

0 Kudos
1,145 Views
dmarples
Contributor IV

The case I generated above was an attempt to highlight the problem and isn't one that has a useful output in itself.  I followed your suggested process for the M4 and I only get the choice of the two M0 CPUs to attach the debug session to ... the M4 does not appear at all.

So, the process I just followed is;

* Delete all debug configurations

* Delete m4_Debug.jtag from m4 Debug directory

* (There is no equivalent m0_Debug.jtag in the m0 directory)

* Create a new Debug Configuration for the m4, ensure JTAG is selected

* Click debug

* Only the M0s show as available attachment targets...do not pass go.

The trace is below....note the last four lines, which I don't really understand.

Regards

DAVE

[Started server]
[Connected on port 3025]
redlink>ProbeList
Index = 1
Manufacturer = NXP Semiconductors
Description = LPC-LINK2 CMSIS-DAP V5.173
Serial Number = IQCYEVCR
VID:PID = 1FC9:0090
Path = USB_1fc9_0090_14100000_ff00
redlink>ProbeStatus
Index = 1
Manufacturer = NXP Semiconductors
Description = LPC-LINK2 CMSIS-DAP V5.173
Serial Number = IQCYEVCR
VID:PID = 1FC9:0090
Path = USB_1fc9_0090_14100000_ff00
IsOpen = FALSE
WireInitialized = FALSE
WireProtocol = JTAG
CoresConfigured = FALSE
PacketSize = 1024
Reference Count = 0
HasSWV = FALSE
HasETM = FALSE
HasJTAG = TRUE
HasSWD = TRUE
Probe Type = CMSIS-DAP
Probe Reference Count = 0
redlink>ProbeIsOpen 1
FALSE
redlink>ProbeOpenByIndex 1
Probe Handle 1 Open
redlink>WireIspReset 1
redlink>WireIsConnected 1
FALSE
redlink>WireJtagConnect 1
redlink>CoresConfigured 1
FALSE
redlink>CoreConfig 1
Number of CORES/TAPs = 3, Fully recognized: True
redlink>CoreList 1
TAP 1: 0BA01477 Core 0: M0   APID: Unknown
TAP 2: 0BA01477 Core 0: M0   APID: Unknown

0 Kudos
1,144 Views
lpcxpresso_supp
NXP Employee
NXP Employee

There are 2 points relating to this issue:

1 - For MultiCore debug of the LPC4370 we have observed that the automatic selection of M0 devices may not be made correctly.

The LPC4370 MCU includes a M4 and two M0 (M0Sup and M0App) cores. The M0 devices appear in the scan chain as device 1 and device 2 - where device 1 corresponds to the M0Sub and device 2 as M0App. When automatic device selection is enabled (the default) then LPCXpresso IDE (version 8.2.2) will automatically select the M0Sub core before the M0App core. This may not be the desired connection order!

To override this automatic selection, go to: 'LPCXPresso IDE Preferences -> LPCXpresso -> Debug Options (Misc) -> Disable Auto-select devices on multicore targets' and untick this option.

Before performing a new debug session,  you will have to ensure that any incorrect project .jtag files are deleted - the simplest way to do this is to delete the build configuration directory within a project (Usually called Debug or Release).

The potential for automatic selection of the wrong core will be addressed in a future tools release.

2 - When a core connection is made, subsequent selections will only present available devices. For an LPC4370 you would initially expect to see 3 possible devices to debug. If this is not the case then it is likely that a target connection exists to the 'missing' device.

First ensure that the IDE does have a target connection (click the double red square to kill the debugger connection to a multi core target).

If this is not the case then launch the Mac Activity Monitor and type 'red' into the search box. Look for the process 'redlinkserv' and kill this (when running under Windows, the same operation can be performed with the Task Manager).

You should now see the 3 devices available for debug connection.

Yours,

LPCXpresso Support

0 Kudos
1,144 Views
dmarples
Contributor IV

Thanks for this.  If I use two back-to-back LPCLink2 boards I can indeed follow your auto-configuration process to get the thing going.  If I then use that established configuration on _my_ board it will not detect the M4, only the M0s....so when I try to start the M4 debug session I get the option to select between the two M0 cores....I cannot see the M4 in the JTAG chain...it is invisible.

If I try the procedure given in my first post with two back to back LPCLinks I can see all of the TAPs, even if I scan the bus repeatedly. If I replace the target LPCLink with the custom board, I firstly just see two M0s, then one M0, then nothing.

So, there is a difference between the 4370 on my board and the 4370 on the LPCLink2 board...time to dig deeper;

I can connect perfectly well to the M4 on my board using SWD. In that case the JTAG Disable bits are clear in CREG5.If I look at 0x40045030 its value is 0x04000000 so JTAG is not being disabled via the OTP either.

...a bit stuck what to look at next I'm afraid?

DAVE

0 Kudos
1,144 Views
lpcxpresso_supp
NXP Employee
NXP Employee

It is probably no surprise that we also used back to back LPC-Link2s!

I think it is worth a moment to see the low level debug view of the world, so please can you try:

1 - ensure there are no redlinkserv processes running

2 - power cycle your board and LPC-Link2 probe and ensure the probe is booted (e.g. from the IDE red boot icon)

3 - within the IDEs console view select the Redlink Server console

4 - enter the following commands (my responses in italics). Note the expected index is 1, and I have assumed this in the commands below.

probelist
Index = 1
Manufacturer = NXP Semiconductors
Description = LPC-LINK2 CMSIS-DAP V5.173
Serial Number = IQC0ETKV
VID:PID = 1FC9:0090
Path = USB_1fc9_0090_20320000_ff00

probeopenbyindex 1
Probe Handle 1 Open

wirejtagconnect 1

corelist 1

TAP 0: 4BA00477 Core 0: M4   APID: 24770011
TAP 1: 0BA01477 Core 0: M0   APID: 04770021
TAP 2: 0BA01477 Core 0: M0   APID: 04770021

5 - please post your results to this thread

Yours,

LPCXpresso Support

0 Kudos
1,145 Views
dmarples
Contributor IV

OK guys, attached below is the output from running redlinkserv from the command line....it claims to have three cores, but only reports TAPs for two. I am back in the UK today so working with a different board (same build state though).  Full markings on the chip are;

LPC4370FET256

SC3A4    26

9SD15120C

DAVE

MacBook-Pro:bin dmarples$ ps aux | grep redli
dmarples         10830   0.0  0.0  2443044    872 s000  S+    8:40am   0:00.00 grep redli
MacBook-Pro:bin dmarples$ ./redlinkserv --commandline
Could not find:redlink_ScriptProbeCoreLoadRunWithVars GetLastError = 2
redlink>probelist
Index = 1
Manufacturer = NXP Semiconductors
Description = LPC-LINK2 CMSIS-DAP V5.173
Serial Number = IQCYEVCR
VID:PID = 1FC9:0090
Path = USB_1fc9_0090_14112000_ff00


redlink>probeopenbyindex 1
Probe Handle 1 Open
redlink>wirejtagconnect 1
redlink>corelist 1
TAP 1: 0BA01477 Core 0: M0   APID: Unknown
TAP 2: 0BA01477 Core 0: M0   APID: Unknown

redlink>coreconfig 1
Number of CORES/TAPs = 3, Fully recognized: True
redlink>

0 Kudos
1,146 Views
dmarples
Contributor IV

For interest I get the same result on a Linux host with CMSIS DAP V5.134 and V5.173.

HOWEVER, I've found something very interesting. We have both a 0.05" header and a 0.1" header on this board. The 0.05" goes to J7, the 0.1" to a custom header on J6.  Using J7 I CAN see all three cores....so this starts to look like a signal issue?  I've been using the 0.1" header for the past six months on variants of this board (via SWD) with no ill effects, so I have no idea what is going on, but it looks like it's something on my board rather than somewhere else.... I'll report back when I know more.

OK, update....the 0.1" header is only suitable for SWD. TDI is missing :-/ Not really sure how that created the symptoms, but it ain't going to work too well without it.

User error. Replace user and press any key.

Sorry for the WOLF!  I'll crawl back under my rock now.

DAVE

0 Kudos
1,144 Views
dmarples
Contributor IV

Hi,

I'm afraid I can't do this right now as I'm stuck in an Airport terminal, but I did try something extremely similar with;

./redlinkserv --commandline

...earlier in a terminal window, then entering the commands from the window pasted above. The result was that it only reported the M0s (i.e. TAPs 1 & 2).  I will do it again for completeness when I have a test rig set up but its unlikely to be until tomorrow now. It's worth noting the slightly strange output from up above where only TAPs 1 & 2 are reported in exactly the same way.  I did check that there was no redlinksrv process already running before I did it, but it looks like TAP 0 has already been claimed somehow.

I'll do some investigation across both OSX and Linux tomorrow and see what I can report back. Thanks for the help on this guys.

DAVE

0 Kudos