USB DFU – Bootloader Update Process (Nano 33 BLE)

RE: USB DFU – Bootloader Update Process (Nano 33 BLE)

GaryDT — Tue, 21 Dec 2021 15:37:28 GMT

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!

RE: USB DFU – Bootloader Update Process (Nano 33 BLE)

Vidar Berg — Tue, 21 Dec 2021 14:20:52 GMT

Good to hear 🙂 I was referring to my remark here:

[quote user="GaryDT"]Except we tend not to use the term "DFU" when using the chip's deticated debug interface for programming.[/quote]

But I see now that I quoted the wrong text.

[quote user="GaryDT"]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?[/quote]

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.

RE: USB DFU – Bootloader Update Process (Nano 33 BLE)

GaryDT — Mon, 20 Dec 2021 17:59:06 GMT

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.

[quote]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,..)[/quote]

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?

RE: USB DFU – Bootloader Update Process (Nano 33 BLE)

Vidar Berg — Mon, 20 Dec 2021 17:33:43 GMT

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.

[quote user="GaryDT"]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?[/quote]

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.

[quote user="GaryDT"]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.[/quote]

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.

[quote user="GaryDT"]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.[/quote]

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.

[quote user="GaryDT"]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?[/quote]

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.

[quote user="GaryDT"]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.[/quote]

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,..)

[quote user="GaryDT"]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?[/quote]

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

RE: USB DFU – Bootloader Update Process (Nano 33 BLE)

GaryDT — Mon, 20 Dec 2021 15:44:46 GMT

[quote]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).[/quote]

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

[quote]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.[/quote]

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?

[quote]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.[/quote]

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?

[quote]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.[/quote]

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.

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

Yes, lol... I see what you mean 😂

But my paragraph continued...

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

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?

RE: USB DFU – Bootloader Update Process (Nano 33 BLE)

Vidar Berg — Mon, 20 Dec 2021 12:57:15 GMT

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.

[quote user=""]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?)[/quote]

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.

[quote user=""]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?[/quote]

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.

[quote user=""]Via this process of replacing the bootloader, is it possible to “brick” a Nano such that it can’t be recovered easily?[/quote]

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.

[quote user=""]Prior to this it seems like my DK acts as a DFU controller which is used to replace the bootloader in my Nano?[/quote]

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.

[quote user=""]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?[/quote]

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.

[quote user=""]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?[/quote]

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

[quote user=""]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?[/quote]

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.

[quote user=""]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).[/quote]

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.

[quote user=""]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. [/quote]

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

Best regards,

Vidar