How to reflash the soft device without MBR

[Aurele]

Hello,

I'm flashing a bootloader (DFU) and then i'm flashing my application but each time i flash the application, Segger Embedded reflashes the softdevice and the MBR. As a result, it erases the address 0xFF8 and 0xFFC that contains the bootloader address and then the FDS cannot identify the right area where to write.

Is it possible to not upload the softdevice when i flash my bootloader or at least the MBR part ?

THank you in advance,

Best regards,

Aurélien

[Einar Thorsrud]

Hi,

You can prevent the SoftDevice from being flashed automatically by changing/removing the additional load file as shown here:

We do not provide SoftDevice .hex files without the MBR, but you could strip out the MBR for instance by combining hex2bin, then strip of the lower 0x1000 bytes and convert it back with bin2hex.

I did not this would be a practical problem, as the MBR should check the UICR for the bootloader start address if the 0xFF8 and 0xFFC are empty (in order to be backwards compatible). Which SoftDevice/MBR version do you use?

[Aurele]

Hello Einar,

Thank you very much for the reply.

Indeed, i tried to not upload the softdevice like you propose but i'm still having issues.

I'm doing the following steps : 

- i erase all the memory

- i flash, by using swd, the DFU with the softdevice + MBR (0xFF8 and 0xFFC are updated with the right address)

- then, i flash, by using swd, the application without uploading the softdevice but unfortunatly the application cannot start, i guess there is something missing in it so that the DFU can jump on it. Or maybe there is something indicating to the DFU to stay in DFU ?

My SoftDevice version is 6.1.1 and i'm working with SDK 15.3.0

Best regards,

Aurélien

[Einar Thorsrud]

Hi,

Aurele said:

- then, i flash, by using swd, the application without uploading the softdevice but unfortunatly the application cannot start, i guess there is something missing in it so that the DFU can jump on it. Or maybe there is something indicating to the DFU to stay in DFU ?

Yes. The bootloader performs a CRC check of the application at startup, and will enter DFU mode instead of starting the application if the CRC does not match. You can verify this by using the debug bootloader with RTT logging, which should state that the app is not valid. There are a few ways around this when debugging:

• The simplest is to modify the bootloader while testing so that it never performs a CRC check of the application. You can do this by modifying crc_on_valid_app_required() in <SDK 15.3>\components\libraries\bootloader\nrf_bootloader.c so that it always returns false.
• Alternatively, you must generate a new bootloader settings page using nrfutil every time you flash a new application, and program that as well. You can program it using nrfjprog with the --sectorerase option so that all other pages are preserved.

[Aurele]

Hi,

Thank you very much for the explanation. Indeed, i discovered what bootloader settings is and i understand the behavior i have now. But i have one more question regarding my appliction. When i upgrade it via DFU, all is working fine, it boots on the application after the upgrade but then it fails to start. I'm suspecting "fds_init" function to fail.

I'm saying that because, then,  after flashing my application by using SWD, i can see : 

<info> app: MBR_BOOTLOADER_ADDR : 0xFFFFFFFF

<info> app: MBR_PARAM_PAGE_ADDR : 0xFFFFFFFF

<info> app: MBR_UICR_BOOTLOADER_ADDR : 0xFFFFFFFF

<info> app: MBR_UICR_PARAM_PAGE_ADDR : 0xFFFFFFFF

So, i think when i flash the application by using SWD it erases the MBR part. I would like to know if it is possible to keep the bootloader start address somewhere else to be sure they are not erased. I heard about the UICR registers. Is it the right way, when do i need to populate these registers ? 

Thank you very much,

Regards,

Aurélien

[Einar Thorsrud]

Hi,

Aurele said:

I'm saying that because, then,  after flashing my application by using SWD, i can see : 

I assume these numbers are the content at the addresses (for instance MBR_BOOTLOADER_ADDR shows the content at (uint32_t*)0xFF8). Either this is not the case (you print something you did not intend to), or there is something else happening. This is in the MBR region, but these words are part of the bootloader .hex file. It can only be reset to all FF's if you have performed a page erase on the MBR page? Or never flashed the MBR?

I suspect you have done something odd, but not entirely sure what. could it be that you first programmed the bootloader, then programmed the SoftDevice (including MBR) using --sectorerase? If so, this would explain it.

If the bootloader address is not present as in this case (all FF's), the MBR will jump straight to the application instead of the bootloader. In this case, FDS will also think that the FDS pages are in the end of the flash, but those will be corrupt since it is actually the bootloader that has been flashed here (FDS requires pages to have a FDS header, alternatively empty so that it can initialize them).