Questions about serial DFU

[Liu Tengfei]

Dear Support Team,

I’m using nrf52840 with PCA10056 and SDK 14.1.  I want to make a DFU feature using SPI as its transport layer. Could you please help me about the following questions?

1. I could find some Nordic bootloader examples which could be easily used as DFU target, but I did not find any DFU controller examples by C++ code. I noticed that nrfutil(python) and ios/andriod apps that could be able to perform DFU, but I wonder, do you have any c++ source code that could be reused as DFU controller?Or if I want to use DFU service, I have to implement DFU controller logic in C++ myself ?

2. I started with the examples\dfu\bootloader_secure_serial, I think this serial bootloader doesn't need to enable sofdevice at all, but why it need to program the SoftDevice before run this example? (Regarding to the instruction in Nordic docs)

3. Also for the examples\dfu\bootloader_secure_serial, I followed Nordic instructions and everything was right (program softdevice/serial bootloader, make zip package and perform DFU, but I don't merge bootloader setting), I successfully updated an application firmware of examples\peripheral\uart to my PDK through DFU over UART. Since I used debug version bootloader, RTT log showed that nrf_bootloader_app_start with address: 0x23000 after DFU done. However, the uart application couldn't work as expected. I did some test myself, if I directly programmed uart example to my PDK, it worked! Also if I change it's flash location from FLASH (rx) : ORIGIN = 0x0000, LENGTH = 0x100000 to FLASH (rx) : ORIGIN = 0x23000, LENGTH = 0x10000 in the .ld file, and then programmed it to PDK, it also worked! So why it cannot work as expected after successfully DFU and jump to the flash address of 0x23000?

4. Since my device doesn't have any buttons and leds, I have to make an DFU API in DFU controller to trigger DFU while DFU target was running application.

(1) When the host call DFU API, a specified command will be sent to DFU target(I planned to do like this), does Nordic have such command in DFU service? or I need to defined a custom command myself?

(2) When the DFU target receive the DFU command, it will do sd_power_gpregret_set(0, BOOTLOADER_DFU_START),  disconnect all the connections and then reset, go into DFU mode after reboot, right?

But how could host know about whether the DFU target was ready in DFU mode or not? Do I need to reponse a specified command to tell host that it was ready to DFU after it reboot? Do I need to clear the SD_POWER_GPREGRET_SET after DFU done?

Best regards,

Tengfei.

[tesc]

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

[Liu Tengfei]

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?

[tesc]

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

[Liu Tengfei]

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?

[tesc]

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