Questions about serial DFU

RE: Questions about serial DFU

gfmoore — Sat, 19 Jun 2021 08:35:03 GMT

This has to be one of the best answers and explanations of what is going on that I have seen on this site.

It should be expanded, updated and put as one of the first documents that beginners should read, not stuck here in an answer. In my opinion there is to much that is assumed in knowledge as to how these things work, especially for newcomers. Well done tesc for your efforts here to an excellent set of questions by Tengfei, even of 3 years ago.

RE: Questions about serial DFU

Aijiapeng — Sat, 07 Jul 2018 03:22:47 GMT

Hello, Liu Tengfei. May I ask you a question ?Have you successfully completed the work of serial dfu? I’m using nrf52832 and SDK 14.2.0. In my project ,there are two dsp,one is nrf52832 and the other is ntk658, they connect via uart with each other. ntk658 supports the sd-card function.What i want to do is using ntk658 read the ble update fw and then transfer to nrf52832 via uart. So i know i need use serial DFU bootloader.Actually,i have done it in my another project. But i used SDK 11.0.0.And the packet format is very clear as following picture shows,

But my question is what the packet format should i send to nrf52832 in SDK 14.2.0? How can i transfer the ble upgrade fw to nrf52832?

RE: Questions about serial DFU

Liu Tengfei — Thu, 12 Apr 2018 12:13:02 GMT

Thank you very much! I've fully understood it.

RE: Questions about serial DFU

tesc — Thu, 12 Apr 2018 10:48:17 GMT

Hi,

1. The bootloader start address is stored in the UICR registers in flash (in UICR.NRFFW[0]), also known as NRF_UICR_BOOTLOADER_START_ADDR or .uicr_bootloader_start_address. This is what is used for deciding where application data is stored. In SDK 14.2, the BOOTLOADER_START_ADDR define is used throughout the code, and it is fetched from the flash settings for the project. Please note however that you cannot do DFU from a bootloader of one size to a bootloader of larger size, as then application data location and bank size calculations might fail.

2. For bootloader update, the new bootloader is first downloaded to a separate location. Then the MBR is invoked for performing the copy operation into the final location. This copy operation is safe. The MBR starts by writing to the MBR parameter storage page in flash what copy operation is to be performed. If it gets aborted (for instance by power failure) it will retry on the next boot.

If the bootloader is successfully updated, but the new bootloader has bugs that prevents it from doing DFU, then you have no choice other than programming the nRF directly. Therefore you should only update to a well tested bootloader such as the ones we provide with the SDK. If you modify it you should be extra careful with testing that it works as intended. This is also a good reason to use Secure DFU, which uses signing to prevent others from making a fake update that bricks the device.

3. That should work, yes.

Regards,
Terje

RE: Questions about serial DFU

Liu Tengfei — Tue, 10 Apr 2018 18:07:17 GMT

Thank you very much for the useful information! I have three more problems here:

1. Because of some limitations, I used a kind of our internal communication protocol between the host and application, and I have to add the protocol to my bootloader to perform DFU as well, but it will make bootloader much larger than 4 kb, I'm not familiar with linker scripts, so I want to confirm that will it be ok if I just update the memory section in secure_bootloader_gcc_nrf52.ld, such as FLASH LENGTH, ORIGIN of bootloader? According to the memory layout of nrf52840 flash, it seems like the application data will also be changed due to bootloader size.

2. The bootloader itself could also be updated over bootloader/DFU, if the new bootloader image has been succefully transferred to bootloader over DFU, but power off occurred during copying the new image to the right place on the flash, how could it be recovered? If the new bootloader has been updated successfully over DFU, but the logic of the new bootloader has bugs and cannot perform DFU, will it be possible to update bootloader again without using JTAG to directly write flash?

3. Since the serial bootloader won't depend on softdevice in SDK15.0, if I implement my bootloader with SDK15.0, but use it to update app & softdevice based on SDK14.1 and softdevice 140 or 132 over DFU, will it be ok?

RE: Questions about serial DFU

tesc — Tue, 10 Apr 2018 16:17:52 GMT

Hi,

1. The mbr.hex is precompiled, just as the SoftDevice. Actually if you investigate the hex files you will see that the MBR is identical to the first flash pages of the corresponding SoftDevice. So you have to take that hex file for programming the MBR.

2. When you have a bootloader, the bootloader is started by the MBR, yes. Then from the bootloader you jump into the application. (In some instances the bootloader enters DFU mode, such as when there is not a valid application, or when DFU mode is triggered by button press or through buttonless DFU.)

If the bootloader has logging enabled, with log level of INFO or more verbose, then I do expect some log lines from the bootloader before the application is started. And you have not replaced the bootloader over DFU as well? You will always jump MBR -> bootloader -> application, if there is a bootloader present.

3. blinky_mbr.hex does not include the MBR.

If you use a SoftDevice then the application is placed directly after the SoftDevice in flash. If you do not use a SoftDevice, and do not use an MBR, then the application is placed at the beginning of flash. If you use MBR (but no SoftDevice), then the application is placed directly after the MBR. That is the reason why building an application for use on its own (blank), for use with MBR, and for use with SoftDevice are different. blinky_mbr.hex is the blinky application built for use with the MBR, but the hex file does not include the MBR.

So yes, you must program both blinky_mbr.hex and mbr.hex to run the blinky example with MBR (but without SoftDevice.)

Regards,
Terje

RE: Questions about serial DFU

Liu Tengfei — Tue, 10 Apr 2018 14:06:57 GMT

Thanks a lot for your kindly reply!

I noticed Nordic has provided SDK 15.0 which has extensive update on bootloader/DFU.

In SDK15.0, only the BLE bootloader is now dependent on the SoftDevice. The others depend only on the MBR (which is now part of the SDK). It's really helpful for my case! So I decided to use SDK15.0 for my application. However, I also have some problems about bootloader/DFU in SDK 15.0:

1. Serial bootloader with DFU in SDK 15.0 does not need softdevice, but it need MBR, SDK 15.0 provided test DFU images in examples\dfu\secure_dfu_test_images\uart\nrf52840, MBR should be programmed to PDK before programming bootloader, but where is mbr.hex from? How to compile the mbr.hex myself without the one provided in the secure_dfu_test_images folder?

2. During system startup, the Master Boot Record (MBR) is responsible for starting the bootloader, if a bootloader is installed. So every time when system startup, even if there was no trigger DFU happened, MBR always will jump to bootloader first, and then after bootloader validates the app, app will be started, right?

But after successfully DFU the hrs_app & softdevice, when the PDK reset, I only see NRF_LOG_INFO trace in hrs_app

and I cannot see any NRF_LOG_INFO trace in bootloader(debug version), does this mean that PDK directly goes into the app without jump to bootloader first?

3. In SDK 15.0, for examples\dfu\secure_dfu_test_images\uart\nrf52840\blinky_mbr.hex, did the blinky_mbr.hex merge from blinky.hex and mbr.hex? If it did, why it was 5kb which was smaller than the mbr.hex which is 8kb ?

If I programmed the blinky_mbr.hex to PDK, do I need to program MBR again before program the bootloader?

RE: Questions about serial DFU

tesc — Fri, 06 Apr 2018 09:25:33 GMT

Hi,

1. Unfortunately we do not have any C++ implementations of DFU.

2. The bootloader needs the SoftDevice mainly for two reasons: First, it needs the Master Boot Record (MBR), which is delivered as part of the SoftDevice. Second, the DFU bootloader was initially written for using BLE, and the serial bootloader is based on that initial BLE bootloader. This means the SoftDevice was originally an integral part of the bootloader and many of those dependencies are still in. While the current version can access flash directly (no longer needing the SoftDevice for flash access) there are still logic and address calculations assuming that there is a SoftDevice in place. Removing the SoftDevice dependency completely (leaving only the MBR requirement) is not an easy task, with the many potential pitfalls and corner cases involved.

3. The application gets built to reside at one particular area in flash, so that jumps in the resulting program (function calls, loops, if statements, etc.) goes to the right place and so that variables are read from the correct memory locations. All peripheral examples comes in a "blank" version, which means they are set to not use a SoftDevice and thus they start at address 0x0. When you use a SoftDevice, the application must start after the SoftDevice, which gives an address depending on the size of the SoftDevice, and in your particular case that is 0x230000.

Some few peripheral examples comes in both a "blank" and a SoftDevice version such as "s132", for instance examples/peripheral/blinky/pca10040 (for the nRF52832). All ble_peripheral examples are set up to use a SoftDevice, and there you can find the correct flash (ROM) settings. RAM settings depend on SoftDevice configuration.

4. We do not have a "buttonless DFU" using serial, but you can use the "enter DFU mode" functionality from the ble_app_buttonless_dfu example (as you mention in (2)) in order to trigger DFU mode. Then you must implement the "button" part of it yourself and use that instead of the buttonless DFU BLE service from that example.

Regards,
Terje