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.

[Tomas S.]

Hi Susheel,

Thank you very much for answering and confirming my speculation about TEMP Sensor.

I have considered how to apply your recommendation in my case.

As I am measuring the temperature (mpsl_temperature_get) only on one place in my SW and it collides with call from "unknown code" (probably some SoftDevice stuff) I can´t add mutex lock into SoftDevice (or another inaccessible code) to prevent the reentry into mpsl_temperature_get.

Or did I miss some trick?

I have also checked the usage of bt_is_ready(). Hypothetically I could be without the temperature measurement during the BLE session, but I have found that something is calling the mpsl_temperature_get (approx each 8 Sec.) regardless of whether BT is ready or not.

Nevertheless this discovery brought me to a possible solution, which seemingly works.

Namely, if something is obviously triggering the TEMP Sensor (by mpsl_temperature_get), somewhere must be the measured value, which I need. And actually it is. Directly in the TEMP register of TEMP Peripheral.

Now I am just reading the value from the register (address 0x4000c508) and getting the temperature.

It may be extended by checking the EVENTS_DATARDY register of the TEMP sensor to be sure to read consistent data.

I will still do some tests with it, but it looks promising at the moment.

[Susheel Nuguru]

Thanks for the updates Tomas, Please keep me posted if you have more hiccups on it. Good luck.