Hi,
We're in the product validation stage of development with nRF54L15, part of the validation is temperature cycling, we noticed that devices seem to be "stuck" in sleep mode at temperatures under -20 deg C. The chips remain in the low power state forever (even after heating back up), and it seems the GRTC passed through the latest compare value without waking the chip properly.
I was able to reproduce this exact issue with an nrf54l15dk and the broadcaster sample from nrf connect sdk v3.3.0. Steps to reproduce:
We're in the product validation stage of development with nRF54L15, part of the validation is temperature cycling, we noticed that devices seem to be "stuck" in sleep mode at temperatures under -20 deg C. The chips remain in the low power state forever (even after heating back up), and it seems the GRTC passed through the latest compare value without waking the chip properly.
I was able to reproduce this exact issue with an nrf54l15dk and the broadcaster sample from nrf connect sdk v3.3.0. Steps to reproduce:
- Compile bluetooth/broadcaster sample for nRF54l15dk/nrf54l15/cpuapp/ns and flash an nRF54L15dk
- Place the board in a freezer set to maximum cold, this typically will allow it to reach under -20 in about 10 minutes
- Notice the bluetooth advertising has stopped. (for debugging it may be helpful to change line 44 to
err = bt_le_adv_start(BT_LE_ADV_NCONN_IDENTITY, ad, ARRAY_SIZE(ad), NULL, 0);so the bluetooth address doesn't change).- It may also be helpful to attach a PPK, as that also clearly shows the advertising current spikes stopped. I have plenty of screenshots of current behavior if helpful.
I then started a debug session, it seems the last GRTC compare value was passed by without waking the chip. Interestingly, it seems like upon reset the board typically re-enters this "stuck" state in less than 10 seconds (so long as it is cold).
(gdb) x/48wx 0x400e2520 0x400e2520: 0x00000000 0x00000000 0x00000000 0x00000000 0x400e2530: 0x00000000 0x00000000 0x00000000 0x00000000 0x400e2540: 0x00000000 0x00000000 0x00000000 0x00000000 0x400e2550: 0x00000000 0x00000000 0x00000000 0x00000000 0x400e2560: 0x00000000 0x00000000 0x00000000 0x00000000 0x400e2570: 0x00000000 0x00000000 0x00000000 0x00000000 0x400e2580: 0x6fdaef98 0x00000000 0x00000000 0x00000000 0x400e2590: 0x00000000 0x00000000 0x00000000 0x00000000 0x400e25a0: 0x6fcd6042 0x00000000 0x00000000 0x00000000 0x400e25b0: 0x6fcbc956 0x00000000 0x00000000 0x00000000 0x400e25c0: 0x00000000 0x00000000 0x00000000 0x00000000 0x400e25d0: 0x00000000 0x00000000 0x00000000 0x00000000 (gdb) x/16wx 0x400e2720 0x400e2720: 0x717467c5 0x00000000 0x00000000 0x00000000 0x400e2730: 0x71746fbc 0x00000000 0x00000000 0x00000000 0x400e2740: 0x7174781d 0x00000000 0x00000000 0x00000000 0x400e2750: 0x71747fc5 0x00000000 0x00000000 0x00000000
Interestingly, it seems the interrupt is pending in the NVIC, as well as the GRTC peripheral.
(gdb) x/wx 0xe000e11c 0xe000e11c: 0x00000028 (gdb) x/wx 0xe000e21c 0xe000e21c: 0x00000028 (gdb) x/48wx 0x400e2300 0x400e2300: 0x00000000 0x00000000 0x00000000 0x00000000 0x400e2310: 0x00000040 0x00000040 0x00000040 0x00000040 0x400e2320: 0x00000000 0x00000000 0x00000000 0x00000000 0x400e2330: 0x00000500 0x00000500 0x00000500 0x00000100 0x400e2340: 0x00000000 0x00000000 0x00000000 0x00000000 0x400e2350: 0x00000000 0x00000000 0x00000000 0x00000000 0x400e2360: 0x00000000 0x00000000 0x00000000 0x00000000 0x400e2370: 0x00000000 0x00000000 0x00000000 0x00000000 0x400e2380: 0x00000000 0x00000000 0x00000000 0x00000000 0x400e2390: 0x00000000 0x00000000 0x00000000 0x00000000 0x400e23a0: 0x00000000 0x00000000 0x00000000 0x00000000 0x400e23b0: 0x00000000 0x00000000 0x00000000 0x00000000 (gdb) x/16wx 0x400e2100 0x400e2100: 0x00000000 0x00000000 0x00000000 0x00000000 0x400e2110: 0x00000000 0x00000000 0x00000001 0x00000000 0x400e2120: 0x00000001 0x00000001 0x00000000 0x00000000 0x400e2130: 0x00000000 0x00000000 0x00000000 0x00000000
We'd appreciate any help on this matter as this issue prevents the product from being viable.