Assertion failed in src/rem.c line 1371

[Miek]

SDK: 10.0.0

Softdevice: s110_nrf51_8.0.0

I'm working on migrating our application from SDK v9 to v10. I'm getting a softdevice assertion failure in src/rem.c line 1371 reproducably at a certain point during the application's startup. Could I have some details on what causes this particular assertion so I can debug further?

Thanks,

Mike

[tesc]

Hi,

First I must ask why you are porting from SDK v9 to SDK v10. When you are first in the process of porting the code base, why not go all the way to the newest SDK release supporting the nRF51 series, namely nRF5 SDK v12.3.0?

I am also curious how you got the file name and line number for the SoftDevice assert. Usually all we get reported is the pc for the assert. I am not aware of any publicly available assert tables or elf files, but I might be wrong of course.

The assert happens if the SoftDevice receives a TIMER0 event at a point where it is not expecting to get one. It is often seen if you are using the timeslot API and timer0, for instance if the interrupt on timer0 is not cleared before returning from the timeslot.

Regards,
Terje

[Miek]

I'm only porting to v10 as I think that's the last version that supports the S110 softdevice. We're very short on resources so we can't switch to S130.

To get the file name and line number, we're overriding `assert_nrf_callback` and logging the error:

void assert_nrf_callback(uint16_t line_num, const uint8_t * p_file_name)
{
    error("Assertion failed at %s, line %d", p_file_name, line_num);
}

Thanks for the extra info, I'll go do some more debugging.

Cheers,

Mike

[Miek]

We're not actually using TIMER0 in our application at all and we've got `#define TIMER0_ENABLED 0` in nrf_drv_config.h. Given that, do you have any other ideas for how this could happen?

[Miek]

It turned out we had inadvertently set SPI interrupts to priority 0, so we were causing the softdevice to miss its timing constaints when there was a lot of SPI traffic. We've set that back to low priority and are no longer getting any failed assertions.

Thanks for the help,

Mike

[Henry Choi]

Hi Terje, I just ran into this assertion also.  SDKv10 s110 on nRF dongle.  Unlike Miek, all my interrupts are at APP_LOW (3), so the root cause must not be the same.  Can you please tell me if there is a callback that the SD will call before and after running (so that I can light up the LED for the duration and measure on the scope)?  I made only a slight modication to the ble_app_uart example (which ran fine without modification): In my main loop, I am not sleeping (checking the UART FIFO I setup and flushing that with nerf_drv_uart_tx() in a blocking call.  Even if it is a blocking call, all the interrupts are using APP_IRQ_PRIORITY_LOW, so I can't imagine what's wrong.  I have to see why SD is getting starved out.