Anomalous RTC2_IRQn generated after DFU

[campy_electronics]

EDIT: the IRQ is always generated by the RTC2, the Radio is not involved

Hello,
we are facing a strange issue with the FW development on nRF52832.
Suddendly after a FW update OTA via BLE (using a slighly changed version of Secure BLE DFU Bootloader) the MCU starts consuming a lot (about 3.3mA) but keeps working as expected for the remaining functionalities.

Here is the conditions generating the issue:

HW: nRF52832

FW: SDK 16, sd132 6.1.1

BLE Role: Single connection as Peripheral

1. Update only the Main App using OTA update via BLE, bootloader is the one present in ..\examples\dfu\secure_bootloader\pca10040_s132_ble with minor changes into the user init of dfu;
2. At restart, clear the whitelist deleting the previous peer if present;
3. Bond with the Central, bonding procedure is started by the Central with pm_conn_secure(...);
4. Disconnection and reconnection of the Central randomly generated;

As a consequence of the above steps the MCU after a short time (seconds to minutes) starts consuming around 3.3mA.
Not sure that step 4 is affecting the phenomenon since it occurs both during the connected and disconnected status.

Debugging we managed to retrieve the cause of the anomalous consumption by printing in the nrf_pwr_mgmt_run the wake up source from idle.
The RTC2_IRQn  is continuosly generated (I suppose from the Softdevice since there is no use of RTC2 in the code) with a frequency of about 7350 Hz, therefore continusly waking up the MCU from the sd_app_evt_wait().
The MCU continues working but with a usage percentage around 75% (all due to the interrupts) and therefore an high power consumption.

This strange behaviour occurs only after a FW update via OTA, I couldn't reproduce it differently.

As a workaround at the moment we are counting the number of interrupts per second in the nrf_pwr_mgmt_run , in case it exceeds a reasonable threshold (2k events) we reset the MCU, therefore we avoid the anomalous consumption from draining the battery. However this is not a solution but just a workaround.

Suggestion on the reasons behind these strange triggers and how to avoid them?

In case you need more details or info please let me know.
I will share what we possibily could share.

[Sigurd]

Hi,

1) Are you seeing this on custom HW, or the nRF52832 DK? 

->If you are using custom HW, are you able to reproduce it on the nRF52832-DK?

2) Are you able to reproduce this with the latest nRF5-SDK version ,and SoftDevice version ?

[campy_electronics]

Hi Sigurd,
tentatively I created a fork project of the one described above using SDK 17 and softdevice sd132 - 7.2.0

The problem of the anomalous power consumption due to continuous interrupts persists, nothing changed.
Did you find something?

[Sigurd]

Hi,

campy_electronics said:

As you can see from the log, in this case the trigger is generated by the RTC2 instead of the RADIO, however, the RTC2 is not even initialize in our code.

The RTC2 timer is used in the bootloader project. So could be that it's somehow still running after your application is booted.

Suddendly after a FW update OTA via BLE (using a slighly changed version of Secure BLE DFU Bootloader)

What was slighly changed?

[campy_electronics]

Hi,

Sigurd said:

The RTC2 timer is used in the bootloader project. So could be that it's somehow still running after your application is booted.

I noticed that but we did not change the code regarding the RTC2 used by the watchdog and timeout timers. And if the RTC2 was still enabled, it should trigger the interrupt regularly from the restart of the code in the main app. Instead, the time it takes to manifest the anomalous triggers is variable.

Sigurd said:

What was slighly changed?

We replaced the "nrf_bootloader.c" with a custom_nrf_bootloader.c, which is almost the same but differs in  the "loop_forever" function where we added a function that changes the advertising name with a runtime built one and manages the switches and leds of the custom board.
The functions for managing the leds use the apptimer from nordic though. I will try to remove these functions and run the test once again.

[campy_electronics]

campy_electronics said:

I will try to remove these functions and run the test once again.

I tried this out, the problem is still there even with standard bootloader without any customization.

My guess is that it is related to the writing in flash with FDS using SD, since the problem occurs when we bond to the central and write the peer info in flash, however it is unknown why it manifests only after OTA update.

On the PCA10040 the time it takes to enter the continuous trigger is around 150s, however we have no timer set to this extent in the code. Is there anything in the sd?

[Sigurd]

campy_electronics said:

however it is unknown why it manifests only after OTA update.

If you after the OTA update, turn the device off, and on again, do you still see the issue?

[campy_electronics]

Sigurd said:

do you still see the issue?

Turning OFF and ON the board the issue never occurs.

The problem is only at the reset after the bootloader OTA.

[Sigurd]

Hi, could you check the RTC2 registers in your app when starting up again after the DFU?

https://infocenter.nordicsemi.com/topic/com.nordic.infocenter.nrf52832.ps.v1.1/rtc.html?cp=5_2_0_24_9#topic