You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
On a custom device using the nRF5340, running nRF Connect SDK 2.5.0 with Zephyr 3.4.99, a systematic bug causes the system to freeze for 512 seconds.
This issue is difficult to track, as its occurrence and timing vary, even under identical test conditions.
Software timers are used to ensure the periodicity of the thread that reads the I2C data and starts the BLE scanning. Another timing critical task is done by hardware nRF timer 2. Hardware timer is used with IRQ zero latency settings. RTOS kernel itself works in multithreading mode with time slicing equal to 1 ms
The delays set by k_sleep do not exceed a couple of tens of milliseconds. I tried to get rid of BLE completely and minimize the load on the system by excluding I2C reading, which resulted in the occurrence of this bug a little less often.
Also, going from TICKLESS_KERNEL=y to TICKLESS_KERNEL=n improves the situation, but significantly reduces timing accuracy, which is also critical for the project.
I suspect that this clearly has something to do with the nrf_rtc_timer that Zephyr uses to implement timings, but I have no idea what would solve this problem at the moment.
The text was updated successfully, but these errors were encountered:
Thank you for reporting this. However - unless you are able to reproduce this issue with upstream Zephyr main - please report issues with the nRF Connect SDK (NCS) on the Nordic Semiconductor DevZone.
On a custom device using the nRF5340, running nRF Connect SDK 2.5.0 with Zephyr 3.4.99, a systematic bug causes the system to freeze for 512 seconds.
This issue is difficult to track, as its occurrence and timing vary, even under identical test conditions.
Software timers are used to ensure the periodicity of the thread that reads the I2C data and starts the BLE scanning. Another timing critical task is done by hardware nRF timer 2. Hardware timer is used with IRQ zero latency settings. RTOS kernel itself works in multithreading mode with time slicing equal to 1 ms
The delays set by k_sleep do not exceed a couple of tens of milliseconds. I tried to get rid of BLE completely and minimize the load on the system by excluding I2C reading, which resulted in the occurrence of this bug a little less often.
Also, going from TICKLESS_KERNEL=y to TICKLESS_KERNEL=n improves the situation, but significantly reduces timing accuracy, which is also critical for the project.
I suspect that this clearly has something to do with the nrf_rtc_timer that Zephyr uses to implement timings, but I have no idea what would solve this problem at the moment.
The text was updated successfully, but these errors were encountered: