flash read/write on nRF52840 dongle

[damo76]

Hello there,

I'm ripping my hair out hear reading everything I can to get the non volatile memory reading and writing.

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.

All I want to do (for now) is write to a 32 bit space somewhere, have it stored when the power is turned off, and read it when the module is turned on. 

I've done a bit of coding on this module already so I'm not a complete beginner but I need help picking the correct memory area, and where to put it into the code so that I dont mess up anything else or cause it to overwrite the bootsector etc.

Please can anyone help? I only need to read and write a single 32bit word and the damn thinng is so complicated to figure out. and yes I've read everything on here, all the info in the datasheet and sdk and I'm still not getting where I need to write this word to and if it will be overwritten by code etc...   Any help would be greatly appreciated. And please dont just simply point mne to the sdk examples because I've already spend ages trying to figure them out, and they are for the pca--56  and not the pca--59  so its doing my head in. I've ran out of brain power here

[Edvin]

Hello,

 

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.

 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

[brianreinhold]

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.

[Einar Thorsrud]

Hi,

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

brianreinhold said:

It's clearly never hit even though SoftDevice has been disabled before these writes are attempted.

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.