Context: I'm trying to debug an NXP LPC4357, a multi-core MCU with a Cortex M4F and M0. I'm using a J-Link v9.10 with IAR EWARM 8.22.1 on Windows 7 Pro x64, using J-Link driver 6.30h.
To debug both cores JTAG must be used. SWD can only access the M4F.
Although I'm able to debug both cores for a while via JTAG, intermittently the debugger will malfunction and send/receive nonsense data. This manifests as follows:
- The probe [and IDE] suddenly believes the core is halted when it is observably not (LEDs continue to blink, LCD is redrawn, etc)
- The core continues executing normally as if no probe is attached.
- The contents of memory and registers all read the same value like "0x0400'0000" or all zero.
- Watch variables get corrupted with incorrect values - more on this below.
- Stopping the debug session and re-attaching the debugger temporarily makes the problem disappear.
- Does not ever happen in SWD mode. SWD doesn't support dual core debug so unfortunately I can't use it a lot of the time.
- The code and the device itself are perfectly stable and never experience problems when the probe is not attached.
- It doesn't seem to be affected by the operating frequency, I tried from 250KHz up to 12MHz.
I have reproduced the issue on two separate J-Link probes both using the latest firmware and drivers. I can reproduce it fairly easily if you have any ideas to try.
I've also captured a log of this happening which I've attached to this post. During the capturing of this log, which was done by attaching to the running M4F core, a watch variable "SystemCoreClock" was overwritten to an incorrect value by the probe and all displayed registers/code/memory in the IDE read back as zero.
The overwrite of the watch variable is the reason I came to suspect the probe was responsible. After attaching the debugger and having it foul up as described above, the value in the watch window reads 0xA05F'0003 instead of the clock frequency. That's a familiar value - what the debugger should write to the DHCSR register to halt the core! But it wrote it to the wrong place somehow. And it's not just displayed wrong, it really did write to memory. I set up the core to blink an LED when the value changed and it did.
I took measures to verify it was the probe and not [as I thought it must be] my code. I set up data watchpoints on both cores to catch any writes to that variable and found nothing. I also halted the M0 and used the MPU on the M4F to fault on any write to that area. Still nothing. The only way it could be written is through the debug port.
Any idea what could be going on here?
To debug both cores JTAG must be used. SWD can only access the M4F.
Although I'm able to debug both cores for a while via JTAG, intermittently the debugger will malfunction and send/receive nonsense data. This manifests as follows:
- The probe [and IDE] suddenly believes the core is halted when it is observably not (LEDs continue to blink, LCD is redrawn, etc)
- The core continues executing normally as if no probe is attached.
- The contents of memory and registers all read the same value like "0x0400'0000" or all zero.
- Watch variables get corrupted with incorrect values - more on this below.
- Stopping the debug session and re-attaching the debugger temporarily makes the problem disappear.
- Does not ever happen in SWD mode. SWD doesn't support dual core debug so unfortunately I can't use it a lot of the time.
- The code and the device itself are perfectly stable and never experience problems when the probe is not attached.
- It doesn't seem to be affected by the operating frequency, I tried from 250KHz up to 12MHz.
I have reproduced the issue on two separate J-Link probes both using the latest firmware and drivers. I can reproduce it fairly easily if you have any ideas to try.
I've also captured a log of this happening which I've attached to this post. During the capturing of this log, which was done by attaching to the running M4F core, a watch variable "SystemCoreClock" was overwritten to an incorrect value by the probe and all displayed registers/code/memory in the IDE read back as zero.
The overwrite of the watch variable is the reason I came to suspect the probe was responsible. After attaching the debugger and having it foul up as described above, the value in the watch window reads 0xA05F'0003 instead of the clock frequency. That's a familiar value - what the debugger should write to the DHCSR register to halt the core! But it wrote it to the wrong place somehow. And it's not just displayed wrong, it really did write to memory. I set up the core to blink an LED when the value changed and it did.
I took measures to verify it was the probe and not [as I thought it must be] my code. I set up data watchpoints on both cores to catch any writes to that variable and found nothing. I also halted the M0 and used the MPU on the M4F to fault on any write to that area. Still nothing. The only way it could be written is through the debug port.
Any idea what could be going on here?