RE: bt_sdc_hci_driver: SoftDevice Controller ASSERT: 33, 531?

Raoul — Tue, 18 Apr 2023 13:15:46 GMT

Hi Tim, I'm glad you found the source of your issue.

Regarding the asserts, you'll see that many customers on DevZone experience this when trying to set breakpoints in their BLE-enabled applications. (You could search for "assert 2195" in particular). The fact is that with normal "halting debugging", it's simply not possible to set breakpoints on any application that uses the SoftDevice controller or Zephyr BLE controller. BLE is extremely sensitive to timing and so the link layer code has asserts all over the place to ensure that timing requirements are upheld. If not, they will fault.

One solution is "monitor mode debugging" which is an alternative to halting debugging, where it keeps high priority interrupts such as those from the SoftDevice, running in the background. But we don't currently have a solution for this as far as I know. I could look more into this when I have the time, if you like.

Best regards,

Raoul

RE: bt_sdc_hci_driver: SoftDevice Controller ASSERT: 33, 531?

pilux — Tue, 18 Apr 2023 06:08:22 GMT

Right. It was my fault.

I hooked up an oscilloscope to a spare GPIO pin and toggled it in my 1Hz reporting thread: that was toggling in both my debug and in the non-debug, so nothing wrong with the initialisation.

So I looked at the code again and realised that one of the threads I was spinning up wasn't sleeping; in fact it consuming 100% CPU and starving the logging. I got further in the debug because I was probably pausing that thread and allowing other stuff - like logging - to run. I now believe that the ASSERT is what I thought: starvation of an IRQ or similar.

I got logging working in the no-sleep case by adding this config property to force immediate logging instead of waiting for the logging thread to have its turn:

CONFIG_LOG_MODE_IMMEDIATE=y

This then showed me that the CPU was pegged at 100% (thank you cpu_load_init!).

The fix was simple: put a sleep into the thread that was starving the rest, including logging. I have now removed the CONFIG_LOG_MODE_IMMEDIATE and it still all behaves, sitting normally at ~7% CPU instead of 100%.

My remaining question is: is the ASSERT "expected" while debugging? If so, is there a way to avoid it? Having random kernel oops while debugging anything might get a bit... annoying. 🙂