nRF5340 BLE Advertisements Stop at Low Temperatures – Possible Network Core Resets?

[sst_S.Sakamoto]

Hello,

I’m working with an nRF5340-based device (NORA-B106-00B) and nRF Connect SDK 2.0.2. At low temperatures (around -20°C), some boards fail to advertise BLE (the advertisements are no longer detected). When the temperature drops further (around -25°C), more boards exhibit the same issue. However, returning the boards to room temperature allows BLE advertisements to resume.

I haven’t created any custom firmware for the network core (no separate net core build). I’m also using the SC32S-7PF20PPM crystal at 32.768 kHz.

Q1: Could the network core be experiencing a watchdog reset (LDOG) or CPU lockup (LLOCKUP) at low temperatures, leading to a situation where only the network core is reset?
Q2: Are there any known issues with the nRF5340 BLE controller at low temperatures, or recommended troubleshooting steps for this scenario?

Any insights or suggestions would be greatly appreciated. Thank you!

Best regards,

[Stian Røed Hafskjold]

Hello, workaround for both errata 160 and 165 must be implemented for safe operation in low temperatures. Unfortunately the 165 workaround is not trivial to implement and consist of PPI pinging between the cores to ensure that the network core regulators are in the correct state when the network core CPU are starting up after wakeup. It also includes a recovery mechanism for the network core, in case the anomaly occurs. So I would suggest updating to a newer SDK version. Errata 160 on the other hand can be added as part of the startup code in the MDK.

Best regards,
Stian

[sst_S.Sakamoto]

Hello Stian,

Thank you very much for the detailed explanation about how the workarounds for Errata 160 and 165 must be implemented. I understand that Erratum 165 requires a more complex solution involving PPI coordination between the cores and a recovery mechanism on the network core— features only found in newer SDK versions.

We would certainly consider upgrading to a more recent SDK as recommended. However, due to development cost constraints, it is difficult for us to change the current SDK version (v2.0.2) or to build a custom firmware for the network core. Under these conditions, we have the following questions:

1. Partial mitigation on SDK 2.0.2
   Is there any approach or workaround we can attempt to reduce the risk of low-temperature failures, given that we cannot immediately upgrade to SDK 2.5 or create a custom net core firmware?

2. Temperature range guarantee
   If we remain on SDK v2.0.2 without the full workaround, what operating temperature range can we realistically support? Is there a safe threshold above which stable operation is expected?

3. Errata 160 register updates
   Regarding Errata 160, we are planning to access certain registers for both the application core and the network core. Is it possible to perform all necessary register writes for the network core from the application core firmware? Or do we need a separate net core firmware update to handle these register writes?

Thanks again for your support and guidance. Any insights you could provide on these topics would be greatly appreciated.

Best regards,