Bricked nrf52840 Dongle

[bricked]

I thought I had been extremely careful to _not_ brick the device, but apparently I did.

I created a firmware-dfu.zip file, even with appropriate keys, etc. as below.

  if /nix/store/if9z6wmzmb07j63c02mvfkhn1mw1w5p4-systemd-257.5/bin/journalctl --dmesg -b | grep -q 'Open DFU Bootloader'; then
    echo "dmesg detected a device with an Open DFU Bootloader" &&
    if /nix/store/zd7fljlfxbf071lpbr0kkfxhfw35ljzi-usbutils-018/bin/lsusb | /nix/store/gqmr3gixlddz3667ba1iyqck3c0dkpvd-gnugrep-3.11/bin/grep -q '1915:521f Nordic Semiconductor ASA Open DFU Bootloader'; then
      echo "Device is currently connected via USB" &&
      device_node=$(/nix/store/7y59hzi3svdj1xjddjn2k7km96pifcyl-findutils-4.10.0/bin/find /dev/serial/by-id/usb-Nordic_Semiconductor_Open_DFU_Bootloader_C1E8D2B54E6C-*) &&
      echo "We found a DFU Bootloader for device $device_node"

      n=/nix/store/byh3jmf68mav7nxsybcaidg9rici2p4m-nrfutil-1.0/bin/nrfutil
      for p in $("$n" search| grep 'Not installed'| awk '{print $1}'); do
        "$n" install "$p"
      done
      set -x
      
      keydir=/configuration/secrets/Thread/nrf52840
      key=$keydir/private.pem
      
      if [ ! -f "$key" ]; then 
        "$n" nrf5sdk-tools keys generate "$key"
        # /nix/store/rjzx8v679rwd6dsb6s08iy3j2rrax72s-openssl-3.4.1-bin/bin/openssl ecparam -name prime256v1 -genkey -noout -out "$key"
      fi &&

      app=/nix/store/10lclbfxncczar6i0789n473am6rlrcy-ot-nrf528xx-unstable-2025-05-23/bin/ot-rcp.hex &&

      printf 'Using hex file: %s\n' "$app" &&
      
      output=$(pwd)/thread_rcp_dfu.zip &&
      printf 'Generating DFU package: %s\n' "$output" &&

      "$n" pkg generate \
      --hw-version 52 \
      --sd-req 0x00 \
      --application "$app" \
      --key-file "$key" \
      --application-version 1 \
      "$output" &&
      dfu_description=$("$n" pkg display "$output") &&
      if printf '%s' "$dfu_description" | /nix/store/gqmr3gixlddz3667ba1iyqck3c0dkpvd-gnugrep-3.11/bin/grep 'sd_req: 0x00'; then
        echo "Good, this is not a SoftDevice"
      fi &&
      echo "" &&
      echo "$dfu_description"
      
    else
      echo "No DFU Bootloader found in dmesg output; nothing to do." 
    fi
  fi

Then, I wanted to flash via:

#!/bin/sh
if [ -z "$1" ]; then
  echo "Usage: $0 firmware.dfu.zip"
  exit 1
fi

FW=$1
set -x

printf "Flashing firmware '%s' to nRF52840 USB Dongle in DFU mode...\n" "$FW"
n=/nix/store/byh3jmf68mav7nxsybcaidg9rici2p4m-nrfutil-1.0/bin/nrfutil
# Flash via USB DFU
"$n"  dfu usb-serial -pkg "$FW" -p /dev/ttyACM0

if [ $? -eq 0 ]; then
  echo "Flash successful."
else
  echo "Flashing failed."
  exit 3
fi

I saw output saying "device programmed" with  a progress bar before it that went to 100%, suggesting that at least *something* was flashed. Before (from the distributor) the device was in DFU mode, showing a dimming orange LED and it would show up in both dmesg and lsusb (as checked by the code), but afterwards it just seems dead/bricked. 

So, how do I recover this and how do I accomplish what really should have been an easy task of flashing an Openthread Border Router RCP (openthread.io/.../border-router) onto the device such that I can achieve my end goal of just being able to use Matter devices? 

The code I used to build the ot-tcp.hex file (the artefact used in the code above creating the DFU zip file) is visible below:

# code used to build ot-rcp.hex

bash build nrf52840 USB_trans

arm-none-eabi-objcopy -O ihex $OT_CMAKE_BUILD_DIR/bin/ot-rcp $NIX_BUILD_TOP/bin/ot-rcp.hex

I feel like I have done nothing wrong and followed all instructions, but despite best intentions, the device still is bricked

Overall, I consider it a _horrible_ developer experience for trying to do something which should have been simple (adding an OBTR to the network).

I am aware other people asked somewhat similar questions, but my setup is probably somewhat unique. Version information of nrfutil:

$ /nix/store/byh3jmf68mav7nxsybcaidg9rici2p4m-nrfutil-1.0/bin/nrfutil --version
nrfutil 8.0.0 (54d8087 2025-01-07)
commit-hash: 54d8087a38b73b6e56942fb1b024b62365f06731
commit-date: 2025-01-07
host: x86_64-unknown-linux-gnu
build-timestamp: 2025-01-07T14:26:42.070728557Z
classification: nrf-external

So, the questions then are:

1. How do I recover to factory settings (assuming I have little to no tools right now, but I can buy tools)? I pressed the white button (there are no other buttons visible) in an attempt to reset to factory settings.
2. What do I need to flash Openthread RCP on it such that it *does* work?
3. Why is it even possible to have a successful flash that bricks the device in the first place? E.g. why is there no simulation of some kind to make sure the resulting flashed device does something useful?
4. If I need to buy something to make this work, what?

[bricked]

I procured a nrf52840-dk and a new nrf52840 as well, but even with those the questions largely remain open. Also, I absolutely do not want to brick anything else.

[Sigurd Hellesvik]

How do I recover to factory settings (assuming I have little to no tools right now, but I can buy tools)? I pressed the white button (there are no other buttons visible) in an attempt to reset to factory settings.

You got two options:

Reprogramming the Dongle using a debugger. This is the "nuclear option", which requires you to connect the Dongle to the DK.

However, I think you missed a button, so you should still be able to put the Dongle into DFU mode and then program it again.

In addition from the button you see, there is a sideways button:

Press this (from the arrow direction) when the Dongle is plugged in. The Dongle should now enter programming(DFU) mode, and the LED should tart blinking(fading) red.

Overall, I consider it a _horrible_ developer experience for trying to do something which should have been simple (adding an OBTR to the network).

If you want a more graphical method for programming the Dongle, try to download nRF Connect for Desktop, open the Programmer app, select the hex and then press "program" when the dongle is in programming mode.

What do I need to flash Openthread RCP on it such that it *does* work?

"Just program the hex file" is the short answer. While this is not helpful as such, at least you get confirmed that the hex should work as-is.

The long answer goes as this:

Looks like you follow the OpenThread guide. This is OpenThread, and not Nordic Semiconductor. 
We do have our own Thread Coprocessor code in our SDK. Yes, these two should be the same, but we can only promise things for our version, as this is the one we run testing on. 
See Thread: Co-processor. 

However, installing the SDK is a bit of work, but if you intend to develop with the nRF later, you might as well install it now. To get started, I recommend https://academy.nordicsemi.com/.

If not, here is a hex file that I just built (and did not test) that you can try:

0005.nrf52840_dongle_thread_coprocessor.hex

I can test it next week if needed, but I built it as the tests do, so it should work.

PS: Here is also blinky, so that you can verify that the programming works for anything:

7851.nrf52840dongle_blinky.hex

Why is it even possible to have a successful flash that bricks the device in the first place? E.g. why is there no simulation of some kind to make sure the resulting flashed device does something useful?

I assume that the other button answers this. 

If I need to buy something to make this work, what?

Generally no. At worst a DK, but looks like you already have that. Maybe a cable, but lets get to that if the above did not work.

Regards,
Sigurd Hellesvik

[Sigurd Hellesvik]

Uploading files again here since they prev seems wrong:

5008.nrf52840_dongle_thread_coprocessor.hex

2845.nrf52840dongle_blinky.hex

[bricked]

It started dimming again and listed under lsusb again. So, hardware saved and thank you for that.

The last thing I want is a graphical environment, unless they work better than a command line interface (and unfortunately, all of your tools are npm thrash (_Nobody_ in the NixOS community likes it when they need to patchelf all your tools to make them work)).

A decent developer experience would be literally nothing more than the below (so, not even having to care where the URL of your SDK is). I don't really get why for this particular flow (that is, just people wanting to _use_ your chips instead of developing for them) you don't optimize. Obviously, if I ever want to really develop for your chips and have some custom application, then I might want to actually have a git checkout of your repo in a place on my system I want to know about, but otherwise, just hide all those unnecessary details (that's called _abstraction_).

#!/bin/shell
wget https://yoursdk.com/default.nix
nix-shell
# screen shows which applications are available for direct flashing: 
# 1. RCP
# 2. blinking app
# usage flash <number> (e.g. flash 1 for RCP)
flash 1 # wait a few seconds and it works. 

Perhaps I am underestimating the amount of products with your chips in it, but writing such a shell script would take anyone familiar with all your tooling perhaps 30 minutes.