SW got stuck during reading internal TEMP sensor

[Tomas S.]

Hello,

We are developing an application with nRF52810 based on nRF Connect SDK V2.4.1.
The application is utilizing the BLE connection, particularly the NUS Service (emulation of UART communication over BLE).
The BLE is not active all the time, but can be enabled and disabled by user input (SW then calls bt_enable/bt_disable function).
Among other things, we are using the nRF52 internal TEMP sensor to get the temperature.
I went through some documentation and obviously the TEMP sensor is used by bluetooth stack too and therefore there are probably some limitations of using the TEMP sensor by application.

I have realized the reading of the temperature via Zephyr sensor device by calling sensor_sample_fetch_chan() and sensor_channel_get() for channel SENSOR_CHAN_DIE_TEMP each 120 ms.
This seemed to work quite nicely (even thought the measured temperature was couple of degrees higher, than expected).

Then I have observed, that in range of temperature measurement there are some individual samples, which are showing precise temperature value compared to majority of higher values.

Based on datasheet and some related posts on web, I guess, it has something to do with HFCLK, which is probably not using the Crystal oscillator all the time and therefore losing some precision.

But then we got to real problem. The device runs smoothly and then it suddenly "freezes" after some hours of operation. We tested it couple of times and it occurred between 4 to 12 hours.
If I attached the debugger to frozen device, I was able to determine, that it got stuck during my function for measuring the temperature after calling sensor_sample_fetch_chan(), which is under the hood using mpsl_temperature_get():



I also found out, that it makes no difference, if the BT is active or not (bt_enable/bt_disable), it stuck after the time anyway.

Based on available examples (e.g. samples\bluetooth\peripheral_ht) I would say, that I am using the TEMP in the same way.

Is actually the TEMP driver designed to be used parallel by application and by BT stack (softdevice)? I suspect that these two things might conflict with each other.

Maybe some CONFIG Switch must be active?

Does the BT stack using the TEMP Sensor even if disabled (by bt_disable)?

I am already out of ideas, where to look.

Thank you in advance for your reply.

Best regards
Tomas

[Susheel Nuguru]

Hi Tomas,

Is actually the TEMP driver designed to be used parallel by application and by BT stack (softdevice)?

Not safely. Only one party should access it at a time — and the BT controller (via MPSL) has priority.

Does the BT stack using the TEMP Sensor even if disabled (by bt_disable)?

Yes, there are scenarios like clock calibration and other stuff where this might be implicitly used. Disabling bluetooth does not shut down completely the MPSL and its API is still available and usable. 

I suggest wrapping the TEMP access using a mutex and checking if BLE is active before proceeding. Here’s what we implemented:

Use a k_mutex to avoid reentry deadlocks.

Skip TEMP access if bt_is_ready() returns true (indicating BLE/MPSL is active).

Add a timeout so the call fails gracefully instead of freezing the app.