Bootloader Serial DFU without SoftDevice (SDK 15)

RE: Bootloader Serial DFU without SoftDevice (SDK 15)

Cecylia — Sat, 16 Feb 2019 00:08:56 GMT

Hi Andreas,

Thanks! I did use the wrong port. However, I have a very hard time to enumerate the USB for this Bootloader. It only got enumerated properly once by my Windows (and then it shows "nRF52", if I'm not mistaken, on the Device Manager). Then I could upgrade the firmware application successfully.

However, I've been having a really hard time to get it enumerated by the Windows, so that I can't test the FW upgrade smoothly. Since it might be a separate issue, I opened another ticket for that: https://devzone.nordicsemi.com/f/nordic-q-a/43776/bootloader-usb-fails-to-enumerate-device-on-windows-10-nrf-54820-development-kit

But, I could see that the steps you explained worked! Thanks a lot!

RE: Bootloader Serial DFU without SoftDevice (SDK 15)

AndreasF — Fri, 15 Feb 2019 08:22:18 GMT

The nRF USB is located here:

RE: Bootloader Serial DFU without SoftDevice (SDK 15)

AndreasF — Fri, 15 Feb 2019 08:17:41 GMT

Hi again.

I think your issue now is that you have wrong COM port.

You have to use the COM port number that you have connected to the nRF USB:

If i choose WRONG COM port, I get following output:

With the CORRECT COM port, I get the following output:

[quote user="cecyliaw"]Then what is the benefit of using USB? I'm trying to evaluate which one I should implement for our product.[/quote]

This depends on what product you wish to make, if you make something that uses USB it might be suitable to update it by using the USB. Also USB is not doing anything Over the Air (OTA), so this gives you more security if the other alternative is a BLE bootloader which does not have bonding.

Best regards,

Andreas

RE: Bootloader Serial DFU without SoftDevice (SDK 15)

Cecylia — Fri, 15 Feb 2019 03:07:53 GMT

Andreas, actually I just remembered that our production HW is using USB only, so we'll have to use USB. Please let me know why I couldn't run the USB example.. Thanks 🙂

RE: Bootloader Serial DFU without SoftDevice (SDK 15)

Cecylia — Thu, 14 Feb 2019 21:38:42 GMT

Andreas,

Thanks for the detailed answer! That's very helpful. I was able to upgrade via UART by replacing step 7 with:
nrfutil dfu serial -pkg my_blinky_mbr.zip -p COM11

About your answer "The difference between the two bootloaders are that the USB bootloader does not require a signature for the Application and so on, it only requires for the bootloader. The UART bootloader on the other hand is "secure" and requires a signature for all the components (like the BLE bootloader)."
Then what is the benefit of using USB? I'm trying to evaluate which one I should implement for our product.

Also, I tried to use the USB example by doing the previous steps, but replacing the following:

3) secure-bootloader_usb_mbr_pca10056

4) mergehex --merge settings.hex secure_bootloader_usb_mbr_pca10056.hex --output output.hex

7) nrfutil dfu usb_serial -pkg my_blinky_mbr.hex -p COM11

But I got the following error.

Does the USB example require an additional step?

RE: Bootloader Serial DFU without SoftDevice (SDK 15)

AndreasF — Thu, 14 Feb 2019 09:06:49 GMT

Hi.

I think your problem is that you have used the wrong nrfutil command to start the DFU.

As I understand, you wish to do a DFU without using the SoftDevice, that is a DFU over a serial port. You also wish to use the precompiled firmware.

I follow your steps:

[quote user="cecyliaw"][/quote]

Generating keys:
nrfutil.exe keys generate private.key
nrfutil keys display --key pk --format code private.key --out_file public_key.c

Then I generate my own zip file:
nrfutil pkg generate --hw-version 52 --application-version 1 --application blinky_mbr.hex --key-file private.key --sd-req 0 my_blinky_mbr.zip

[quote user="cecyliaw"]

Install micro-ecc - done

[/quote]

[quote user="cecyliaw"][/quote]

Compile the bootloader. -> Should I use "secure_bootloader_uart-mbr_pca10056"? Or "secure-bootloader_usb_mbr_pca10056" ? Debug? no Debug?
I've decided to use: secure_bootloader_uart_mbr_pca10056 no debug. and change the public key with the ones generated from step 1.
Build ran OK.

UART and USB are different transport layers, but this might be confusing in this case. The difference between the two bootloaders are that the USB bootloader does not require a signature for the Application and so on, it only requires for the bootloader. The UART bootloader on the other hand is "secure" and requires a signature for all the components (like the BLE bootloader).

The difference between Debug/No Debug is the possibility to debug. This might be more useful if you had created all the components yourself.

I also used the pca10056_uart bootloader. (examples\dfu\secure_bootloader\pca10056_uart)

[quote user="cecyliaw"][/quote]

If you generated a bootloader settings HEX file, flash it using the following command:
nrfjprog --program --sectorerase settings.hex

I followed another page to generate a basic setting:
nrfutil settings generate --family NRF52840 --application blinky_mbr.hex --application-version 1 --bootloader-version 1 --bl-settings-version 1 settings.hex

nrfutil settings display settings.hex

Then I merged the bootloader settings with bootloader:
mergehex --merge settings.hex secure_bootloader_uart_mbr_pca10056.hex --output output.hex

I also did this.

5)

[quote user="cecyliaw"]

Program the HEX file.
I used nrfConnect's programmer and programmed the following 3 files:
mbr.hex - from C:\Users\cwati\Documents\My Work\Nordic\nRF5_SDK_15.2.0_9412b96\examples\dfu\secure_dfu_test_images\uart\nrf52840
output.hex - from step 4
blinky_mbr.hex - from C:\Users\cwati\Documents\My Work\Nordic\nRF5_SDK_15.2.0_9412b96\examples\dfu\secure_dfu_test_images\uart\nrf52840

[/quote]

I only programmed mbr.hex and output.hex, there is no point in programming blinky_mbr.hex, since this is the firmware you are trying to update your device with.

The device did enter DFU mode

[quote user="cecyliaw"]

Use either nrfutil or a mobile app to perform the DFU:
I power cycled while holding down Button 4 so that LED stops (DFU mode) and ran:
nrfutil dfu ble -ic NRF52 -f -pkg my_blinky_mbr.zip and got error below.

[/quote]

Since you are trying to do a DFU over UART, it would be wrong to use the command nrfutil dfu ble.

If you look at step 9 in the link you sent, you can read this:

So you have to use the command nrfutil dfu serial.

Like i did here: (note that my .zip file is called jada.zip for no reason).

______________________________________________________________________________________________________________________________

Moving on to more of your questions:

[quote user=""][/quote]

1) Does this example "Secure DFU Bootloader over Serial Link (UART/USB)" expect us to use the UART or USB example? Or will either one work?
For running either of those 2 examples, do I need to connect the USB cable on 52840 DK Board to the JLINK port, or to the nRF USB port?

And, when it's in DFU serial mode, do I expect to see, on the Device Manager, something other than "JLINK" on the COM PORT? Because I only see "JLINK" for now.

The difference between the two is as I said in step 3 above. Either will work with the right setup. You only need to connect a USB cable to your nRF52840 DK to the "J-Link port".

When its in DFU mode, is this what you see?

[quote user=""]2) How many hex files do I need to program for an empty DK eval? I think I need to program:
MBR.Hex (resides at 0x0000)
Application (such as blinky_mbr.hex) starting from 0x1000
output.hex, which consists of Bootloader Settings + Bootloader [/quote]

I don't quite understand this question. But I will make a statement which I hope will help.

If you wish to do serial DFU, you either need to program:

1) Bootloader, bootloader settings, MBR

2) Bootloader, bootloader settings, MBR, SoftDevice

If you wish to do a DFU Over the Air (OTA), you need to program:

Bootloader, bootloader settings, MBR, SoftDevice

It should be noted that the MBR is a part of the SoftDevice, but you will do no harm in programming both.

[quote user=""]3) I use the mbr.hex from the example folder, but will we ever have the need to generate or modify mbr.hex?[/quote]

The mbr.hex from this folder is what it is, the Master Boot Record, it should not be modified or generated in any way by you.

I hope this helps.

Best regards,

Andreas