Flash corruption caused by power down during writing

[Andrea Pieretti]

Hello,

I'm using nRF52840 chip with nRF5 SDK 15.2.0 ,Mesh SDK 3.1.0 and soft device S140 6.1.1

I'm trying to protect the flash if a shutdown occurs during a write.
Reading in the forum it seems that the POFWARN event does it for me.

I'm trying to configure this event but without success.
I use this code:

nrfx_power_config_t power_config = {.dcdcen = 1};
nrfx_power_init (& power_config);
nrfx_power_pofwarn_config_t pofwarn_config = {.thr = POWER_POFCON_THRESHOLD_V28,
                                                   .handler = power_failure_warn_handler};
nrfx_power_pof_init (& pofwarn_config);
nrfx_power_pof_enable (& pofwarn_config);

If I use this code snippet before enable the softdevice, the nrf_sdh_enable_request() return the NRF_ERROR_SDM_INCORRECT_INTERRUPT_CONFIGURATION error code

If I use this code after enable the softdevice, the program stops when it try to write the POWER->DCDCEN register

What am I doing wrong?

Besides this, what is the best practice to avoid flash corruption it a power off occours during a write operation?

[Einar Thorsrud]

Hi,

You are right that using POFWARN make sense in this setting, as flash writes are not allowed after a POF warning.

You cannot use nrfx after the SoftDevice has been enabled, as it uses direct register access to the protected POWER registers. You could use the power driver (nrf_drv_power) instead after first enabling the SoftDevice, as this use SoftDevice API's when a SoftDevice is present.

Similarly, you cannot write to POWER->DCDCEN when the SoftDevice is enabled, as this is a protected peripheral. Instead you should use the SoftDevice API for this (sd_power_dcdc_mode_set()), or simply set POWER_CONFIG_DEFAULT_DCDCEN to 1 in sdk_config. h and use nrf_drv_power. 

[Andrea Pieretti]

ret_code_t nrf_drv_power_init(nrf_drv_power_config_t const * p_config)

{

#ifdef SOFTDEVICE_PRESENT

if (m_initialized)

{

return NRF_ERROR_MODULE_ALREADY_INITIALIZED;

}

if (nrf_sdh_is_enabled())

{

return NRF_ERROR_INVALID_STATE;

}

#endif

if (p_config == NULL)

{

p_config = &m_drv_power_config_default;

}

ret_code_t err_code = nrfx_power_init(p_config);

if (err_code == NRFX_SUCCESS)

{

m_initialized = true;

}

return err_code;

}

This is the code of nrf_drv_power_init: if the softdevice is already enabled, the function return with NRF_ERROR_INVALID_STATE error code

There is something not clear to me

[Andrea Pieretti]

I've found this method which uses only SoftDevice APIs

I call the sequent code after SoftDevice enable.

ret_code_t err_code = sd_power_dcdc_mode_set(NRF_POWER_DCDC_ENABLE);
APP_ERROR_CHECK(err_code);
err_code = sd_power_pof_enable(1);

APP_ERROR_CHECK(err_code);

err_code = sd_power_pof_threshold_set(NRF_POWER_THRESHOLD_V28);
APP_ERROR_CHECK(err_code);

Now I'm able to catch the NRF_EVT_POWER_FAILURE_WARNING event inside the SoC event observer.

Is this sufficent to avoid flash corruption during power down writes?

[Einar Thorsrud]

Hi,

This makes sense.

Andrea Pieretti said:

Is this sufficent to avoid flash corruption during power down writes?

This will make sure that no writes are allowed to flash after the supply voltage has dropped below the POF warning level. However, weather the flash is corrupted or not also depends on the time it takes from the POF warning until VDD drops below the minimum voltage, in cases a flash write operation was already started before the POF warning. This might be theoretical but could occur if for instance the device starts to draw more current while writing to flash, pulling down the battery voltage. Therefor you should probably add some margin.

[Andrea Pieretti]

Ok, now i'll take care of time margins during flash write.

I'm implementing a BLE Mesh Network using BLE Mesh SDK 3.1.0.
I use the "flash_manager" API to write my user persistent data and I see that these APIs do defragmentation and other smart procedures to manage the flash area.

If there's a a power down during a write session, I've noted that the SDK throw an assert at the next power on:
- mesh_config_backend_file_create
  - flash_manager_add
    - get_invalid_bytes
      - get_next_entry  [ NRF_MESH_ASSERT(p_entry->header.len_words != 0);]

Now I'm trying to avoid this flash corruption using the POFWARN event for my persistent user data writes.

How can avoid this issue for the SDK Mesh Flash Writes (for example, during the provisioning and subscribe/publish configuration phase from the provisioner)?

I've no control in these phases, and a flash memory corruption at the final customer should be critical and irrecoverable.

[Einar Thorsrud]

Andrea Pieretti said:

How can avoid this issue for the SDK Mesh Flash Writes (for example, during the provisioning and subscribe/publish configuration phase from the provisioner)?

Usig POFWARN will prevent all flash writes. This is implemented in HW. From product specification:

If the power failure warning is enabled and the supply voltage is below the threshold, the power-fail comparator will prevent the NVMC from performing write operations to the flash.

[Andrea Pieretti]

ok thanks,

Now I see that, if the power loss occours during a flash erase, the NRF_EVT_POWER_FAILURE_WARNING event inside the SoC raises only after the erase complete.

The SDH_SOC_OBSERVER has already priority 0.

Is it possible to catch the NRF_EVT_POWER_FAILURE_WARNING during an erase operation?

[Einar Thorsrud]

No, that is not possible.