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

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

Hung Bui — Mon, 02 Jan 2017 11:39:51 GMT

The final application should always be copied starting from MAIN_APPLICATION_START_ADDR ( right after the softdevice) regardless it was updated using dual bank or single bank. Please have a look here with attention to "DFU flash operations for a dual-bank application update" and "DFU flash operations for a single-bank application update"

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

Jarmo — Mon, 02 Jan 2017 11:22:37 GMT

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?

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

Hung Bui — Mon, 02 Jan 2017 09:59:48 GMT

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.

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

Jarmo — Fri, 30 Dec 2016 14:31:22 GMT

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?

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

Hung Bui — Fri, 30 Dec 2016 14:11:21 GMT

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) .

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

Jarmo — Fri, 30 Dec 2016 13:30:37 GMT

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