NRF5340： the zephyer OS priority issue: the BLE thread and the other thread priority can be changed?
Does the BLE thread be the 1st priority than other thread all the time?
can the BLE thread change to lower priority? how to change it in the zephyer OS.
Hi,
the BLE thread and the other thread priority can be changed?
Yes, a thread's priority in Zephyr RTOS can be altered up or down after the thread has been started, meaning a preemptible thread can become a cooperative thread and vice versa. See Thread Priorities.
Does the BLE thread be the 1st priority than other thread all the time?
The BLE stack uses the System work queue (priority -1) as a cooperative thread, which gives it a high priority, but it is not unconditionally the highest priority. Any thread with a priority lower than -1 (e.g., -2, -3, etc.) would have higher priority. See the DevAcademy course: Scheduler In-Depth
can the BLE thread change to lower priority? how to change it in the zephyer OS.
What is your NCS version? Are you using standard HCI IPC (SB_CONFIG_NETCORE_IPC_RADIO_BT_HCI_IPC) or RPC on the NetCore?
Regards,
Amanda H.
NCS version = V2.9.2 using the standard HCI IPC
thank you for your previous guidance on Zephyr thread priorities.
I would like to circle back to the topic of thread priorities, as I've encountered some interesting observations during high-load stress testing:
System Load vs. BLE Stability: Under high sensor throughput (3000+ bytes/sec), I've observed that the BLE stack's system work queue (priority -1) occasionally experiences contention with my custom SPI polling threads. While I have managed to handle this using buffer-and-burst, I’m interested in whether it is advisable to keep the BLE work queue at its default priority, or if there are specific scenarios where elevating or lowering it (to balance sensor data processing) is recommended without risking connection stability?
HCI IPC Latency: Regarding your previous question on our communication method: We are using the standard HCI IPC (nRF5340 dual-core architecture). In this setup, could you provide any insights into the typical latency budget for IPC messages between the NetCore and AppCore? I am curious if heavy sensor interrupt activity on the AppCore could implicitly impact the HCI throughput through IPC resource contention?
Advanced Tuning Advice: As we are aiming for "medical-grade" precision, I want to ensure our architecture is robust. Are there any hidden "gotchas" or advanced configuration tips for nRF5340 when handling high-frequency multi-sensor streams simultaneously with high-bandwidth BLE data?
I truly appreciate your technical support so far, which helped us reach this level of performance. Looking forward to your insights!
ougengzhou said:While I have managed to handle this using buffer-and-burst, I’m interested in whether it is advisable to keep the BLE work queue at its default priority, or if there are specific scenarios where elevating or lowering it (to balance sensor data processing) is recommended without risking connection stability?
For connection stability, keep sysworkq at -1. Your buffer-and-burst approach is the right architectural pattern.
ougengzhou said:could you provide any insights into the typical latency budget for IPC messages between the NetCore and AppCore? I am curious if heavy sensor interrupt activity on the AppCore could implicitly impact the HCI throughput through IPC resource contention?
Yes, due to AppCore scheduling. The NetCore runs the BLE controller and radio timing independently. But NetCore sends HCI events/ACL to AppCore must process them in HCI driver / bt_rx threads. If AppCore is saturated with SPI ISRs or a tight polling loop, HCI RX backs up.
ougengzhou said:Advanced Tuning Advice: As we are aiming for "medical-grade" precision, I want to ensure our architecture is robust. Are there any hidden "gotchas" or advanced configuration tips for nRF5340 when handling high-frequency multi-sensor streams simultaneously with high-bandwidth BLE data?
I am not sure what issue you will encounter. Maybe you can check out the nRF Connect SDK v2.9.2 Release Notes and known issues for nRF Connect SDK v2.9.2.
ougengzhou said:While I have managed to handle this using buffer-and-burst, I’m interested in whether it is advisable to keep the BLE work queue at its default priority, or if there are specific scenarios where elevating or lowering it (to balance sensor data processing) is recommended without risking connection stability?
For connection stability, keep sysworkq at -1. Your buffer-and-burst approach is the right architectural pattern.
ougengzhou said:could you provide any insights into the typical latency budget for IPC messages between the NetCore and AppCore? I am curious if heavy sensor interrupt activity on the AppCore could implicitly impact the HCI throughput through IPC resource contention?
Yes, due to AppCore scheduling. The NetCore runs the BLE controller and radio timing independently. But NetCore sends HCI events/ACL to AppCore must process them in HCI driver / bt_rx threads. If AppCore is saturated with SPI ISRs or a tight polling loop, HCI RX backs up.
ougengzhou said:Advanced Tuning Advice: As we are aiming for "medical-grade" precision, I want to ensure our architecture is robust. Are there any hidden "gotchas" or advanced configuration tips for nRF5340 when handling high-frequency multi-sensor streams simultaneously with high-bandwidth BLE data?
I am not sure what issue you will encounter. Maybe you can check out the nRF Connect SDK v2.9.2 Release Notes and known issues for nRF Connect SDK v2.9.2.
