Bluetooth Controller assertion on sys_reboot() with active connections (lll_preempt_calc: Actual EVENT_OVERHEAD_START_US) #52833
Comments
|
@cvinayak FYI |
caco3
changed the title
|
The encountered assertion check was added recently to catch skipped BLE radio events that could happen due to any externally introduced latencies. Does this only happen on restart? Please check if waiting for |
|
Thanks for the quick response! We only saw it on the It looks to me that the issue is not related to the For my point of view this issue can be closed. |
cvinayak
changed the title
|
Thank you for verifying the solution. |
|
As you use |
|
@cvinayak Thanks for the notification. How ever I am still able to provoke this error sporadically: The way I am able provoke it sporadically (after 30 minutes or more) is to have my measurement system active (meaning I am sending notifications at a high sampling rate of 333 notifications/second) and adittionally running GATT read/writes as fast as possible. |
|
The assertion you see could very well be due to any latencies introduced from any user/application ISRs in ZLI priority. Is this assertion be reproducible without any user ISRs in ZLI (or highest priority level)? |
|
hmm... To my understanding, I have no ISRs using ZLI. proj.conf: And I only have to following relevant ISR: /* Priority of Timer 2 (ADC) interrupt
* It must be below the BLE Radio IRQs (0) and above any other IRQ. */
#define ADC_DMA_TIMER_IRQ_PRIORITY 1
#define SPIM_TRANSFER_COUNT_TIMER_INSTANCE 2 // Increment on every SPIM3 transfer,
#define SPIM_TRANSFER_COUNT_TIMER_IRQ NRFX_CONCAT_3(TIMER, SPIM_TRANSFER_COUNT_TIMER_INSTANCE, _IRQn)
#define SPIM_TRANSFER_COUNT_TIMER_ISR NRFX_CONCAT_3(TIMER, SPIM_TRANSFER_COUNT_TIMER_INSTANCE, _IRQHandler)
IRQ_DIRECT_CONNECT(SPIM_TRANSFER_COUNT_TIMER_IRQ, ADC_DMA_TIMER_IRQ_PRIORITY, SPIM_TRANSFER_COUNT_TIMER_ISR, 0);
ISR_DIRECT_DECLARE(SPIM_TRANSFER_COUNT_TIMER_ISR) {
// ...
}According to https://docs.zephyrproject.org/latest/kernel/services/interrupts.html#zero-latency-interrupts I would have to use In the ISR itself I use several |
|
I hope you have the default peripheral interrupt level value greater than 2? i.e. use lower priorities for other SoC peripherals used in your application by having the below
inside your application folder in In spite these, you still get the assertion, then the value of |
|
Yes, I have set So should I simply increase the define in https://github.com/zephyrproject-rtos/zephyr/blob/v3.4.0-rc3/subsys/bluetooth/controller/ll_sw/nordic/lll/lll_vendor.h#L39? What is the disadventage on setting it to high? SInc eit is very difficult to provoke this issue, it also wil lbe hard to check that the set value is sufficient. I also saw your suggestion in 52491 (comment) to simply disable the ASSERT. Would this be a safer approach? |
Higher value reduces radio utilization. I.e. each radio event has this possible CPU use overhead margin between next radio use.
Since you mention that it is difficult to reproduce, yes, it is safe to disable the assertion check. |
Thanks for the confirmation. I also now have a test run where I see that changing it to a LOG message does not harm our applications functionality (No BLE disconnects or reduced throughput, no crashes). May I suggest to provide a Kconfig to disable this assert or to adjust the value? For me I always see the same pattern: |
I have some work in progress in a local repo, I will see what I can do:
But this will take some time before I have a clean PR to upstream. |
Describe the bug
We have a BLE application based on a nrf52.
With Zephyr
3.2.0it runs stable, we didn't see any crashes for a long time.Now we tried the latest commit
da23050and we sporadically see crashes when we try to restart the sensor (either usingsys_reboot(SYS_REBOOT_COLD)orNVIC_SystemReset()).Relevant code:
Prj.conf:
To Reproduce
Expected behavior
no assert
Impact
showstopper
Logs and console output
Environment (please complete the following information):
Additional context
The text was updated successfully, but these errors were encountered: