NRF52840 Memory Layout

[Fernando Fontes]

Hi guys,

I'm leading a project with the nrf52840 dongle connected to a Raspberry Pi via the GPIO header. 

The firmware updating options for the Nordic are a bit limited in the sense that the dongle needs DFU via USB port and I don't want to make this extra connection. So instead I'm exploring openocd for programming via the SWDIO & SWDCLK pins. I was able to get it to work with some ease but now I'm struggling to understand the flash memory regions. 

In my project, I'm using Bluetooth and my linker file looks something like this:

MEMORY
{
  FLASH (rx) : ORIGIN = 0x27000, LENGTH = 0xd9000
  RAM (rwx) :  ORIGIN = 0x20002300, LENGTH = 0x3dd00
}

Using the Nordic programming tool and dragging the hex file I can see the address starting in the position 0x27000 as expected and with the length of the program. Doing some calculations 0x27000+0xd9000 = 0x100000, so I was expecting the memory regions from 0x27000 to 0x100000 to be all program-related. However, when I type the command to erase everything from 0x27000 to 0x100000 the bootloader stops working, making me believe that I'm also messing with some bootloader regions... Is that true? Or it is openocd not working as expected?

Also, do you know in what region of the memory are the User Information Configuration Registers (UICR)? I want to avoid deleting it or erasing it by mistake since it would make the regulator use 1.8V instead of 3V.

Best regards,

Fernando Fontes

[Vidar Berg]

Hello,

The bootloader occupies the end of the flash, starting from address 0xE0000. This means the bootloader has been erased in your case. If you want to restore it, you can program the hex file provided at the end of this tutorial nRF52840 Dongle Programming Tutorial 

Also, do you know in what region of the memory are the User Information Configuration Registers (UICR)? I want to avoid deleting it or erasing it by mistake since it would make the regulator use 1.8V instead of 3V.

The UICR starts at address 0x10001000, so it is mapped to a different memory range than the FLASH.

Best regards,

Vidar

[Fernando Fontes]

Hi Vidar Berg,

Thank you for the reply.

So this means that the actual program length should be: B9000 instead of D9000? 

Thank you,

[Vidar Berg]

Hi,

Yes, if you want to keep the bootloader. Also, I forgot to add earlier that if you want to remove the bootloader, you should do a full chiperase to erase the bootloader starting address stored in UICR/MBR to prevent the MBR from trying to boot a non-existent bootloader on subsequent startup. If you do this, it is also important that you update the REGOUT0 register before resetting to keep the IO voltage at 3 volts.

[Fernando Fontes]

Hi,
Well, the bootloader is not a problem. It can stay as it is. I just want to be able to safely update the dongle using the GPIOs of the raspberry Pi since I will make a HAT for the dongle. 

For that openocd seems to be the way. I've successfully erased the program partition without messing with the bootloader thanks to your answer. The only thing that is missing now is the write command. It writes and verifies OK but then the program does not boot. Am I missing something? I'm just writing the hex file.

Best regards,

[Vidar Berg]

Sorry, another thing I forgot to mention is that the bootloader performs a checksum validation of the app image before booting it. This checksum is typically updated during the DFU process. Therefore, I believe the simplest approach would be to erase the bootloader after all. The other option is to re-program the Bootloader settings page (see  Generating and displaying bootloader settings) with the new CRC value and flash it along with the application hex file. But then you will depend on nrfutil being installed on your Pi to generate the settings page.

[Fernando Fontes]

Ok, I was already thinking that it might be something related to either CRC or missing writes to specify where the end/start of the program would be.

If I delete the bootloader, at what address should I write the program for it to start? 

[Vidar Berg]

The start address will remain the same if you use the Softdevice. If not, you can place it at address 0x0 and overwrite the MBR.

[Fernando Fontes]

Ok, so I can do something like: `flash erase_address 0x27000 0xD9000` to delete current APP and Bootloader and then `flash write_bank 0 nrf52840_xxaa.bin 0x27000` to set the new app? 

[Fernando Fontes]

That seems to work but I'm a bit confused how the MCU knows where the program region is. Is the MBR that holds that information? With the program region pointed to the address 0x27000?

Nevertheless, I might need to preserve the bootloader. Without the bootloader I'm not able to halt de NRF now. I'm receiving `[nrf52840.cpu] external reset detected` after trying to halt it... I was only able to halt it when in booloader (DFU) mode. 

[Vidar Berg]

Fernando Fontes said:

Ok, so I can do something like: `flash erase_address 0x27000 0xD9000` to delete current APP and Bootloader and then `flash write_bank 0 nrf52840_xxaa.bin 0x27000` to set the new app? 

The problem with that is that you will still have the bootloader start address stored in the UICR @ 0x10001014 which signals the MBR that a bootloader is present. In other words, when erasing the bootloader, you will also need to erase the UICR. 

Fernando Fontes said:

That seems to work

It will work as long as the flash is erased @ 0xE0000, but if the application reaches this address, the MBR may think that a bootloader is present and try to boot it from that address.

Fernando Fontes said:

Is the MBR that holds that information?

The entry point after reset is always 0x0, for more details, please refer to the Master boot record and SoftDevice reset procedure section of the softdevice specification.

I'm not familiar with openocd, and got a 404 error when I tried to access the documentation now, but I assume it should have an 'eraseall' command to erase the chip so you can just re-program the Softdevice and app. 

With regards to the REGOUT0  register, it can also be set at runtime before enabling the Softdevice:

    // Configure UICR_REGOUT0 register only if it is set to default value.
    if ((NRF_UICR->REGOUT0 & UICR_REGOUT0_VOUT_Msk) ==
        (UICR_REGOUT0_VOUT_DEFAULT << UICR_REGOUT0_VOUT_Pos))
    {
        NRF_NVMC->CONFIG = NVMC_CONFIG_WEN_Wen;
        while (NRF_NVMC->READY == NVMC_READY_READY_Busy){}

        NRF_UICR->REGOUT0 = (NRF_UICR->REGOUT0 & ~((uint32_t)UICR_REGOUT0_VOUT_Msk)) |
                            (UICR_REGOUT0_VOUT_3V0 << UICR_REGOUT0_VOUT_Pos);

        NRF_NVMC->CONFIG = NVMC_CONFIG_WEN_Ren;
        while (NRF_NVMC->READY == NVMC_READY_READY_Busy){}

        // System reset is needed to update UICR registers.
        NVIC_SystemReset();
    }