Buttonless DFU with: application + softdevice + bootloader. Application doesn't boot

[0x4141]

Hello all,

We sell BLE devices with pre-programmed firmware, which has the ability to be remotely updated using the nordic buttonless DFU service based on a modified version of the secure bootloader.

Our customer wishes to use their own application + bootloader, and we would like to make that update using the buttonless DFU service.

Some technical info:

  Customer SDK version: 15.0.0 (EDITED: Previously: 5.0.0)

  Customer SoftDevice FW ID: 0x9D (s132)

  Our SDK version: 17.0.1 (EDITED: Previously: 7.0.1)

  Our SoftDevice FW ID: 0xCB (s132)

  Hardware: BMD-350 (nrf52832 base)

  The DFU zip package is generated using the command:

nrfutil pkg generate --application app_v0.1.1.hex --application-version-string "1.0.0" --bootloader bootloader.hex --bootloader-version 2 --hw-version 52 --sd-req 0xCB --sd-id 0x9D --softdevice s132_nrf52_5.0.0_softdevice.hex --key-file dfu_private_key.pem complete_dfu.zip

The issue is: When we update using this DFU zip file, the customer bootloader starts running. But the application never starts, not even after waiting for the customer bootloader to time-out (which it never does).

This indicate to me that the application is not successfully received by the device. But the application runs without problem when flashed to the device using SWD.

As I understand it, the bootloader and SoftDevice are programmed first when using DFU and the application is programmed afterwards. How come only half of the process is successful?

Best regards

[Edvin]

Hello,

Have you tested your bootloader with nrfutil? Do you make it work on your end? Do you make it work if you generate an application image using SDK5? Is the nrfutil version that you and the customer is using supporting SDK5?

Is the bootloader start address the same in your bootloader and the customer's bootloader?

Let us start there. Let me know whether you have tried this yourself.

As I understand it, the bootloader and SoftDevice are programmed first when using DFU and the application is programmed afterwards. How come only half of the process is successful?

Does the device start advertising as a DFU target after the softdevice + bootloader is transferred? 

The SDKs you are using are quite old, so I don't think the current versions of nrfutil are working with them. That is why I ask about whether or not you have tested it.

Best regards,

Edvin 

[0x4141]

I have been successfully using our bootloader for updating application before, but I have never tried updating bootloader + SD + APP in a single package.

Yes, the device start advertising as bootloader, with the custom bootloader name implemented by our customer. So their bootloader manage to start after the SD + bootloader is transferred. This is one of the things that confuse me: Is this expected behaviour? Or should it boot into the application? (which was transferred in the same DFU package)

The start address is different. Is this a problem? Since we update the entire FW (bootloader + SD + APP) to that of our customer. So we just assumed that our old FW wouldn't interfere. Or must the start address always be the same as of the original FW image that was programmed to the device in production?

[Edvin]

0x4141 said:

I am using sdk 17.0.1 and my client is using SDK 15.0.0.

 I recommend that you switch to 17.0.2, since the 17.0.1 is no longer public due to some bugs. The 17.0.2 is identical, except for the bugs, so your applications/bootloader should work without modifications.

Besides that, I see that SDK15.0.0 and SDK17.0.2 has the same flash start address for the bootloader, so did you change the start address for the bootloader?

 

0x4141 said:

The start address is different. Is this a problem? Since we update the entire FW (bootloader + SD + APP) to that of our customer. So we just assumed that our old FW wouldn't interfere. Or must the start address always be the same as of the original FW image that was programmed to the device in production?

 The issue is that the bootloader address is programmed into the UICR, and the bootloader doesn't update this during runtime. Did you change the start address yourself? Or did the customer change theirs? If possible, the easiest fix would be that they use the same start address as yours, so if you increased the size, they can do to. If you decreased it, however, the customer may not be able to do the same. Let me know what the situation is.

 

0x4141 said:

This is one of the things that confuse me: Is this expected behaviour? Or should it boot into the application? (which was transferred in the same DFU package)

 When the application is included in the same DFU image as the BL + SD, then it actually creates two DFU images. It will first update the SD + BL, and then the application when this is done. I don't know what they use to perform the DFU, but if they are using a custom name, perhaps the DFU master is looking for something else? What are they using as the DFU master? Perhaps they can try to do the update in two parts, and when they update the application, they can specify what advertising name the DFU master should look for.

Best regards,

Edvin