USB DFU – Bootloader Update Process (Nano 33 BLE)

Question

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). 
 
 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? 
 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) 
 
 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? 
 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? 
 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? 
 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? 
 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? 
 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 · Accepted Answer

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

USB DFU – Bootloader Update Process (Nano 33 BLE)

Top Replies