Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

DFU with external QSPI memory

Hi,

   I am working on project, in which we using nordic nRF52840 chip. We need to flash the app+SD+BL image file in external QSPI memory.

After prevalidation, the DFU controller starts to send flash image package, we need to receive this and need to save in external QSPI memory. Once the postvalidation is successful, then read all the flash image package stored in external QSPI memory and write it to internal flash memory.

For that we use secure bootloader example code as reference file. I need to know where i need to modify the secure bootloader code.

I noticed that after prevalidation, the flash is erased in on_data_obj_create_request() function in nrf_dfu_req_handler.c file, and flash is written in on_data_obj_write_request() under the same c file. Is that right?

Thanks & Regards

Mohammad Gouse

  • Hi Hung Bui,

        I have integrated the qspi with secure bootloader code but i am getting .rodata too lager to fit in the flash memory error.

    Can you help me over come this problem

  • Hi Mohammad, 

    This complain is related to the defined size of the bootloader is not big enough (because you added more code in) you would need to move the start address of the bootloader down (FLASH_START) and then increase the size of the flash setting (FLASH_SIZE) for the bootloader. You can change this in the project option (common setting) -> Linker -> Section Placement Macros

  • You are correct, the flash erased when the object is created and it's write when there is a NRF_DFU_OP_OBJECT_WRITE command.

    You then need to modify the functions inside nrf_bootloader_fw_activation.c ( app_activate, sd_activate,bl_activate) to use the image in QSPI to replace the app/bootloader/softdevice in the internal flash. 

    As I'm working in parallel to @Mohammad (different company and project, but similar goal), I'm finding that there might be more required to change than the flash store and copy functions.  Logically the operation is a dual bank operation, with 'Bank 1' being in external flash rather than internal.  However, I'm finding places where the code is assuming that Bank 1 is in internal flash and I'm not sure how to handle this.  For example, nrf_dfu_cache_prepare(), in nrf_dfu_utils.c, has a call to nrf_dfu_bank1_start_addr(), which I could rewrite to return an address that uniquely defines the external flash memory region, however, there is an ASSERT(cache_address <= DFU_REGION_END(bootloader_start_addr)); that would fail in this case.  This implies that this function/file should be modified as well as the ones you've mentioned.  Is this the only other place that needs update, or are there other places I just haven't found yet?

  • Hi Thomas, 

    You are right, there should be other files that require to be updated. I actually haven't tried doing DFU with QSPI myself, so I'm not sure that's all you need or not. But nrf_dfu_cache_prepare() should definitely be modified to cope with the change to QSPI.  

  • Thanks for confirming.  Yeah, it looks like we might actually need to know how this code works before we modify it!  ;-)

    There are just a few places, especially in my case where I'm only using external memory for APP update. It doesn't make sense to mess with SD or BL update since those are critical and, since I'll expect to have to update the APP if these need updating, there will always be internal flash storage available for them.  I'll have to RAM buffer on copy since there isn't a convenient way to transfer directly from External Flash to Internal Flash.  But I'll do this in page chunks.

    FYI, I'll using using base address 0xA0000000 (returned by nrf_dfu_bank1_start_addr()) to signify external flash, as this would be consistent with the Memory Map in the nRF52832 PS.  I'm also using SPI flash, not QSPI, but that's not a fundamental difference for these changes.

    I think I have all I need to get on with this (he said optimistically :-)

Related