Power Consumption Issue

[NordJus]

I have inherited some code that is production after doing some extensive testing on battery life have noticed that after writing to the flash my power consumption on the Nordic Power profilier increases from approx 20 micro amps to 3 milli Amps, this occurs approx 30 seconds after the write operation.

This has been confirmed by a restart counter to the flash to keep a track of how many times the product has restarted.  With no other operations occurring I can see the power increase after 20-30 seconds.  Removing this code the power level returns to normal

We are using the SDK Version 2 and am reluctant to move to version 6 unless we know that a fix exists for this issue.

I have checked the code and can see that the process is 

errorCode = sd_flash_page_erase( absolutePageNumber );    // Clears the current page

errorCode = sd_flash_write( address, headerData, HeaderLength / sizeof( uint32 ) );   // Writes a header to the page

errorCode = sd_flash_write( address, reinterpret_cast<const uint32*>( data ), length / sizeof( uint32 ) );   // Write configuration data to the page

After each of these requests the code polls for the NRF_SOC_EVTS event and checks whether the operation has been successful, every time it reports success

Has anyone seen anything similar?

[bjorn-spockeli]

Hi NordJus, 

I have not seen issues where calling the sd_flash- API leads to increased current consumption 20-30 seconds after the call has returned and the NRF_EVT_FLASH_OPERATION_SUCCESS event has been received. 

If the current consumption still increases after 20-30 after you have reset the chip after calling sd_flash_write(), then there must be something else going on. 

Which SDK version are you using? If you are using S132 v2.x.x, then my guess is SDK v11.0.0`?

3mA is quite a lot of current so that could indicate the CPU is running and not going to idle(i.e. sleep). However, the current consumption numbers only fit if you're using the DCDC 

CPU current, running from flash, cache enabled, DCDC 3V      3.7 mA

Best regards

Bjørn

[NordJus]

Hi Bjorn

Currently the product is supplied using a AAA battery (1.5V) with a step-up regulator to 3V.  I have just checked and the product us using DCDC.

We are using SDK v11.0.0. 

Just to be clear the increased current consumption occurs 20-30 seconds after the write has been completed and will stay in that level onwards (there is no increase after the write has been completed)

Just removing the sd_flash_write does not show this power increase.

So performing the same actions in the following:

1.   Start the product and do not store the bluetooth peer address using sd_flash_write - no increase in power consumption at all
2.   Start the product and stores the bluetooth peer address uing sd_flash_write - after 30 seconds the power increases to approx 3mA.

My initial feeling was that some callback /event might be occurring from the Nordic is there anything to check for

[bjorn-spockeli]

Are only calling sd_flash_write() once at start-up or is sd_flash_write() called anywhere else in the code?

How are you handling the NRF_EVT_FLASH_OPERATION_SUCCESS event? You mentioned that you were polling for the event?

The sd_flash_write() function will return immediately with NRF_SUCCESS if the flash operation has been queued successfully and then you will get the NRF_EVT_FLASH_OPERATION_SUCCESS event when the operation is done. There is no additional events or callbacks that are invoked. 

Have you verified that the device is not stuck in an error handler or in the Hardfault handler when the current consumption goes from 20ua to 3mA? Is the device functional after the current consumption increase, e.g. can you send and receive BLE packets?

BEst regards

Bjørn

[NordJus]

Are only calling sd_flash_write() once at start-up or is sd_flash_write() called anywhere else in the code?

The only call to sd_flash_write is when the device is paired with a remote central. 

How are you handling the NRF_EVT_FLASH_OPERATION_SUCCESS event? You mentioned that you were polling for the event?

The sd_flash_write() function will return immediately with NRF_SUCCESS if the flash operation has been queued successfully and then you will get the NRF_EVT_FLASH_OPERATION_SUCCESS event when the operation is done. There is no additional events or callbacks that are invoked. 

The code checks that the flash operation has returned NRF_SUCCESS, The code waits for an interrupt from the Softdevice and makes then calls sd_evt_get to check the interrupt.  Once completed the code performs the next write operation, or completes the write operation.

Have you verified that the device is not stuck in an error handler or in the Hardfault handler when the current consumption goes from 20ua to 3mA? Is the device functional after the current consumption increase, e.g. can you send and receive BLE packets?

Every hour the product connects to the remote central and immediately disconnects (to test the connection is still working).  This is continuing for about 4-6 days successfully until the battery reaches a level that the chip can no longer draw enough current.

For testing purposes to investigate this issue I have set the product to perform general non-connectable advertising every 10 seconds.  Every 10 minutes this updates the battery level to give me an indication of the current battery level.

When the battery is removed from the product after the pairing then the connect/disconnect process will continue for currently at least 8 weeks (still units under test).

On a separate line I have changed the code so that after a write operation to allow the watchdog to expire and restart the system this is currently under test to see if this will overcome the issue we are seeing. 

Previously has attempt calling sd_nvic_SystemReset and this did not seem to rectify the issue 

[bjorn-spockeli]

NordJus said:

The code checks that the flash operation has returned NRF_SUCCESS, The code waits for an interrupt from the Softdevice and makes then calls sd_evt_get to check the interrupt.  Once completed the code performs the next write operation, or completes the write operation.

 You should only have to add an event handler to the sys_evt_dispatch() function in main.c, which forwards all system events to the different software modules. See the attached snippet

void ble_advertising_on_sys_evt(uint32_t sys_evt)
{
    uint32_t err_code = NRF_SUCCESS;
    switch (sys_evt)
    {

        case NRF_EVT_FLASH_OPERATION_SUCCESS:
        // Fall through.

        //When a flash operation finishes, advertising no longer needs to be pending.
        case NRF_EVT_FLASH_OPERATION_ERROR:
            if (m_advertising_start_pending)
            {
                m_advertising_start_pending = false;
                err_code = ble_advertising_start(m_adv_mode_current);
                if ((err_code != NRF_SUCCESS) && (m_error_handler != NULL))
                {
                    m_error_handler(err_code);
                }
            }
            break;

        default:
            // No implementation needed.
            break;
    }
}


/**@brief Function for dispatching a system event to interested modules.
 *
 * @details This function is called from the System event interrupt handler after a system
 *          event has been received.
 *
 * @param[in] sys_evt  System stack event.
 */
static void sys_evt_dispatch(uint32_t sys_evt)
{
    pstorage_sys_event_handler(sys_evt);
    ble_advertising_on_sys_evt(sys_evt);
}

You can also check if the nRF52 is not going to its low power mode by checking if teh sd_app_evt_wait() function which is called in the main while loop returns immediately on every call. 

static void power_manage(void)
{
    uint32_t err_code = sd_app_evt_wait();
    APP_ERROR_CHECK(err_code);
}

You could for instance toggle a GPIO pin before and after the sd_app_evt_wait() call and look at the state of the GPIO through a logic analyzer or oscilloscope. If it always returns immediately, then there is probably a pending interrupt that is not cleared. 

Best regards

Bjørn