AnsweredAssumed Answered

LPC4357 JTAG malfunction with both cores active

Question asked by leecoakley on Mar 19, 2018
Latest reply on Mar 25, 2018 by leecoakley

For a while I've been developing just on the Cortex M4 and had no problems. I'm using IAR EW 8.22.1 with the latest J-Link DLL.  But after starting to do dual-core debugging I now see very strange behaviour and I have no idea where it's coming from. doing dual-core debugging I have two IDE windows open and I see the same problems in both.

 

Examples:

- The debugger thinks the core is halted but it actually isn't. I can see the activity LEDs blinking and LCD screen updating normally.

- The debugger reads register values incorrectly as all zero, or all 0x0400'0000 etc.

- Rarely it will corrupt a value in the watch window seemingly by accidentally writing the address of another register into it.

 

Have you guys ever seen anything like this?

 

I know the debugger is doing the corrupting of the watch variables because I set data breakpoints on both the M4 and M0 and neither ever write to the value.  Not only that, the M4 has the MPU configured to catch memory corruptions and I've verified that it does catch such cases.  Also when the debugger isn't connected the system is completely stable. I've run it for many hours overnight with zero problems.

 

I have a log of one example where the debugger corrupted the watch variable. I'll attach it to the post. The value I'm watching is "SystemCoreClock".  After attaching the debugger and having it foul up, the value in the watch window reads 0xA05F'0003 instead of the clock frequency. This is interesting: that value is what the debugger should write to the DHCSR register to halt the core.  But it wrote it to the wrong place somehow!  And now it believes the core is halted, when it most definitely isn't. I can see the TX activity light still blinking on the UART and the screen updating.

 

Some other info:

- When the M0 isn't running - held in reset in CREG - this doesn't ever happen, or is so rare that I can never observe it.

- If I start the M0 and halt it at the reset vector, the problem still happens on the M4 side.

 

System configuration:

- Cores running at 204MHz from crystal

- EMC with SDRAM @ 102MHz

- USART0 at 115200 baud

- LCD controller driving 480x272 TFT screen

- USB0 in host mode with a HID device attached

 

Now the obvious: try another probe. But I don't have a spare one! I'll have to go order another to see if that's the problem. But if it's broken then why does it work with only one core active?  Tricky.

Attachments

Outcomes