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