Internal flash memory operations when softdevice present

[jfpastrana]

Hi everyone,

First, my current environment is SDK 17.1, s332 v7.0.1 and nrf52832.

We recently have migrated from SDK 14 and we are still facing some problems, we have some doubts about how work with the internal flash memory of Nordic. Our current layout is:

• Bootloader: [ROM] 0x71000- 0xD000 [RAM] 0x20002C00- 0xD380
• Main application: [ROM]0x30000 - 0x1B000 [RAM] 0x20002F70- 0xD090

And we are using one page memory from internal configuration, starting on 0x70000. The problem comes when we try to erase a page after the first booting.

• We start the application
• We write some data above 0x70000.
• We switch off the unit.
• We start again the unit.
• We read what we wrote, and check that it is the same.
• We erase a page - > Not possible.

We are using the following function sd_flash_page_erase, we also have tried fstorage module, but it does not work for us neither. We saw that it is some flash protection on secure bootloader side, we have tried to disable every protection, but it continues without working.

Any idea o recommendation?

Is there any flash protection that we should know?

Which is the better approach from writing into the internal flash memory when you are using secure bootloader, main app and Softdevice?

We will experience some BLE connectivity problems due to the flash operations timing?

Thank you very much,

Javier

[tesc]

Hi,

What bootloader is this?

By default, the Secure DFU bootloader from nRF5 SDK 17 is using the area 0x78000 to 0x7E000. There are other components in addition to bootloader and application, such as bootloader settings page, MBR parameter storage, SoftDevice and Master Boot Record (MBR). What is the complete layout in flash? The default for nRF5 SDK 17 can be read on the Memory layout page of the documentation.

We erase a page - > Not possible.

In what way does it fail? Error message? Flash not getting erased (how do you check?) Please note that flash erase is a time consuming task. Calling the SoftDevice API (or a flash handler API) only queues the operation. At a later point in time, when the operation has succeeded (or failed), you will get notified through an event (or callback.) If for instance the device is reset before the erase has happened, then no erase will have been performed.

Regards,
Terje

[jfpastrana]

Hi,

You can find our complete layout below:

• MBR                       0x00000000 – 0x00000AFF
• Softdevice              0x00001000 – 0x0002F8CF
• Application             0x00030000 – 0x0004862F
• Bootloader             0x00071000 – 0x0007807F
• MBR parameters   0x0007E000 – 0x0007E05F
• Reserved               0x0007F000 – 0x0007F05F

Moreover, we have included the DFU_APP_DATA_RESERVED to not lose the configuration after an DFU update.

It fails because we have checked that the new values are not written, because it does not erase the page. It does not return any error, what we have done is performing a long delay (2.5s) after calling sd_flash_page_erase.

Furthermore, we know that we are able to read and write in this memory section, because, after the first boot time when all of this section is written to 0xFF we manage to write any value, but not afterwards.

Also, we have tried to wait until receive this event NRF_EVT_FLASH_OPERATION_SUCCESS, but we do not receive it.

Also, we have tried to move our writings far from application addresses.

It looks like that function is not able to write in that address because it is protected somehow.

Thanks for your support and best regards,

Javier

[tesc]

Hi,

Based on the bootloader start address of 0x71000 it looks like you have a custom bootloader. The default bootloader placement is at 0x78000. Might there be some wrong settings for bootloader start address? For instance, the bootloader start address should be found in UICR, in the NRFFW[0] register, which can be read at memory address 0x10001014.

In addition to triggering an event, sd_flash_page_erase() should give a return value when you call it. Sometimes you might get an error value (different than NRF_SUCCESS which is 0) when calling this function. In that case, you will not get any event either (since the error return value signals that the erase could not be scheduled.) You might also, if the erase was successfully scheduled, get an NRF_EVT_FLASH_OPERATION_ERROR which you should look for. Even if the operation is correctly scheduled, things might happen that means it fails.

What return value do you get from sd_flash_page_erase(), and are you getting any NRF_EVT_FLASH_OPERATION_ERROR events?

Regards,
Terje