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

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

Hung Bui — Wed, 19 Nov 2025 12:20:38 GMT

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.

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

Tom Douady — Tue, 18 Nov 2025 11:31:48 GMT

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.

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

Hung Bui — Fri, 14 Nov 2025 10:25:09 GMT

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 ?

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

Tom Douady — Thu, 13 Nov 2025 11:25:51 GMT

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.

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

Hung Bui — Fri, 07 Nov 2025 14:01:05 GMT

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

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

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

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

Hung Bui — Fri, 07 Nov 2025 11:37:00 GMT

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:

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

PjGlasso — Mon, 03 Nov 2025 17:46:45 GMT

Hi there,

SO i'm not in way left field :grin:

you want to use the Dongle with custom Bootloader and Firmware App.

The Bootloader presently is immutable(can't be update, by code). You would need to erase the device completely. Program/SWD and Add your bootloader (MCUboot)maybe and recommended.

When it's in DFU mode. give it your app and cross your fingers is what I see? , Now perhaps there is a software method in your Bootloader to Reboot and PAUSE ?(allows app update ONLY) , X-seconds and continues to app installed...

Feels very Generic and Vanilla to me.

LMK ?

And others will comment...

HTH

GL :-) PJ ✌

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

Tom Douady — Mon, 03 Nov 2025 08:46:07 GMT

Hi PJ,

Thanks again for your detailed explanation — it really helped me understand the two approaches better.

With your advices I succeed to create my own bootloader. Thanks for that !

I’d like to clarify my specific situation:

I cannot modify the application itself, as it’s provided to me in a precompiled .zip format (standardized across projects).
My goal is to replace the factory bootloader on the nRF52840 USB Dongle with a custom one that:
- Stays in DFU mode for a short period after reset, waiting for a potential firmware update.
- Then jumps to the existing application if no update is received.

So I’m only looking to compile and flash the bootloader, without touching or rebuilding the application. This would allow me to update the app via DFU when needed, without requiring any changes to the app itself.

From my perspective, it seems that Path B (MCUboot) might be closer to what I’m trying to achieve — assuming I can configure it to enter DFU mode temporarily after reset, even without cooperation from the application.

Is there a way to overwrite the factory bootloader by a custom bootloader ?

Tom.

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

PjGlasso — Fri, 31 Oct 2025 15:29:04 GMT

Hi there,

So looks like you may be mixing the two methods... You need to decide which path gives you the best function for your situation.

You built Blinky with CONFIG_BOOTLOADER_MCUBOOT=y and a child mcuboot/prj.conf, then targeted nrf52840dongle/nrf52840. Now you see hex images and a memory layout that looks “off” and can’t auto-jump to bootloader.

That’s because there are two distinct approaches:

A) Keep the factory Nordic USB DFU bootloader (shipped on PCA10059)

You do not build/flash MCUboot.
You enter DFU (bootloader) either by the dongle’s button at reset or by software using GPREGRET.
You flash your application-only image (no MCUboot) using the Programmer tool or nrfutil dfu.

B) Replace the factory bootloader with MCUboot

You do build MCUboot as a child image and flash the merged.hex that contains MCUboot + your app.
To auto-enter recovery, you enable MCUboot’s serial/USB DFU or pin-detect in the child Kconfig and trigger it.

You have done a bit of B while expecting behavior from A. :grin:

Path A — Use the factory Nordic USB DFU bootloader (simplest, safest for the dongle)

Remove CONFIG_BOOTLOADER_MCUBOOT=y from the app. Don’t build MCUboot.
Build your app normally for nrf52840dongle/nrf52840.

To auto-enter bootloader from your app, write the GPREGRET and soft reset:

#include <zephyr/sys/reboot.h>
#include <hal/nrf_power.h>  // or <nrfx/hal/nrf_power.h> depending on includes

static void enter_factory_dfu_now(void)
{
    /* Nordic factory bootloader (nRF5 SDK DFU) looks for 0xB1 in GPREGRET */
    nrf_power_gpregret_set(NRF_POWER, 0, 0xB1);
    sys_reboot(SYS_REBOOT_WARM);
}

Call enter_factory_dfu_now() when you want the dongle to pop into DFU.
In Programmer you’ll then see the bootloader enumerate as a DFU device over USB.
Do not flash anything that overwrites the bootloader region, or you lose this convenience.

If it’s not entering DFU with 0xB1, try 0xB0. Different bootloader variants sometimes use 0xB0 vs 0xB1. 99% of the time on PCA10059 it’s 0xB1.

What about the two hex files?

zephyr.hex = just your application.
merged.hex (when you had MCUboot enabled) = bootloader + app; don’t use that in Path A or you risk overwriting the factory bootloader.

Path B — Switch to MCUboot (Zephyr-native boot + recovery)

If he really wants MCUboot (e.g., standardizing across boards), then commit and configure it right:

Keep CONFIG_BOOTLOADER_MCUBOOT=y in the app.
In child_image/mcuboot/prj.conf, enable a recovery method. Options:
- Pin-based serial recovery (handy on dongle’s single button, P1.06):

CONFIG_BOOT_SERIAL=y
CONFIG_BOOT_SERIAL_DETECT_PORT=y
CONFIG_BOOT_SERIAL_DETECT_PIN=1,6      # Port 1, pin 6 = P1.06 (SW1)
CONFIG_BOOT_SERIAL_DETECT_PIN_VAL=0    # Active low when button held
CONFIG_BOOT_SERIAL_DETECT_PIN_PULL_UP=y
CONFIG_SERIAL=y

USB DFU in MCUboot (if you want host-side dfu-util/USB):

CONFIG_BOOT_USB_DFU=y
CONFIG_USB_DEVICE_STACK=y
CONFIG_USB_DEVICE_PRODUCT="MCUboot DFU"

3. Build and flash the merged.hex (this replaces the factory bootloader with MCUboot).

4. To auto-enter MCUboot from the app, you have two easy options:

Hold the button at reset (pin detect above), or
Put the system into recovery via a software trigger supported by your chosen recovery path (for serial, many folks wire a “virtual detect” pin or just prompt the user).

Note: MCUboot doesn’t use the factory 0xB1 GPREGRET convention. That’s why mixing A & B is a dead end.

On the dongle, the DTS/partition keeps a bootloader region at the end. If you build with MCUboot, your app slot is different than a bare app. If you’re still seeing partitions “at the end of Application,” that’s just the board’s partition layout and does not imply an error — but it’s a red flag if you intended to keep the factory bootloader (Path A) while flashing a merged.hex (Path B).

It all comes down to Do you want to keep the factory USB DFU?
→ YES: Don’t enable MCUboot. Use GPREGRET=0xB1 + warm reset to auto-enter DFU. Flash app-only images (zephyr.hex) via Programmer/DFU.
→ NO: Enable MCUboot, pick serial or USB DFU in the child image, and flash merged.hex once to install MCUboot. Then use button-detect or MCUboot DFU to recover/upgrade.

HTH

GL :-) PJ :v:

for my solutions, for the nRF52840 USB Dongle, stick with Path A unless you have a compelling reason to standardize on MCUboot there. The factory DFU is rock solid, and the GPREGRET trick makes “enter bootloader” 100% software-driven—perfect for remote “press a button in the app to put the dongle in DFU mode.” 👍

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

Tom Douady — Fri, 31 Oct 2025 10:30:35 GMT

Hey,
Thanks for your reply.

Here’s the process I’m following using the nRF extension in VSCode:

Create a new application
Copy a sample
Search for: "blinky"
Click on: "Blinky Sample" (zephyr/samples/basic/blinky)
Add at the top of prj.conf:
CONFIG_BOOTLOADER_MCUBOOT=y
Create the child_image/mcuboot/prj.conf as you previously described
Add a build configuration: select the nrf52840dongle target (Shall I config something else here ?)
Generate and build

Now I have two .hex images generated:

blinky/build/merge.hex
blinky/build/blinky/zephyr/zephyr.hex

When I open the Programmer tool, the memory layout shows that these files are located at the end of the Application region.

Am I missing something in the process ?

Tom.

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

PjGlasso — Thu, 30 Oct 2025 17:57:55 GMT

Using the Nrf dongle with any of the example apps, build the bootloader example. The trigger Options are what you might be missing. I use the NRF_SDK with Visual Studio also .

Make changes to the PRJ.conf file and try that.

I would use option 3, it will just wait forever.

HTH

GL :-) PJ :v:

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

Tom Douady — Wed, 29 Oct 2025 16:09:56 GMT

Thanks for the detailed explanation. I’d like to implement option 1 (DFU window at boot), but I’m not sure which base project you're starting from.

I don’t have a specific application to modify—my goal is to build a bootloader-only image, since the application is already flashed and cannot be changed. It resides at address range 0x00001000 - 0x000557F7, so I assume the second image (to update the app) should be placed at 0x00000000 - 0x00001000.

Also, I’ve seen two ways to create bootloaders:

Using the nRF5 SDK from Nordic: nRF5 SDK (in maintenance mode). I saw a example called dfu/open-bootloader/pca10059_usb that seems to do the thing I want. But when I'm flashing the bootloader and reset my dongle it seems to jump on my application without waiting in DFU mode.
Generating projects from samples via the nRF Connect for VSCode extension (with the nRF Connect SDK)

Could you clarify what's the base project you tell me to modify ?

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

PjGlasso — Fri, 10 Oct 2025 01:31:52 GMT

Hi there,

AFAIK, there are 3 , YMMV 🤞🏼

Totally doable—even if you can’t touch the app. You just make MCUboot do the work.

Here are the bootloader-only ways to enter DFU (no app changes):

1) “Always give me a DFU window” (most common)

MCUboot waits at boot for serial/USB DFU for N milliseconds; if nothing connects, it boots the app.

In your application prj.conf:

CONFIG_BOOTLOADER_MCUBOOT=y

Create child_image/mcuboot/prj.conf (this configures the bootloader image that sysbuild makes):

# Turn on MCUboot serial recovery
CONFIG_BOOT_SERIAL=y

# Choose one transport:
CONFIG_BOOT_SERIAL_UART=y         # DFU over UART
# or
CONFIG_BOOT_SERIAL_CDC_ACM=y      # DFU over USB CDC (shows up as a COM port)

# Enter recovery automatically at boot and wait for host
CONFIG_BOOT_SERIAL_WAIT_FOR_DFU=y
CONFIG_BOOT_SERIAL_WAIT_FOR_DFU_TIMEOUT=2000   # ms; 0 = wait forever
# Optional: don’t require any detect pin
CONFIG_BOOT_SERIAL_DETECT_NONE=y

UX: Power/reset the board → bootloader opens a ~2s DFU window →

If you start an upload, it stays in DFU.
If not, it boots the third-party app.|

2) Hardware strap (no button on the device, but you can pull a pin)

If you can wire a pin at reset (e.g., test pad or baseboard):

In child_image/mcuboot/prj.conf:

…and in child_image/mcuboot/overlay.dts set which GPIO = “enter DFU when held” (active level per your wiring). That way you can clip a probe or jig the pin at power-on to force DFU. App still untouched.

3) “Forever DFU” mode for bring-up

Same as #1 but:

CONFIG_BOOT_SERIAL_WAIT_FOR_DFU_TIMEOUT=0

👈 😎

Bootloader always sits in DFU until you upload something. Useful during recovery; change back once you’re done.

if you can't put mcumgr in with app then the last option might work or a Strapping pin (something on the board that needs pulled high on boot or always could be useful to connect with.

HTH

GL :-) PJ :v:

Good topic

From the trigger lib doc.

This information applies to the nRF52840 SoC only.

When the trigger library is added to an application, it allows a connected USB host to remotely tell the app to reboot into the bootloader to allow it to be updated via DFU. When asked to enter bootloader mode, it pulls its own reset pin using the GPIO pin BSP_SELF_PINRESET_PIN (by default, only available on PCA10059). As a consequence, the library requires the following:

a GPIO pin connected to the RESET pin which is true for the PCA10059 dongle,
a bootloader that enters DFU mode on pin reset.

The experimental Open USB bootloader example is configured in this way, and newer versions of the nRF Connect PC app are equipped to communicate with the Trigger module.

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

PaKa — Mon, 29 Sep 2025 13:38:32 GMT

This is what the DFU trigger library is made to do so you should probably look into why it doesn't work. Did you integrate it into the application code you built as that is required for it to work. This is the solution used for all the Nordic FW images used by the tools and it works like a charm.

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

DanielNG — Mon, 29 Sep 2025 10:42:21 GMT

Hi,
It doesn't seem like there's any software implementation that would satisfy your constraints. I think your best solution is some kind of HW fix.

Best,
Daniel

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

Robin D. — Fri, 26 Sep 2025 12:49:24 GMT

Hello DanielNG ,

I'm working with Cedric on Thread activities.

Just to make sure we have the same understanding of the issue we are encountering, here is our main constraints : we want to be able to upgrade the dongle's firmware without any physical access to the dongle and 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).

For now, all the potential solutions I found (including the one you proposed) require either to plug an additionnal debug probe on the dongle or to edit the firmware to flash on the dongle (let me know if I'm wrong and your solution does not require any of these two actions).

Kind regards,

Robin

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

Cedric ABGRALL — Tue, 23 Sep 2025 15:26:39 GMT

Dear Daniel
Please let me double check with my colleagues if your proposal solves their issue. I will come back to you then.

Warm regards

Cédric

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

DanielNG — Tue, 23 Sep 2025 12:27:13 GMT

You can switch to MCUboot as the bootloader. Please refer to this documentation

Instead of using a button MCUboot can be configured to wait for a limited time at startup to check if DFU is invoked through an MCUmgr command.

Please refer to MCUboot serial recovery