s132 5.1.0 SD assert error

[Mike]

I'm trying to get a Bluetooth interface (Bluefruit) to the Nordic BLE softdevice under NuttX. Right now it's very unstable. It will work occasionally for 90 seconds and then hangs. Sometimes it'll hang during sd_softdevice_enable(). So pretty random. Sometimes it'll die "nicely' by calling the error callback. Here are two such calls to the error callback:

        nrf_error_cb: id = 1, pc = 0xdcc8, info = 0x00000000

        nrf_error_cb: id = 1, pc = 0x13ea4, info = 0x00000000

Any information on what these two assertion failures mean might help in understanding the underlying issue(s).

I have a Segger J-Trace module on order so hopefully that will give me some indication of what the interaction between the softdevice and NuttX is when things go wrong.

Mike

[Sigurd]

Hi,

It could be that a NuttX thread/task or interrupt with higher priority is blocking the Softdevice from processing BLE events in time. I’m not very familiar with NuttX, but if you run in the SoftDevice in a NuttX thread, make sure to give the thread high enough priority.

In general, if sd_softdevice_enable() hangs it could indicate some issue with the crystal/clocks. So if this is a custom board, you should check the crystal(s) on the board. If this is a nRF52-DK, then this could also be an issue with NuttX.

EDIT: If you are looking for an RTOS for the nRF52832, I would recommend Zephyr or FreeRTOS instead.

[Mike]

We're not looking for a nRF52 RTOS. We have one. Neither FreeRTOS nor Zephyr meets our needs. NuttX does.

What I am looking for is the specific meaning of the assert error that s132-5.1.0 BLE softdevice throws at addresses 0xdcc8 and 0x13ea4.

[Sigurd]

Hi,

The asserts indicate timing issues in the SoftDevice BLE link layer, where the SoftDevice was unable to process events in time. The BLE protocol have timing requirements, and when they are not meet the SoftDevice will assert. There could be several reasons why the SoftDevice did not process these events in time.

• You are somehow blocking the SoftDevice in a higher priority interrupt/task/thread, and therefore not giving the SoftDevice enough time to process the BLE events.
• If this is a custom board, it could be some HW issues with the crystal(s) you are using. You did not mention if this is a nRF52-DK or a custom board?

Please see the Interrupt priority levels chapter in the SoftDevice specification, and make sure that you are not using interrupts priority levels that are reserved by the SoftDevice.