This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Assertion in soc_radio_timeslot.c

Hello, I am getting a 0xdeadbeef assertion at src\soc_radio_timeslot.c line 390. I am using S110 SoftDevice v7.1.0 with nRF51822 revision 2 CEAA. I am using the multiprotocol timeslot API to run BLE simultaneously with Micro ESB. What could cause this specific error? I don't think it's caused by spending too much time in the timeslot signal handler, because that causes an assertion at a different line in soc_radio_timeslot.c. Thanks, Paolo

  • How often do you see this assert? Can you give us some information on what happens before you see this assert? Also are you using radio notifications?

  • Also, you are missing the full chip variant code which should have 2 more characters. So it should be CEAAXX. Please let us know what the XX is.

  • I am using the CEAAD10 chip variant. The device which is crashing is set up as a Micro ESB PTX, based on the sample code from github.com/.../nrf51-ble-micro-esb-uart. I am not using radio notifications. While keeping a BLE connection open with a slow connection interval (currently using 220ms) it tries to send large packets (252 byte payload) as fast as possible in each timeslot. The crashes are random, sometimes it will run for long enough to transmit 100MB and other times it will crash almost immediately.

    Can someone with access to the SoftDevice source code provide more details on what triggers this specific assertion? I would like to make sure that I properly fix the problem, instead of just making it less likely to occur randomly. Thanks, Paolo

  • This assert can happen if the highest priority interrupts were delayed.Are you: disabling interrupts at any point in your code, using the highest priority level somewhere else in your code or writing to flash? Since you are able to replicate this assertion, can you get a memory dump when it happens and send it to us?

  • I think that I might have found the problem:

    In the Micro ESB library, the uesb_init function calls NVIC_SetPriority to change the RADIO IRQ priority, by default to AppHigh. Since that library assumes that it's not running under a SoftDevice this would normally be ok. Based on the nrf51-ble-micro-esb-uart sample code, I am calling uesb_init from a software interrupt at AppHigh priority, triggered from the radio signal callback at the start of a timeslot. However the SoftDevice probably is expecting that the RADIO IRQ priority would not be changed during the timeslot. Removing the call to NVIC_SetPriority from uesb_init, leaving the RADIO IRQ priority at the level the SoftDevice set it to, appears to fix the problem.

    I haven't done much testing of this fix yet, and will post here if I have any more trouble.

Related