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.

[campy_electronics]

So, the issue is generated by the activation of DFU which leaves enabled the RTC2 with a compare event.

Since the main app doesn't use the RTC2, these triggers continuously wake up the MCU because there is no clearing of the event.

The workaround that seems to solve the issue is to uninit the RTC2 at startup in the main app.
Why the RTC2 is active after a reset in the DFU remains a mistery up to now.

Here is the code added just at the beginning of the main app "main()":

// Function used to fix the anomalous power consumption once the device exits from DFU
static void workaround_rtc2_after_dfu(void)
{
    // WORKAROUND TO DISABLE ANOMALOUS POWER CONSUMPTION, SHUT DOWN THE RTC2
    NRF_RTC2->INTENCLR = 0x000F0003;
    NRF_RTC2->EVTENCLR = 0x000F0003;
    NRF_RTC2->CC[0]    = 0;
    NRF_RTC2->CC[1]    = 0;
    NRF_RTC2->CC[2]    = 0;
    NRF_RTC2->CC[3]    = 0;
}

int main ( void )
{
    uint16_t ret_code;
    
    // First of all call the workaround, this will solve the issue after OTA DFU
    workaround_rtc2_after_dfu();

    // .... Remaining code
}