USB DFU – Bootloader Update Process (Nano 33 BLE)

[GaryDT]

Good Saturday evening,

Up until now I’ve been accessing the registers directly in my Nano 33 BLEs to experiment with Timers, GPIOTE and PPI, all via the Arduino development environment. However, I’ve now got a Nordic nRF52840-DK official development kit. I’m using Segger Embedded Studio and I’ve successfully ran some of the examples within the nRF5 SDK, on my DK.

The official development kit seems awesome, but I also need to transfer binary image executables to my Nano 33 BLEs (…flash program through USB). I’ve also been referring to the following pages amongst others…

Device Firmware Update process

The update process refers to “DFU controller” (i.e., my DK. But, does my PC work in conjunction with my DK, such that the DK, PC, and Nano, are all communicating simultaneously?) and “DFU target” (i.e., any of my Nano 33 BLEs).

1. Considering an nRF52840 chip that’s currently using an Arduino bootloader, communicating with another nRF52840 chip that’s currently using a Nordic Bootloader. Is it DFU mode itself that makes communication possible (i.e., “firmware update standard” …Using a Microcontroller’s DFU Mode, an excellent! article), such that by putting my DK and Nano each into DFU mode, the DK can then replace the Nano’s Arduino bootloader with a Nordic bootloader?
2. Via this process of replacing the bootloader, is it possible to “brick” a Nano such that it can’t be recovered easily?

Secure DFU Bootloader over Serial Link (UART/USB)

1. Paragraph 2: “The example bootloader accepts images…”. I’m guessing that this is referring to binary images (e.g., my own compiled programs) that can be transferred to the DFU target (my Nanos) via nRF Util (Documentation) (which acts as a DFU controller) running on my PC? … Prior to this it seems like my DK acts as a DFU controller which is used to replace the bootloader in my Nano?
2. Setup: (a) “\examples\dfu\secure_bootloader\pca10056_usb”. Providing I fix the following issue “#error "Debug public key not valid for production. Please see …/README.md to generate it"”, I’m guessing that if I select “Build and Run” in SES, it will then turn my DK into a DFU controller that is capable of replacing the bootloader?
3. Setup: (b) Should I now put my Nano into bootloader mode and connect it to my DK via a micro-USB to micro-USB cable (or do I need to connect to the Nano's probe pins, SWDIO, SWCLK, etc)? and then hold down button 4 on my DK and turn it on?
4. USB Setup: “After connecting the USB cable, the development kit enumerates as a COMx port on Windows…”. Does this basically mean that my Nano sees the DK, the same as it sees being connected to a PC?
5. Testing: (a) “DFU procedure” within “Device Firmware Update process”, further up, refers to Creating a firmware package with nrfutil, which seems to follow on from the steps that I’ve mentioned so far by me now using this nRF Util tool. But there are also 10 testing steps listed here under “Testing” (which I appreciate overlap with other areas of Nordic's info centre that I've linked to). Referring to 1. “If you want to create your own firmware package for testing:” – so for example, this will be each time I’ve created some program that I want to run on a Nano? i.e., every time? Referring to 2. Libraries “micro-ecc” & “Cryptography” – because these two libraries are part of this setup/testing process, I'm assuming that I need to install them before I can transfer any of my own programs to my Nanos? Referring to 5. “Program the HEX file.” – it looks like I don’t need to do anything because I’m using SES?
6. Testing: (b) is Open Bootloader with DFU a good alternative? Are there fewer steps involved (the linked example doesn't state much compared to the Secure DFU Bootloader example)? Is Open Bootloader generally considered easier to set up than the Secure DFU Bootloader being referred to in this thread? For nRF Util, I can see there's "Legacy – Uses a simple structure and no security" – therefore maybe this option along with Open Bootloader will work well? (I'm tempted to give it a go now, but I'll wait and hope for some advice... don't want to Brick! a Nano).

Edit: I've read about when using a J-link as the DFU controller for example, that it is connected to a PC via USB lead, and that the DFU target (such as a Nano 33 BLE) connects to the J-Link. Is this correct? And if so, is it the same for when using a DK as the controller? I'm wondering about what is connected to what at any given time – conceivably there could be an independent communication between the DK and the Nano which takes care of replacing the bootloader (i.e., PC not involved)? In any case, after the bootloader has been replaced, can programs then be transfered from the PC to the Nano without the DK being involved, like is done by default when using the Arduino bootloader?

[Vidar Berg]

Hello,

For development and debugging it's generally better to load the FW images directly through the debug interface (Debug and trace) over the SWD bus instead of doing DFU through a serial bootloader.  This will allow you to program and debug your nano from the Segger IDE.

Programming via DFU will limit your debugging options, have a slower transfer rate, and it will prevent you from doing full chip erase (you cannot erase the bootloader itself).

You should be able to program the nano using the Debug output pins on your nRF52840DK. These pins are connected to the on-board Jlink debugger.

The update process refers to “DFU controller” (i.e., my DK. But, does my PC work in conjunction with my DK, such that the DK, PC, and Nano, are all communicating simultaneously?)

Your PC will act as the DFU controller when you do serial DFU (BLE DFU requires a devkit to provide the BLE connectivity), and the board you have connected via USB will be the DFU target. nrfutil can only program one target at a time.

Considering an nRF52840 chip that’s currently using an Arduino bootloader, communicating with another nRF52840 chip that’s currently using a Nordic Bootloader. Is it DFU mode itself that makes communication possible (i.e., “firmware update standard” …Using a Microcontroller’s DFU Mode, an excellent! article), such that by putting my DK and Nano each into DFU mode, the DK can then replace the Nano’s Arduino bootloader with a Nordic bootloader?

It depends on whether the arduino bootloader support updates of itself or not. As this is an arduino implementation, I think it's likely that it only supports application updates for simplicity's sake.

Via this process of replacing the bootloader, is it possible to “brick” a Nano such that it can’t be recovered easily?

Do you have a hex file for the arduino bootloader? In that case, you can restore the original bootloader by re-programming it with the J-link in case it does become "bricked" in the process.

Prior to this it seems like my DK acts as a DFU controller which is used to replace the bootloader in my Nano?

The PC is always be the DFU controller when you use nrfutil. The DK will howver act as a connectivity bridge when you are doing over-the-air DFU with Bluetooth.

I’m guessing that if I select “Build and Run” in SES, it will then turn my DK into a DFU controller that is capable of replacing the bootloader?

The bootloader will make the board capable of receiving FW images over the selected DFU transports (USB, UART, BLE,..). In other words, make it become a DFU target. We do not have any official examples to make the board act as a DFU controller.

Setup: (b) Should I now put my Nano into bootloader mode and connect it to my DK via a micro-USB to micro-USB cable (or do I need to connect to the Nano's probe pins, SWDIO, SWCLK, etc)? and then hold down button 4 on my DK and turn it on?

The nano bootlaoder will probably have a different mechansism to enter bootloader mode. Button 4 is what we use in our bootloader to enter dfu mode (Note: there are other methods to allow buttonless entry into dfu mode as well).

USB Setup: “After connecting the USB cable, the development kit enumerates as a COMx port on Windows…”. Does this basically mean that my Nano sees the DK, the same as it sees being connected to a PC?

Sorry, I'm not sure I understand the question. Both boards will enumare as a COM port when connected to a PC. But neither the nano board or DK has a usb host like the PC has. So you can't connect them toghether like you can with a PC.

Testing: (b) is Open Bootloader with DFU a good alternative? Are there fewer steps involved (the linked example doesn't state much compared to the Secure DFU Bootloader example)? Is Open Bootloader generally considered easier to set up than the Secure DFU Bootloader being referred to in this thread? For nRF Util, I can see there's "Legacy – Uses a simple structure and no security" – therefore maybe this option along with Open Bootloader will work well? (I'm tempted to give it a go now, but I'll wait and hope for some advice... don't want to Brick! a Nano).

The open bootloader will require the same number of steps. The difference with this bootloader is that it allowed unsiged application and softdevice updates. That is, you don't have to provide the private key when generating the DFU distribution packet.

I've read about when using a J-link as the DFU controller for example, that it is connected to a PC via USB lead, and that the DFU target (such as a Nano 33 BLE) connects to the J-Link.

Correct Except we tend not to use the term "DFU" when using the chip's deticated debug interface for programming.

Best regards,

Vidar

[GaryDT]

Programming via DFU will limit your debugging options, have a slower transfer rate, and it will prevent you from doing full chip erase (you cannot erase the bootloader itself).

The debug and trace option sounds very interesting. I hadn't heard of that before.

Your PC will act as the DFU controller when you do serial DFU (BLE DFU requires a devkit to provide the BLE connectivity), and the board you have connected via USB will be the DFU target. nrfutil can only program one target at a time.

But to get to this stage (even when not using BLE), my understanding is that I'll first need to program my nano to have a Nordic bootloader, and that my DK is used to achieve this. Therefore I'm now thinking that I'll need to connect the DK's debug output pins to the nano's SWDIO, SWCLK, etc?

Do you have a hex file for the arduino bootloader? In that case, you can restore the original bootloader by re-programming it with the J-link in case it does become "bricked" in the process.

Last night I did manage to find a few references showing how to restore Arduino bootloaders, although I'm not really intending to revert back to Arduino. Assuming that it is debug output to SWDIO, etc (please correct me if I'm mistaken), I'm guessing that by accessing the board via that connection, a bricked board is always recoverable (in that you can program it to have a new bootloader) as long as the hardware isn't damaged of course?

The bootloader will make the board capable of receiving FW images over the selected DFU transports (USB, UART, BLE,..). In other words, make it become a DFU target. We do not have any official examples to make the board act as a DFU controller.

I've read that my DK can be used to program/replace the Arduino bootloader, and therefore I've been assuming that I'll need to use my DK to do that, as I've mentioned above. I've been imagining (please don't laugh too much) that your bootloader examples perform two tasks: 1) make my DK the DFU controller, and 2) transferred DFU receiver functionality to my Nano. I understand now that that is completely wrong.

My understanding now is that once I have a Nordic bootloader in my nano, I can then program it either by debug and trace, or by DFU USB like I have been so far.

Correct  Except we tend not to use the term "DFU" when using the chip's deticated debug interface for programming.

Yes, lol... I see what you mean 

But my paragraph continued...

...Is this correct? And if so, is it the same for when using a DK as the controller?

So then I will need to use my DK (I don't yet have a J-Link) to program one of your bootloaders to my nano?

Does nRF Util instruct the DK to program the nano, such that the compiled bootloader is residing on the PC, which is then transferred via the DK to the nano? If not, then please kindly explain this part of the process.

To summarise, that would then be: DK (or J-Link) connect to PC via a USB lead, and DK's debug output pins connected to nano's SWDIO, SWCLK, etc, pins?

[Vidar Berg]

I would define it as "DFU" if the nRF gets programmed through any other interface than the SWD, because then you are relying on some existing FW being present (typically a bootloader) on the chip to both enable the interface and store received FW data to flash. While with SWD you can you always re-program the chip as everything is handled in HW.

The nRF52840 IC are "blank" when they leave our factory, but the module vendors will often ship the modules with a per-preprogrammed bootloader to allow customers to program their application without a J-link programmer.

GaryDT said:

But to get to this stage (even when not using BLE), my understanding is that I'll first need to program my nano to have a Nordic bootloader, and that my DK is used to achieve this. Therefore I'm now thinking that I'll need to connect the DK's debug output pins to the nano's SWDIO, SWCLK, etc?

Yes, I think this would be the easiest if not only approach to get the nano board to run the same FW with the same memory layout as the DK.

GaryDT said:

My understanding now is that once I have a Nordic bootloader in my nano, I can then program it either by debug and trace, or by DFU USB like I have been so far.

Yes. You should always be able to re-program the chip via the the debug interface no matter what SW state the chip is in.

GaryDT said:

I've read that my DK can be used to program/replace the Arduino bootloader, and therefore I've been assuming that I'll need to use my DK to do that, as I've mentioned above. I've been imagining (please don't laugh too much) that your bootloader examples perform two tasks: 1) make my DK the DFU controller, and 2) transferred DFU receiver functionality to my Nano. I understand now that that is completely wrong. Sorry for any confusion caused.

Sorry, that probably came out wrong. What I really wanted to point out that programming via the debug interface is not considered to be the same as DFU for the reason mentioned at the beginning of this post.

GaryDT said:

So then I will need to use my DK (I don't yet have a J-Link) to program one of your bootloaders to my nano?

Yes, you can use the DK for this. The on-board J-link has mostly the same features as you get on a standalone J-link.

GaryDT said:

Does nRF Util instruct the DK to program the nano, such that the compiled bootloader is residing on the PC, which is then transferred via the DK to the nano? If not, then please kindly explain this part of the process.

nrfutil is only for DFU. For programming with J-link you can use the same tools you use to program the DK (segger embedded studio, nrfjprog, Programmer app in nRF connect for desktop,..) 

GaryDT said:

To summarise, that would then be: DK (or J-Link) connect to PC via a USB lead, and DK's debug output pins connected to nano's SWDIO, SWCLK, etc, pins?

This summaries the setup. Also remember to connect ground and Vref on target to VTG (pin next to SWDIO) on the DK.

Edit: forgot to add that it's voltage on VTG that makes the DK detect if an external board is connected:

"When the external board is powered, the interface MCU will detect the supply voltage of the board and program/debug the target chip on the external board instead of the onboard nRF52840 SoC."

[GaryDT]

It's my own humour that's not very good... please don't laugh = please feel free to 

That's great information and clarification with respect to defining DFU... thank you kindly.

nrfutil is only for DFU. For programming with J-link you can use the same tools you use to program the DK (segger embedded studio, nrfjprog, Programmer app in nRF connect for desktop,..)

So I only need SES to do the programming. Final question if I may please...

Please confirm about my layman's guess regarding the relationship of transferring data, i.e., use SES to compile bootloader on PC; use SES to initiate/instruct DK to program (effectively transfer) the bootloader to the nano via the DK?

[Vidar Berg]

Good to hear I was referring to my remark here:

GaryDT said:

Except we tend not to use the term "DFU" when using the chip's deticated debug interface for programming.

But I see now that I quoted the wrong text.

GaryDT said:

Please confirm about my layman's guess regarding the relationship of transferring data, i.e., use SES to compile bootloader on PC; use SES to initiate/instruct DK to program (effectively transfer) the bootloader to the nano via the DK?

Yes, this is correct. The DK will automatically detect when an external board (nano) is connected, and then program that chip instead of the nRF chip on the DK. SES will not know the difference.

[GaryDT]

Awesome! Ah the wrong text, lol.

I'll mark your last but 1 reply as the verified answer, since I can only select 1, but obviously all your answers are correct.

I'll finish by saying thank you... "thank you", and wishing myself good luck. Cheers!