LPC MicrocontrollersのトピックRe: LPC4357 JTAG malfunction with both cores active

LPC4357 JTAG malfunction with both cores active

leecoakley — Mon, 19 Mar 2018 19:42:30 GMT

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.

Re: LPC4357 JTAG malfunction with both cores active

leecoakley — Wed, 21 Mar 2018 03:40:03 GMT

Actually I can now reproduce the issue when the Cortex M0 is not running at all.

It is simply that SWD works and JTAG fails after some time. Even got my hands on a spare probe but the results are the same.

How can it be that JTAG malfunctions but SWD never does? Could there be a bug in the debug probe? I will contact Segger and see what they have to say about it.

Re: LPC4357 JTAG malfunction with both cores active

lpcxpresso_supp — Wed, 21 Mar 2018 03:48:27 GMT

You could download the latest NXP MCUXpresso IDE for free. It has JLink support. The caveat is I didn’t see JTAG work with their GDB server. SWD provides access only to the M4 core at AP 0. The M0 is accessible only on the JTAG scan chain.

Thanks and regards,

MCUXpresso Support

Re: LPC4357 JTAG malfunction with both cores active

leecoakley — Sun, 25 Mar 2018 19:35:39 GMT

I was in contact with Segger and they don't believe the probe or their driver is at fault. Perhaps it is some memory corruption bug in IAR EW.

Indeed I wasn't able to connect to both cores through JLink using its GDB interface. I wanted to try that with IAR EW as well.

I will try the NXP IDE and see what happens.