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?