DFU in external memory

[amarin]

Hi,

I am working on doing a DFU over UART into my nrf52840 DK using the external memory provided. I want to be able to store the new init and firmware packages into external memory, then be able to move it from external to flash after validation. I am having trouble trying to figure out how to go about doing this. I have been going through some of the Devzone posts and know this is possible, but I am still confused about where to start with going about this. I still consider myself a beginner with Nordic, so any help is appreciated!

[Vidar Berg]

Hi,

It is possible to add support for external flash as you say, but it will require some major changes to the existing SDK bootloader. What's the motivation for using QSPI flash in this case, if I may ask? External flash will not let you update any larger FW images assuming DFU is handled within the bootloader.

[amarin]

Hi, 

We are currently running firmware on the nrf52840 DK. We do not want to loose any of our code while performing a DFU in case it were to fail, so we purchased an external memory that would be able to hold the new firmware without erasing the old until the new one has been post-validated. Since QSPI is faster and all of the sample code and nrfjprog use QSPI, I thought it would be safer to use QSPI. However, the chip we are using can do SPI, Dual SPI and QSPI just in case I need to switch to SPI.

[Vidar Berg]

Hi,

The DFU process is designed to be fail-safe even when you don't have enough flash to perform a dual banked update (Dual-bank updates). There is nothing wrong with using QSPI flash. The only problem is that you have to modify the bootloader to support externally mapped memory.

[Dominik Eugster]

Hi

Is there an update? I have the same "problem" but it seems that nobody shared or explained in detail how to solve this exactly. I guess a lot of users need this QSPI external flash memory instead of the internal one but like to us ethe same features like the standart nordic dfu ota with all crypto features included, only transfer the bin and dat file (converted to hex before) over the QSPI instead of the BLE OTA.

Thanks for an update

[Vidar Berg]

Hi,

Unfortunately, we do not have a guide that outlines the steps required to add support for external memory in the bootloader. We have received some requests for this over the years, but not many. Did you want to use the existing BLE DFU transport to upload the FW images to the QSPI flash?

[Dominik Eugster]

Hi Vidar

No, the transport to the QSPI flash is already done by a custom made function over BLE Mesh. The goal is to handle this file in the QSPI similar like the dat and bin files from the App received over BLE. And use all crypto and CRC features from the Nordic bootloader.

[Vidar Berg]

OK, I see you already created a ticket for this here:  nrf5_SDK secure bootloader with external QSPI Flash Image . What you are trying to do is different from the scenario described by OP.

Since you're receiving updates from the main app, you should enable the NRF_BL_DFU_ALLOW_UPDATE_FROM_APP setting in the bootloader. This will allow the app to store the init command (i.e., the content of the *.dat file) directly on the bootloader settings page. Next, in nrf_bootloader.c, modify the postvalidate() function to utilize the QSPI driver API for accessing the FW image. Lastly, you have to modify the nrf_bootloader_fw_activate() function to enable the copying of the FW image from external flash to internal flash.