flash read/write on nRF52840 dongle

RE: flash read/write on nRF52840 dongle

Einar Thorsrud — Mon, 14 Jun 2021 09:20:14 GMT

Hi,

Just to rule out if there is a conflict with the bootloader it would be good to know which page this fails with?

[quote user="brianreinhold"]It's clearly never hit even though SoftDevice has been disabled before these writes are attempted.[/quote]

You cannot call sd_flash_page_erase() when the SoftDevice is disabled. When not using a SoftDevice you should sue for instance nrf_nvmc_page_erase() instead.

RE: flash read/write on nRF52840 dongle

brianreinhold — Fri, 11 Jun 2021 16:12:12 GMT

I have a similar problem and I DO have an nRF52840 DK and the flash write works fine on the DK. I am using fstorage to store pairing keys, CCCD info, and stored measurements.

However, when I port the code over to the nRF52840 dongle, everything works fine until the disconnect at which point I disable SoftDevice and store my data to flash. The program freezes, deadlocks, or somehow dies in the first while loop to write the data (it probably croaks on the first page erase but I have no sure way of telling). I have written to the LEDs using different color patterns to try and see where it actually dies. It's a tedious chore and I have gotten as far as the first while loop and note it dies in there

        while(true)
        {
            err_code = sd_flash_page_erase(pg_num);
            if (err_code == NRF_SUCCESS)
            {
                break;
            }
            if (err_code != NRF_ERROR_BUSY)
            {
                NRF_LOG_DEBUG("Erasing data returned error %u.", err_code);
                APP_ERROR_CHECK(err_code);
            }
        }
        bsp_board_led_on(CONNECTED_LED);

When I put the LED write before the while loop it was called but it does not get called after. I don't think I am messing the bootloader here as I am able to continue to program the dongle. MY gut feeling is that I continuously get BUSY and it tags the CPU as my primary for loop in main has a reset when it sees SoftDevice disabled. It's clearly never hit even though SoftDevice has been disabled before these writes are attempted.

RE: flash read/write on nRF52840 dongle

Edvin — Mon, 07 Dec 2020 13:56:05 GMT

Hello,

[quote user=""]I have a nFR52840 dongle and I dont want to brick it or stuff it up in any way so I'm stuck on what to do.[/quote]

What you need to watch out for is to not write to the memory inside (or used by) the bootloader on the dongle.

I guess you have no way of debugging or monitoring the log of the dongle either, but in case you do, you can check the bootloader address the following way from your application:

static void print_bootloader_start_addr(void)
{
    uint32_t bl_address;
    bl_address = *NRF_UICR->NRFFW;
    NRF_LOG_INFO("Bootloader start addr: 0x%08x", bl_address);
}

You can also check the bootloader address using nRF Connect for Desktop -> Programmer:

Note that this bootloader address is not the same as the bootloader start address of the bootloader in the SDK. The dongle has a customized version. On my dongle, the bootloader address is 0x000E0000, but double check this on your dongle, in case there are multiple versions of the bootloader out there. (I remember that there were some updates since launch).

So I still want to point to the examples SDK\examples\peripheral\flash_fstorage and SDK\examples\peripheral\flash_fds. They do not have pca10059 projects. If you do not already have an nRF52840 DK, I would recommend that you get hold of one before you start this project, because development without the possibility to debug is very difficult. Save your hair, and get a DK.

So as you may understand there are two approaches. FDS and fstorage. FDS uses fstorage, but handles everything you need to think of when dealing with flash.

Some basics:

Flash can only be changed from physical 1's to 0's. This means that a "clean flash" is 0xffffffff. If you want to write a value to a flash address, you it needs to be 0xffffffff before you can do so. When you have written to that address, you need to erase the entire page before you can write to it again. FDS handles this for you. If you choose to use fstorage directly, you need to erase the page before you can write to it again. If you loose power, or reset at the wrong time, you may loose the data you stored in flash.

So, is that important in your application? What happens if you are in the middle of an update, and loose power?

Other than that I can only point to the examples. Look at what the CLI commands does in these examples.

BR,
Edvin