How to automate the entrance in bootloader mode on nRF52840 USB dongle?

[Cedric ABGRALL]

Dear DEVZONE,

We are working on Nordic nRF58480 USB dongle for Thread activities.

We are using one testbench on which we need to automate with Python scripts reprogramming of the USB dongle with a new firmware.

To this end, we need to reflash the USB dongle; but nRF52480 requires a pression on a small button to enter into bootloader mode, and this is incompatible with automation.

We may find an HW fix to solve this limitation but we are rather wondering whether you have another solution you could propose?

 

We found a DFU trigger library (USB) thread but we did not succeed in exploiting it.

nRF5 SDK v17.0.2: DFU Trigger Library (USB)

 

Similarly, we found this document specifying the Device Firmware Upgrade over USB.

DFU_1.1.doc

 

Could you please support or advise us?

Warm regards

Cedric

[Hung Bui]

Hi Cedric and Tom, 

Could you please let me know which SDK your application on the dongle is built on ? 
If your application is on the legacy nRF5 SDK I don't think adding MCUBoot would be the best option as it involve nRF Connect SDK. 

Putting the nRF52840 dongle to DFU mode is quite simple. During booting up, the bootloader will check for the reset reason and if it's s a pin reset it will enter DFU mode. You can find this code in the bootloader (nrf_bootloader.c):

So the task for the application is to toggle a GPIO pin that connect externally to the reset pin to trigger a pin reset from the software. This is exactly what the DFU trigger library does. 
You can find many of our application for the dongle already support this, for example you can switch between the firmware for the NRF52840 dongle for nRF Connect for Desktop -> Bluetooth Low Energy application and nRF Connect for Desktop -> RSSI viewer application without having to press any button. The firmware automatically switch to bootloader mode without any intervention to press any button. 

We will need to see how you implemented the DFU trigger library and what error you have. You can take a look at the \examples\connectivity\ble_connectivity\pca10059 to see how it's implemented. 

Or you can simply try a simple test to set BSP_SELF_PINRESET_PIN to 0 in your application code to see if the dongle switch to DFU mode or not (The LED breaths red). This code in nrf_dfu_trigger_usb.c put the chip to DFU mode: 

[Hung Bui]

Hi again, 
I got noticed about the constrain Robin mentioned: 

Robin D. said:

without making any modification to the firmware we are flashing on the dongle (we use the firmware provided with the Thread Test Harness so we can't modify it).

Could you explain a little bit more on this ? Is the firmware a precompiled hex file ? Any chance to recompile this ? 

[Tom Douady]

Hi,

Thank you for your response.

Unfortunately, I am unable to recompile the application, as it is a precompiled app (.zip) that was provided to me. This means I have no visibility into the app’s internals, except for what I can access through the serial connection and any printed output.

[Hung Bui]

Hi Tom, 

This will make it much more difficult to do anything here as your application most likely doesn't have any feature to toggle the correct GPIO to reset. 

Can you give us some more information about your set up ? How many dongle are you running ? 

The most obvious option is to connect Jlink to the dongle and reflash the bootloader to a new one. We can add a delay for DFU there and then you just need to do a power reset for the dongle to enter DFU mode. The Jlink is only needed once per dongle. 

Do you have the option to automatically turn off and on the USB dongle power ? 

[Tom Douady]

Hey,

I'm using 40 dongles, and I don't have the option to turn the USB dongle power off and on.

I feel like using my own bootloader would take too much time, so we thought of another approach: using more dongles, each prepared with the app versions I want. I will plug them depending on the configuration needed for my tests.


Thanks for your answers. 

[Hung Bui]

Hi Tom, 

I agree. Simply use different dongles for different application would be the better solution. It's much more simple that trying to get a different bootloader and/or modify the test application.