Trouble Debugging with J-Link

[sbranover]

Hi,

I am trying to debug my code using a Segger J-link and I seem to be getting a hard fault at startup. The same code works with the on board PE-Micro debugger.

I am using the TWR-KM34Z75M board.

Attached is the image of the call tree.

[sbranover]

Updating to the latest version of the J-Link software solves the problem.

Deleting all breakpoints has no effect.

[lpcxpresso_supp]

I can't see anything obvious in the logs you sent.

As previously suggested, can you try installing the latest SEGGER J-Link software (from SEGGER - The Embedded Experts - Downloads - J-Link / J-Trace ) and see if you still see the same behaviour?

It would also also be interesting to know whether you see the same behaviour if you delete all breakpoints in the Breakpoints view before you start your debug session.

Regards,

MCUXpresso IDE Support

[lpcxpresso_supp]

Setting breakpoints solving the problem sounds a little wierd. Might be interesting to see the log generated by the SEGGER software. See section 3.10, "SEGGER Troubleshooting", of the MCUXpresso IDE v10.02 User Guide.

Also are you seeing this with a standard off-the-shelf project, or is it something you have pulled together yourself?

Finally, please can you confirm what version of MCUXpresso IDE you are using, and also the version of the SEGGER software (and it might be worth installing the latest from their website too and seeing if that helps).

Regards,

MCUXpresso IDE Support

[sbranover]

I've attached the the logs from J-link and from GDB Server.

I first discovered the problem on my own project so I tested it on the hello world demo app with similar results.

I'm running MCUXpresso v10.0.2 [Build 411] [2017-07-11] and SEGGER J-Link V6.16b

[robertpoor]

It seems suspicious to me that g_pfnVectors() shows up in the stack trace with an address of 0x0. 

That could just be because the stack got clobbered, but can you verify that there were no linker errors?  Or start single stepping from _pvHeapStart() and see where things go bad?

[sbranover]

Adding two break point one at 0x00000000 and one at 0x00000004 seems to fix the problem.

I'm really not sure why.

[BlackNight]

Hi,

I would check if the device specified in the Segger connection dialog is matching your device, as this could cause a hard fault too.

Erich

[sbranover]

Hi Erich,

Thanks for the response.

The device specified in the Segger connection dialog is the correct device.

Based on the ARM Exception handling

Looking at the registers:

LR       = 0xFFFFFFF9

MSP    = 0x20005FE0 (pretty much start of stack)

xPSR  =  0x61000003

Looking at the stack the previous state was:

xPSR  = 0x61000000

PC      = 0x00000000

LR      = 0x1FFFE32F