This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Over-the-air DFU requires two uploads (SDK12.0.0 + S132 3.0.0)

We made a version of bootloader_secure for our own purposes. The problem is now that application must be uploaded twice into the device (nRF52) before it really gets updated. I guess it is because of dual banking and for some reason, the bank is not changed when application is uploaded.

So I am asking if somebody knows where in the bootloader_secure is the code fragment that makes the bank changing, and what possibly goes wrong there? On the other hand, I don't find mentions of dual banking from the code (quickly peeking), so could there be some other reason for that behavior?

  • I have now tried to set s_dfu_settings.bank_layout = NRF_DFU_BANK_LAYOUT_SINGLE after nrf_dfu_settings_init() but this did not help. Debug prints look like following. After first upload, it says "Current bank is bank 0" but then it stays always at bank 1.

    :INFO:Doing postvalidate
    :INFO:Current bank is bank 1
    :INFO:Successfully run the postvalidation check!
    :INFO:Erasing old settings at: 0x0007f000
    :INFO:Could not queue writing of DFU Settings
    :INFO:Erasing old settings at: 0x0007f000
    :INFO:Could not queue writing of DFU Settings
    :INFO:Erasing old settings at: 0x0007f000
    :INFO:Erasing: 0x0007f000, num: 1
    :INFO:Writing 0x00000057 words
    :INFO:Writing settings...
    :INFO:Sending Response: [0x4, 0x1]
    :INFO:Resetting device. 
    :INFO:In nrf_dfu_transports_close
    :INFO:num transports: 1
    
  • The bank swapping is done inside nrf_dfu_app_continue().

    What do you have after :INFO:num transports: 1 ? Would the device reset and you are back to main ? You may want to post the full log. You may also add a break point ad check why the new application is not consider valid app (nrf_dfu_app_is_valid()) and the bootloader stay in bootloader mode instead of the application.

    You can also record the two logs, and compare what make the difference between the first and the second update.

    Have you tried to get the hex dump and check if the image is actually copied into bank 1 (or bank 0 if you are using single bank) .

  • It does not stay in bootloader but enters into the previous version of application. Is it sure that the original example (bootloader_secure) works correctly? Because everything looks to work, It took me a while to notice that the application is truly updated only after the second upload. In the bootloader main.c there is the call nrf_bootloader_app_start(MAIN_APPLICATION_START_ADDR), is that taking dual banking into consideration?

    The way I got the system finally working was to disable dual banking brutally from nrf_dfu_utils.c. What would be the correct way to set dual banking off, to use NRF_DFU_BANK_LAYOUT_SINGLE?

  • Hi Jarmo,

    The bootloader_secure is at production level, it's tested properly. Could you try to test again with the unmodified bootloader debug version and the provided .zip package in \examples\dfu\ble_dfu_send_hex\test_images_update_nrf52 ?

    How did you flash your application for the first time, would it work when u do the first DFU or also only works on the second trial ?

    nrf_bootloader_app_start() won't take dualbank or single bank into consideration, it simply start the application at MAIN_APPLICATION_START_ADDR which is the address right after the softdevice.

  • The first flash is also do with DFU and it works as expected. After that, I need to do DFU twice, always.

    The original bootloader_secure uses also nrf_bootloader_app_start(MAIN_APPLICATION_START_ADDR), so how can it work with dual banking, if you say that call does not take dual banking into consideration? Is that a bug?

Related