Debugger crashes when target resets?

[bp1979]

Hi,

When I start a debug session on my iMX RT 1020 board, I can step through code. All good.

When I set a breakpoint in my main e.g., and I stop the debugger, and press start again, it will hit the breakpoint. 

But then, when I press resume, and I press the reset button on the board, the board obviously resets, but the breakpoint is never hit. When I then press pause, the debugger tells me that the connection is lost.

This is really annoying. This makes development cumbersome. There are many situations where you can simply debug through some behavior which occurs after reset. With STM dev boards (nucleo and such) this works perfectly. 

Is this a known issue and is this going to be fixed?

Many thanks! 

[ErichStyger · Accepted solution]

What debug interface are you using? For example LinkServer will set HW trigger points, and they are lost if you reset the target as the debug blog gets reset too.

If you use the J-Link connection, it sets the breakpoints in Flash and they are still there if you reset the target.

I hope this helps,

Erich

[bp1979]

Aha! That's a perfectly good explanation ! Thx for the reply.

I am using LinkServer. I don't know if I can use JLink on a RT1020 evk board. I will look into that.

[ErichStyger]

I wrote an article here about how breakpoints work: https://mcuoneclipse.com/2012/07/29/software-and-hardware-breakpoints/

For the i.MX RT1020 you could use an external debug probe, see https://mcuoneclipse.com/2018/08/06/first-steps-with-the-i-mx-rt1020-evk-board/ if you happen to have one.

Anyway I recommend to use an external debug probe (much faster and more features). The J-Link EDU you can get for $20 (depending on your usage, check the license terms).

The RT1020 EVK has a K20 based circuit: I'm not sure if it can load the SEGGER firmware (did not try). But as the K20 is rather limited in speed, I would go for an external debug probe anyway (this is what I use for the RT1020).

I hope this helps,

Erich