Debugger does now longer handle breakpoint after watchdog reset.

[Canastra]

Hi 

I play with watchdog.

After a watchdog reset the debugger does no longer stop on a breakpoint or generate a hardfault on a __BKPT()

How can I config the Chip to handle breakpoints correct after watchdog reset?

[Håkon Alseth]

Hi,

 

Which IDE/debugger do you use? usually the debugger is able to catch a reset, but not normally re-attach to the process properly.

 

generate a hardfault on a __BKPT()

 Do you see a fault when the device resets? This could be a timing issue in your application (for instance, when init'ing an external device or similar)

 

Kind regards,

Håkon

[Canastra]

Hi Håkon

I use SES an nRF9160DK

Attached is my project.5707.buttonWdt.zip

The watchdog is refreshed until button1 is pressed.

After Watchdog timeout a reset is generated and then __BKPT() is called.

Then the debugger doesn't stop and a Hardfault is generated.

The Output from the consol is attached ZOC20210803.LOG

On line 47 is a RESETPIN

On line 100 is a DOG

On line 159 is SREQ 

When I set a breakpoint on line 87 nothing happends after DOG Reset

When I remove __BKPT() no hardfault is generated.

[Håkon Alseth]

Hi,

 

A __BKPT() instruction will cause a fault when no debugger (or semi-hosting not enabled) is connected:

https://community.arm.com/developer/ip-products/processors/f/cortex-m-forum/13615/what-is-the-behavior-for-a-bkpt-instruction-in-a-hardfault-handler

 

In this case, the wdt reset allows the device to run, and you need to re-attach the debugger. 

 

Kind regards,

Håkon

[Canastra]

Hi Håkon

SES is still in debugging mode.

The target handle a reset from the debugger correct.

How can I re-attach the debugger in SES?

Can this be done automatically?

[Håkon Alseth]

Hi,

 

Canastra said:

Hi Håkon

SES is still in debugging mode.

The target handle a reset from the debugger correct.

How can I re-attach the debugger in SES?

Can this be done automatically?

 Yes, the debug session is still open, but it goes into the running state after a wdt reset has occurred. If you halt the cpu, you can see that it has faulted (set CONFIG_RESET_ON_FATAL_ERROR=n to enable blocking assertions/faults), but you're not able to connect in such a time that the bpkt instruction is executed as you intend.

 

Kind regards,

Håkon

[Canastra]

Hi Håkon

So I see there is now way to handle breakpoints after a reset.

Today I test the reset button and it is the same behavior.

No halt on breakpoint and hardfault on __BKPT()

I print out DCB->DHCSR at startup.

with working debugger the value is #######1.

After reset (pin or dog) the value is #######0.

And only a debugger can modify this bit.

Thanks for support