Cannot connect with hw debugger JTAG to IMX7D after Linux boots

I’m using the Colibri iMX7D 512 module & Aster board, as purchased from Toradex. The SoC has software as programmed by Toradex before shipping. (or Colibri eval board, same result)

I’m trying to do work on M4 core, with hardware debugger with JTAG interface. I’m using Segger J-Link Plus, and latest soft package they supply - V6.20i.

I’m testing on example project(s) as provided by NXP, and, targeted for SABRE iMX7D board. But this is not relevant for my question, see below.

The problem I have is that the debugger cannot connect to the M4 or A7 core _if Linux has booted _ (don’t know at which stage).

I can successively connect to M4 or A7 cores iff only u-boot is running and before it starts Linux.
So for example
JLinkExe -device MCIMX7D7_A7_0 -autoconnect 1 -if JTAG -speed 4000 -JTAGConf -1,-1
JLinkExe -device Cortex-M4 -autoconnect 1 -if JTAG -speed 4000 -JTAGConf -1,-1

Both cases connect, and then I can do setup required to upload the M4 code and run & debug it. Tested with “hello_world” FreeRTOS based example.

But things break after Linux has started. It is not possible to connect anymore to either core.
See below messages / errors:

A7

JLinkExe -device MCIMX7D7_A7_0 -autoconnect 1 -if JTAG -speed 4000  -JTAGConf -1,-1


SEGGER J-Link Commander V6.20i (Compiled Nov 17 2017 17:33:21)
DLL version V6.20i, compiled Nov 17 2017 17:33:15
Connecting to J-Link via USB...O.K.
Firmware: J-Link V10 compiled Nov 14 2017 11:13:00
Hardware version: V10.00
S/N: 600000226
License(s): RDI, FlashBP, FlashDL, JFlash, GDB
VTref = 3.373V
Device "MCIMX7D7_A7_0" selected.

Connecting to target via JTAG
***************************************************
J-Link script: iMX7D Cortex-A7_0 core J-Link script
***************************************************
TotalIRLen = 4, IRPrint = 0x01
JTAG chain detection found 1 devices:
 #0 Id: 0x5BA00477, IRLen: 04, CoreSight JTAG-DP
**************************
WARNING: Identified core does not match configuration. (Found: None, Configured: Cortex-A7)
**************************
***************************************************
J-Link script: iMX7D Cortex-A7_0 core J-Link script
***************************************************
TotalIRLen = 4, IRPrint = 0x01
JTAG chain detection found 1 devices:
 #0 Id: 0x5BA00477, IRLen: 04, CoreSight JTAG-DP

****** Error: Could not power up debug port: Control/Status register reads 40000003
***************************************************
J-Link script: iMX7D Cortex-A7_0 core J-Link script
***************************************************
TotalIRLen = 4, IRPrint = 0x01
JTAG chain detection found 1 devices:
 #0 Id: 0x5BA00477, IRLen: 04, CoreSight JTAG-DP
***************************************************
J-Link script: iMX7D Cortex-A7_0 core J-Link script
***************************************************
TotalIRLen = 4, IRPrint = 0x01
JTAG chain detection found 1 devices:
 #0 Id: 0x5BA00477, IRLen: 04, CoreSight JTAG-DP
Cannot connect to target.

M4

JLinkExe -device Cortex-M4  -autoconnect 1 -if JTAG -speed 4000  -JTAGConf -1,-1 

SEGGER J-Link Commander V6.20i (Compiled Nov 17 2017 17:33:21)
DLL version V6.20i, compiled Nov 17 2017 17:33:15
Connecting to J-Link via USB...O.K.
Firmware: J-Link V10 compiled Nov 14 2017 11:13:00
Hardware version: V10.00
S/N: 600000226
License(s): RDI, FlashBP, FlashDL, JFlash, GDB
VTref = 3.373V
Device "CORTEX-M4" selected.

Connecting to target via JTAG
TotalIRLen = 4, IRPrint = 0x01
JTAG chain detection found 1 devices:
 #0 Id: 0x5BA00477, IRLen: 04, CoreSight JTAG-DP
Scanning AP map to find all available APs
AP[0]: Stopped AP scan as end of AP map seems to be reached
Iterating through AP map to find AHB-AP to use
Scanning AP map to find all available APs
AP[0]: Stopped AP scan as end of AP map has been reached
Iterating through AP map to find AHB-AP to use

****** Error: Bad JTAG communication: Write to IR: Expected 0x1, got 0xF (TAP Command : 10) @ Off 0x5.
Could not find core in Coresight setup
Cannot connect to target.

Another A7 attempt

Connecting to target via JTAG
***************************************************
J-Link script: iMX7D Cortex-A7_0 core J-Link script
***************************************************
TotalIRLen = 4, IRPrint = 0x01
JTAG chain detection found 1 devices:
 #0 Id: 0x5BA00477, IRLen: 04, CoreSight JTAG-DP
CoreSight AP[0]: 0x04770001, AHB-AP
CoreSight AP[1]: 0x04770002, APB-AP
CoreSight AP[2]: 0x0477000F, Unknown-AP (Reserved)
CoreSight AP[3]: 0x0477000F, Unknown-AP (Reserved)
CoreSight AP[4]: 0x04770001, AHB-AP
ROMTbl[0][0]: CompAddr: 80040000 CID: B105100D, PID:00-00080000 ROM Table
Invalid ROM table component ID 0x100DD3D3 @ 0x80040FF0 (expected 0xB105100D). Trying again at alternative offset.
***************************************************
J-Link script: iMX7D Cortex-A7_0 core J-Link script
***************************************************
TotalIRLen = 4, IRPrint = 0x01
JTAG chain detection found 1 devices:
 #0 Id: 0x5BA00477, IRLen: 04, CoreSight JTAG-DP

****** Error: Cortex-A/R-JTAG (connect): Could not determine address of core debug registers. Incorrect CoreSight ROM table in device?
***************************************************
J-Link script: iMX7D Cortex-A7_0 core J-Link script
***************************************************
TotalIRLen = 4, IRPrint = 0x01
JTAG chain detection found 1 devices:
 #0 Id: 0x5BA00477, IRLen: 04, CoreSight JTAG-DP
***************************************************
J-Link script: iMX7D Cortex-A7_0 core J-Link script
***************************************************
TotalIRLen = 4, IRPrint = 0x01
JTAG chain detection found 1 devices:
 #0 Id: 0x5BA00477, IRLen: 04, CoreSight JTAG-DP
Cannot connect to target.

And there may be slightly more versions of the same …

Is there configuration conflict with Linux kernel preventing JTAG access to the core(s) after boot?

I observe that I have the same trouble on NXP’s SABRE board - after Linux starts I cannot connect & debug code.
On some random occasions on SABRE it seems to succeed, but then the entire chip/SoC gets reset sometime at or after trying to upload M4 code.

Anyone resolved this? A help would be appreciated in this regard.

(I’ve asked a day ago on the NXP forum too, but had no answers or suggestions of any sort yet)

Hey Stefan,
Thanks for quick response.

I’m testing and will report back. (Seems like it can sometimes connect with this argument)

Hi Stefan,

Thanks for that suggestion, and I also reviewed Toradex’s link here :

and added fdt_fixup to remove UART_B, to avoid kernel crash (should have started with it, apologies. . Toradex does excellent job documenting steps for developers).

However, I can say it only partially fixed the problem.

Trying to connect to A7 core fails ~60+% of the time. The other times when it does connect, it complains that could not be halted, and started, and trying to read/write any registers fails. After few such A7 attempts the chip seems to get hard locked (i only judge by the non-responsive serial console; i guess wdog would reset it if it would really hardlock), requiring power cycle. If not powercycled, I observed that rebooting back to u-boot still does not allow to connect to either core.

Ok, but leaving all A7 core(s) to Linux, which I hope I won’t need to debug with JTAG.

So with your suggested change to add parameter ignore unused clocks, I can then connect to the M4 core after Linux is booted. I’ve tested so far with hello_world, and (with a bit customized reset on the Segger side) I can enable and connect to M4, and load the code & debug it. Also booting back to u-boot, without full reset / POR, still allows to upload same code & debug it.

So far no issue I’ve seen, but of course I need to try a more complex example, probably the RPMSG hello next. I’ll play around and come back if I have more issues I guess.

I just want to say thanks so much to you on how fast you reply, and give support/ help. I really love this about Toradex.
Thanks again.

Can you try using the ignore_unused_clks kernel boot argument (e.g. by calling setenv defargs ignore_unused_clks in U-Boot).

Connecting to A7 cores probably would require to deactivate runtime suspend/low power modes in Linux (e.g. disable kernel config CONFIG_CPU_IDLE)

Thank you Stefan,
I need to try this out and build a custom kernel with the change.

Btw, do you have any experience with NXP’s provided kernels? My understanding is Toradex used NXP’s provided Linux kernel & BSP, and modified that to suit Toradex’s SoC and devboards. ( Is that wrong? ).

Having trouble to get same ‘success’ on SABRE iMX7D as (with your help) on Toradex’s SoC & kernel. Each connect attempt to M4 or A7 immediately resets entire SoC, if Linux boots…
Some other conflict seems, which causes resets on Segger attempt to connect, to either core.

Yes, our Colibri iMX7 kernel is based on the NXP provided kernel.

We did some additional modification to FreeRTOS and the Linux Kernel so that we are able to load the firmware including Interrupt vectors directly to the cores vector table (see this and this commit). But not sure if it is related to that, it could also be a Watchdog running or something else…

hey Stefan,

Thank you very much for the information and the pointers.

Hello Stefan,

I’ve found these to improve results with the Toradex’s kernel as is (was) provided for iMX7D, by adding kernel boot params:

  • nohz=off : this seems to allow me always connect to A7_0 with Segger, but the HW debugger complained about not able to halt/go CPU.
  • nohlt : allows now to connect Segger with no warnings, and I’m able to halt/go A7/Linux with no issues

Thus : setenv defargs clk_ignore_unused nohz=off nohlt

are the options to add when debugging with hw debugger on iMX7D Colibri (at least in my few tests…)

Additionally this might be good to add:
nowatchdog
(but note will not prevent platform wdog reset, imx2-wdt or rn5t618-wdt; )

And this may be good:
cpuidle.off=1
(Checking that kernel config its enabled by default, but setting it to off didn’t matter so far, in my testing).

Hm, nohlt prevents the ARM kernel from using WFI… I guess this prevents the platform from triggering any power saving mechanism which interfere with JTAG. Thanks sharing the results/parameters, very helpful indeed!