How is the Bootloader safely copied during a BLE DFU?

[droberson]

SDK: 15.2.0

Reference documentation: http://infocenter.nordicsemi.com/topic/com.nordic.infocenter.sdk5.v15.2.0/lib_bootloader_dfu_banks.html?cp=4_0_0_3_5_1_2 

Hello,

I have extensively researched the SDK documentation and Nordic forums but cannot find the answers the the following questions. Forgive me if I overlooked something in the documentation.

1. In a dual-bank BLE DFU, how is the bootloader updated when the bootloader itself is responsible for performing the update?

I understand that the new bootloader is stored in free flash memory when downloaded, but what is responsible for copying the new bootloader to the location of the old bootloader?

What happens if the device loses power during the copy of the bootloader?

2. For a single bank BLE DFU, is the bootloader copy process the same as a dual-bank DFU? It seems that older SDK's did not support single-bank DFU and SoftDevice updates but the newer SDK's do. The only difference that I see is that the application is deleted to make room for the bootloader and SoftDevice download. After the update, the application must be restored.

My assumption was that the bootloader was copied to RAM so that the old bootloader could be updated but I have read that this isn't the case.

Thanks for your help!

Derek

[Einar Thorsrud]

Hi Derek,

1. Safe upgrades of the Bootloader (and SoftDevice) is the responsibility of the MBR, which resides in thr first flash page, starting at address 0. The MBR is a minimal bootloader responsible for copying in place and verifying the bootloader and/or SoftDevice when they are upgraded. 

Bootloader (and SoftDevice) upgrades are always dual bank. If there is not enough available space, the bootloader will erase the application to make room for temporarily storing the new bootloader. Then it will write a command to the MBR settings page (second highest flash page), which is checked by the MBR on every startup. If a command is present indicating that a new bootloader should be copied in place, this is handled by the MBR, which then validates that the copy is successful (identical with the temporary bootloader). If there is a reset at any point in this process before the copying has been successfully performed this will be detected on the next startup and the MBR will attempt to erase the flash and reprogram the bootloader again, until it is successful.

2. Single bank upgrades are only allowed for the application. It cannot be used for bootloader (or SoftDevice), as it would not have been safe.

[droberson]

Hey Einar,

Thanks for your response! I see now that the MBR is responsible for the copy process.

You state that single bank upgrades are only allowed for the application. However, according to the documentation link below, the SoftDevice and Bootloader can be updated in single bank mode.

https://infocenter.nordicsemi.com/topic/com.nordic.infocenter.sdk5.v15.2.0/lib_bootloader_dfu_banks.html?cp=4_0_0_3_5_1_2_1_0#lib_bootloader_dfu_single_bank_sd 

The above link should take you to the section I am referencing, but if not, refer to section "Single-bank updates" followed by subsection "SoftDevice and bootloader". Am I missing something here?

Also, please confirm my understanding of dual-bank vs single-bank updates.

Dual-bank: Copy update into free flash memory without first erasing the application.

Single-bank: Erase the application to make room for the update, perform the update, and then restore the application.

Is my understanding of this correct?

Thanks again!

[Einar Thorsrud]

Hi, 

droberson said:

You state that single bank upgrades are only allowed for the application. However, according to the documentation link below, the SoftDevice and Bootloader can be updated in single bank mode.

No, not exactly. It shows how the SoftDevice and/or bootloader is temporarily placed in the application region. But I understand why you read it like this, as there is a formatting issue in the documentation that makes it look like "SoftDevice and bootloader" is a subsection of "Single-bank updates". In any case looking at the figure shows clearly how this is done, and that it is dual banked.

droberson said:

Dual-bank: Copy update into free flash memory without first erasing the application.

Yes, correct. Dual bank means essentially: 1) first copy to a temporary location in flash and validate that everything is ok. 2) copy the already validated new firmware to the correct location. As everything is validated, this cannot fail. If a reset occurs at a "bad" time, it is just a matter of trying to copy again, and this is handled automatically.

droberson said:

Single-bank: Erase the application to make room for the update, perform the update, and then restore the application.

Yes, that is correct. The down side is that if something goes wrong with the transfer or validation of the image, there is no valid firmware to run. This is OK for the application, as then the bootloader would just enter DFU mode. But if it happens to the bootloader (or SoftDevice if you do DFU over BLE), the device will effectively be bricked. That is why dual banking is required for the bootloader and SoftDevice.

[droberson]

" It shows how the SoftDevice and/or bootloader is temporarily placed in the application region."

Is this not a single-bank update by definition since the application is deleted to make room for the SoftDevice and bootloader as depicted in the diagram?

"In any case looking at the figure shows clearly how this is done, and that it is dual banked."

The diagram description actually says it is a single-bank update. Is the description wrong as well? Also, you confirmed that the definition of a single-bank update is that the application is deleted to make room for the update itself. Is this not what the diagram is demonstrating? It clearly shows that the application is deleted to make room for the SoftDevice and bootloader.

In regards to single-bank: "The down side is that if something goes wrong with the transfer or validation of the image, there is no valid firmware to run. This is OK for the application, as then the bootloader would just enter DFU mode. But if it happens to the bootloader (or SoftDevice if you do DFU over BLE), the device will effectively be bricked. That is why dual banking is required for the bootloader and SoftDevice."

Lets say we are updating the bootloader in single-bank mode and that this is possible. Based on the diagram above and according to the definition of single-bank updates, the following would occur.

1. The application is erased to make room to download the bootloader.

2. The bootloader is downloaded into the now free flash memory previously occupied by the application.

3. The MBR then validates the new bootloader and proceeds to copy and overwrite the old bootloader with the new one.

If the device were to lose power during this time, the new bootloader would still reside in flash and the MBR could restart the copy process until it succeeds. Effectively, operating the same as in the dual-bank scenario. The only difference being that the application was deleted to make room for the new bootloader download.

Sorry to keep asking but something doesn't make sense here. Either the documentation and diagram is completely wrong or you can in fact perform a SoftDevice and Bootloader update in single-bank mode.

Thanks for being patient with me and clarifying the documentation.

Derek

[droberson]

Any update on this?

Thanks!

[Einar Thorsrud]

Hi Derek,

I am sorry for the late reply (I am out of office).

droberson said:

Sorry to keep asking but something doesn't make sense here. Either the documentation and diagram is completely wrong or you can in fact perform a SoftDevice and Bootloader update in single-bank mode.

If your definition of dual bank is on the system as a whole, then I see that you could call this something else. Looking at it from a pure SoftDevice and/or bootloader perspective (which is what is important for not bricking the device), we see it as dual bank for the reason I have descried. It seems from your last post that you have a correct understanding of how this works, so I guess this is mostly a matter of semantics.