Segmentation fault when debugging nRF52840-DK

RE: Segmentation fault when debugging nRF52840-DK

awneil — Wed, 10 Jul 2019 17:26:54 GMT

As Håkon Alseth said, it sounds like the classic problem of Halting Debug with a SoftDevice:

https://devzone.nordicsemi.com/f/nordic-q-a/48647/ble-debugging-on-nrf52/193088#193088

I know nothing about this "Black Magic" probe, but Segger seem to be the only ones to have implemented Monitor Mode Debug for Cortex-M. They say it should be transparent to the IDE, but it does require that you use a J-Link.

RE: Segmentation fault when debugging nRF52840-DK

Fredcoach — Wed, 10 Jul 2019 14:28:58 GMT

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

RE: Segmentation fault when debugging nRF52840-DK

Håkon Alseth — Wed, 10 Jul 2019 14:22:02 GMT

[quote user="Fredcoach"]What do you mean by "mon reset"? [/quote]

a debugger issued reset.

[quote user="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.[/quote]

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

RE: Segmentation fault when debugging nRF52840-DK

Fredcoach — Wed, 10 Jul 2019 14:11:54 GMT

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"?

RE: Segmentation fault when debugging nRF52840-DK

Håkon Alseth — Wed, 10 Jul 2019 14:00:22 GMT

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

RE: Segmentation fault when debugging nRF52840-DK

Fredcoach — Wed, 10 Jul 2019 13:46:20 GMT

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

RE: Segmentation fault when debugging nRF52840-DK

Håkon Alseth — Wed, 10 Jul 2019 08:42:16 GMT

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

RE: Segmentation fault when debugging nRF52840-DK

niebert — Tue, 09 Jul 2019 11:25:03 GMT

It is possible that there are compatibility issues with the black magic probe (and this is likely the reason why you cannot flash with it). If you have that alternative, use openocd, e.g. with an STLink programmer or a CMSIS DAP programmer or even bit banging from a raspberry PI, all work great, also for flashing.

As much as I like the concept of BMP, it remains limited since all targets must be known in the firmware. OpenOCD remains more universal.