Unable to attach debugger and break at reset vector

[RMV]

I am trying to debug a runtime issue on an nRF52832 based board while it is still powered up -- I am afraid that it will 'recover' if I cycle the power.

I have tried to attach a debug client using Eclipse CDT but am running into some issues.  I have not yet tried it out with Segger and am happy to use it if that is the only option.

My application is using nRF5 SDK 16.0.0, Soft Device S132 v6.1.1.

The device was operating as expected for over two months when all of a sudden it entered this state where it keeps rebooting every 2-3 seconds.
I have been able to get some clues by minimally attaching an Eclipse CDT based debug client.
It appears to be that the RTC timer handler runs into an error (I am not sure what the exact error is but whenever I have been able to trap it, it seems to be that the scheduler thinks there is a previous instance of the timer on the queue, and in that loop it bails out with the code NO_MEM i.e. '4'.

I can see that the debug client stops when it its a firmware breakpoint instruction 'bkpt'.
However, I have a hard time reconciling the function call stack with the actual run time operation -- no matter where I place a breakpoint higher up in the stack the CPU always seems to only stop at the software bkpt instruction and never at any of the breakpoints in the called frame history.

In frustration, I am trying to RESET the CPU and have it start at the reset vector 0x0 but no matter how I send the debug command to reset the target, the CPU never stops at the reset vector.
But it always stops at the address 0x271C4 (or it could be 0x27C14, I don't recall the exact information right now).
This address happens to be an instruction 'bx lr' and the link register points to an address a few instructions later on in the progam.

I also tried changing this memory location using the debug client but it looks like something is preventing the client from writing this flash location even when the MCU is halted under debug client control.

I have two questions that I am looking for answers.

1.  Why can my debug client not have the MCU reset and STOP AT PC 0x0?

2.  Is there any MPU mechanism that is preventing my debug client from updating the program memoy within the SoftDevice range i.e. 0x0 to 0x25FFF?

3.  What can cause the scheduler (which is being used by the timer) to enter a state where even a call to NVIC_SystemReset() does NOT clear the internal state of the scheduler after the reset and upon entering the main() function?

4.  Any other thoughts on how to debug such error conditions where I cannot afford to cycle the power to the device?

Thanks

RVM

[RMV]

RMV said:

But it always stops at the address 0x271C4 (or it could be 0x27C14, I don't recall the exact information right now)

Just an update....

The first address that the attached debug client stops at is:     0x251C4.
The instruction at this address (as presented by the disassembler) is:  'BX LR'.
The value in the Link Register is: 0x16275  (which is within the SoftDevice)

[Vidar Berg]

Hello,

2.  Is there any MPU mechanism that is preventing my debug client from updating the program memoy within the SoftDevice range i.e. 0x0 to 0x25FFF?

Execution starts from the reset handler (address to reset handler is always stored at 0x4) while address 0x0 is where the CPU obtains its initial stack pointer value from.

2.  Is there any MPU mechanism that is preventing my debug client from updating the program memoy within the SoftDevice range i.e. 0x0 to 0x25FFF?

Not the MPU, but the MWU — Memory watch unit. This module is configured by the Softdevice prevent you or the application from writing data to its reserved memory regions.

3.  What can cause the scheduler (which is being used by the timer) to enter a state where even a call to NVIC_SystemReset() does NOT clear the internal state of the scheduler after the reset and upon entering the main() function?

Considering you are getting a NO_MEM error it seems more likely that something is preventing the scheduler queue from being processed and therefore cause the overflow to occur 2-3 seconds after boot. Maybe it hangs in an interrupt handler so the program cant return to main() and process the queue? 

Could you try to see if you are able to set breakpoints with Segger Ozone (https://www.segger.com/products/development-tools/ozone-j-link-debugger/ )? It's requires very little setup, all you have to do is to supply is the *.elf file for your FW so it can load the debug symbols.

Best regards,

Vidar

[RMV]

Hi Vidar

Thanks for your support. It did help.

I was able to figure out that the first address that the debugger breaks at is indeed the location of the 'ResetHandler' linked to by the vector at address 0x4....

Please close this ticket as 'resolved'.

Thanks again.