Softdevice assertion failed pc: 16346

[bart]

Using:

• nRF52832
• SDK 15.3.0
• SD S132 6.1.1
• nRF5 SDK for Mesh 3.2.0
• NRF_SDH_DISPATCH_MODEL == NRF_SDH_DISPATCH_MODEL_APPSH

Hi, i'm sometimes getting a crash when a phone connects, caused by softdevice assertion failed, pc: 16346. Can you tell me what could be the reason of this assert to fail?

[Amanda Hsieh]

Hi, 

What is the application or the based example?

Please kindly upload the completed debug log with the failed message. That could help us investigate the issue. Thanks. 

Regards,
Amanda

[bart]

Hi,

GDB showed it crashed into:

app_error_fault_handler(uint32_t id, uint32_t pc, uint32_t info)

with: id=1, pc=16346, info=0

Of course, the backtrace was empty, as it's a softdevice assert.

I will try to reproduce the crash, but it takes several hours, and I don't think it shows any extra info, since the info parameter is empty.

It's a rather big application, that uses connections, advertisements, and a lot of mesh traffic. You can find it here.

[Amanda Hsieh]

Do you run the https://github.com/crownstone/bluenet on nRF 52832 and then get the failed?

-Amanda

[bart]

Yes indeed, but only after a long time with a lot happening. Since it's a softdevice assert, I have no clue where something goes wrong. Normally, a nordic engineer can tell from the PC.

[Amanda Hsieh]

Hi, 

Can you check if the application is using both a connectable and non-connectable advertiser?

-Amanda

[bart]

It's using the softdevice to advertise connectable advertisements. When a connection is made, it will start advertising non-connectable advertisements.

[Amanda Hsieh]

Hi, 

Our softdevice team confirmed that 

When the application starts a non-connectable advertiser right after a connection gets established, an assert may occur. The workaround is After pulling the event BLE_GAP_EVT_CONNECTED, pull events until sd_ble_evt_get returns NRF_ERROR_NOT_FOUND. 

This bug is present in all released SoftDevices since 6.0.0. Please let me know if you are satisfied with the workaround.

-Amanda

[bart]

Thanks!

The assert that may occur is the same as what I get?

[Amanda Hsieh]

Yes. 

[Anne van Rossum]

Hi Amanda,

I'm on the same team, Crownstone, as Bart. :-)

1. We are of course happy that you know this issue exists and how to work around. Satisfaction is perhaps not the right word choice. ;-)
2. It would be great to understand why we have to pull events till we get NRF_ERROR_NOT_FOUND. What's the underlying issue?
3. If it's already since Softdevice 6.0.0, is it that you didn't know of this problem that no fix has been issued or is there something very fundamental about this which makes it difficult to solve within the Softdevice?
4. If we use the workaround, will this completely fix this, or is it still possible to run into the assert so now and then?

Of course, ideally we would have a complete explanation including some diagrams if there are some timing issues involved. Perhaps there are also some configuration settings which influence this bug. An overall picture would be ideal. (Of course, keeping private what you want to keep private).

Thanks in advance!

Anne

[Amanda Hsieh]

Hi Anne, 

We hadn't been aware of the bug until it's reported by this case.

Since the status of advertising in SD is updated to non-connectable right after a connection gets established before the next event. That will trigger an event to cause assert. NRF_ERROR_NOT_FOUND from sd_ble_evt_get  means No events ready to be pulled. Pulling events till getting NRF_ERROR_NOT_FOUND can make sure the statues be changed after the event next to the connection. 

-Amanda