Segmentation fault when debugging nRF52840-DK

[Fredcoach]

Hello, I am developping on a nrf52840-DK board and try to debug using a Black Magic probe. Software is based on softdevice, GCC build chain and Visual Studio Code with Cortex-debug extension. For now, we advertise on BLE and send the battery voltage when connected, we go to sleep when the voltage is too low. All this works well as long as we don't try debugging. The execution is stopped at the beginning of main() until the button 4 is pressed, in order to have enough time to start the debugger (the code is downloaded using USB, I did not manage yet to do this through the Black Magic probe). Then most of the routines do not return when skipping them (F10) and some even don't allow entering them (F11). I can go (F5) and stop later if still at the beginning. But if the system is fully initialized when I debug, I get a segmentation fault. Extract:

Program
 received signal SIGINT, Interrupt.
debug_wait_loop () at ./main.c:1116
1116            if((drop & 0x02000000) == 0)

Program
 received signal SIGSEGV, Segmentation fault.
0x00015522 in ?? ()

Did I miss something obvious?
My background: I am new to ARM and particularly Nordic but 40 years of low level development, embedded, Windows device drivers and several years of BIOS, including debugger development.

[Håkon Alseth]

Hi,

 

Your debugging experience here doesn't look like it's optimal.

Have you considered contacting BMP community (via https://github.com/blacksphere/blackmagic or similar) to ask about this?

 

Since you're new to debugging with a Softdevice running, do note that if you halt/run while the softdevice is active (advertising or in a connection), you will assert.

This is because halting using the debugger halts only the CPU, while keeping peripherals like the radio, rtc, timers, etc. running. When resuming again, all these peripherals are then set, and the softdevice asserts if events are triggered in a abnormal order.

Setting a breakpoint is OK, but if you continue again; you will assert.

 

Kind regards,

Håkon

[Fredcoach]

Thanks for the answers.

Thus, stepping Inside the code is not possible...

Is it possible to disable these assertions?

If not, I don't clearly see why to use a debugger.

Best regards,

Frederic

[Håkon Alseth]

Well, technically, you can ignore the assertion callback from the softdevice, but I would not recommend it. You'd need a reset to recover the SoftDevice at that point.

The bluetooth LE communication relies on a peer device as well, so halting/running would break the link anyway.

 

You can still use the debugger, just know that you need to do a "mon reset" if you continue after halting while the SoftDevice is actively doing something.

 

Kind regards,

Håkon

[Fredcoach]

Yes, I can probably ignore the assert (do I have to intercept it to see it?), but I don't know what to do after a segmentation fault.

What do you mean by "mon reset"? 

[Håkon Alseth]

Fredcoach said:

What do you mean by "mon reset"? 

a debugger issued reset. 

Fredcoach said:

Yes, I can probably ignore the assert (do I have to intercept it to see it?), but I don't know what to do after a segmentation fault.

Given that it stops in the address space of the softdevice, I suspect that the seg fault is actually the softdevice asserting.

I haven't used a BMP myself, but address-wise (0x00015522); it's the SoftDevice.

 

Kind regards,

Håkon

[Fredcoach]

Yes, for sure, it is the soft device.

You talked about an assertion callback. Is it possible to get this callback, ignore it and continue?

I know that the comm will fail but it will still allow to follow the code and, thus, understand many things.

I use the reset button after the segmentation fault.

Best regards,

Fred