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

Parents
  • 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

Reply
  • 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

Children
No Data
Related