Hi, When using RBC mesh and SD8.0.0 I often get assertion at line 189 in soc_radio_timeslot.c. This file is part of sd8.0.0 and I dont have source code. Why is this assert triggering? What can I do about it?
Hi, When using RBC mesh and SD8.0.0 I often get assertion at line 189 in soc_radio_timeslot.c. This file is part of sd8.0.0 and I dont have source code. Why is this assert triggering? What can I do about it?
This assert will hit if you spend too much time in the callback handler, because this could disturb the timings used for BLE. You can fix this by asking for more time, or optimizing your code to run faster. Remember that there is some overhead back and fort due to interrupt handling and function calls, so this must be calculated in.
Hi, thanks for your answer! What do you mean with "asking for more time"? What is "too mush time", do you have some form of constant?
The code that requests a timeslot with the Radio Timeslot API promises that it will use X microseconds when it is given control. The callback is then able to use the TIMER0 peripheral to time this, or make sure the code is optimized enough to run in less than (X-overhead) time. If the allotted time is exceeded, this assert will trigger.
Ok, then I understand, Thank you!
The "Concurrent Multiprotocol Timeslot API" section of the S110 nRF51 SoftDevice Specification v2.0 is recommended reading.
Make a particular note of this warning (section 9.9.6): "The signal handler runs at LowerStack priority, which is the highest priority. Therefore, it cannot be interrupted by any other activity. Also, as for the App(H) interrupt, SVC calls are not available in the signal handler. It is a requirement that processing in the signal handler does not exceed the granted time of the timeslot. If it does, the behavior of the SoftDevice is undefined and the SoftDevice may malfunction."