Failed FW upload, device stuck in DFU

[SimonSaysBoo]

I've just compiled and attempted an upload of the FW per the below:

---

simongeorge@MacBook-Pro-3 firmware % nrfutil device program --firmware objects/dfu-app.zip --traits nordicDfu WARNING: JLinkARM DLL not found. SEGGER J-Link devices will not be recognized correctly, and J-Link operations will not be available. Install J-Link from https://www.segger.com/downloads/jlink/.

[00:00:00] ------ 0% [2/2 DABF4026FDE6] Failed, [sdfu] Error: One or more program tasks failed

Device was in DFU mode, connected (Mac) via USB. Device now has two red lights flashing (same as DFU green lights). Lights return to green when reconnected to Mac via USB, but I can't get out of the DFU and reattempts to upload FW result in same.

[SimonSaysBoo]

I have reflashed FW using the GUI app - just interested to report the issue and perhaps understand where i went wrong.

Thanks

[GameTec-live]

maybe something wrong with nrfutil for mac...

[m-kozlowski]

Had this error yesterday trying to flash self compiled firmware to chameleon lite. Tried native windows, WSL and linux - same result. Flashing dpu-app.zip from github actions worked (and brought device back to life).

Changing compiler from gcc-arm-none-eabi-10.3-2021.10 to arm-gnu-toolchain-12.2.rel1 also produced flashable bundle. I haven't investigated any further

[domints]

So you changed the toolchain and it helped? I also have this problem, on Mac, while on Windows everything works correctly for me. I will try investigating this issue in the future, as I'd rather use mac as my main development machine.

[whywilson]

I compiled success on MacOS but failed to flash it.

Bootloader DFU Settings:
* File:                     settings.hex
* Family:                   NRF52840
* Start Address:            0x000FF000
* CRC:                      0xD2F71E54
* Settings Version:         0x00000002 (2)
* App Version:              0x00000001 (1)
* Bootloader Version:       0x00000001 (1)
* Bank Layout:              0x00000000
* Current Bank:             0x00000000
* Application Size:         0x00020620 (132640 bytes)
* Application CRC:          0x288BE629
* Bank0 Bank Code:          0x00000001
* Softdevice Size:          0x00000000 (0 bytes)
* Boot Validation CRC:      0x78B0644C
* SD Boot Validation Type:  0x00000000 (0)
* App Boot Validation Type: 0x00000001 (1)

+ mergehex --merge bootloader.hex settings.hex application.hex ../nrf52_sdk/components/softdevice/s140/hex/s140_nrf52_7.2.0_softdevice.hex --output fullimage.hex
Parsing input files.
Merging file "bootloader.hex" into output.
Merging file "settings.hex" into output.
Merging file "application.hex" into output.
Merging file "s140_nrf52_7.2.0_softdevice.hex" into output.
Storing merged file.
➜  firmware git:(fix) ✗ sh flash-dfu-app.sh
[00:00:00] ------   0% [2/2 F3********64] Failed, [sdfu]
Error: One or more program tasks failed

[domints]

@whywilson exactly. That's the thing - and it's not a problem with flashing process, but with toolchain - package built on Windows or downloaded from this github flashes fine. But as m-kozlowski suggests it might be matter of toolchain, we need to test couple of them to see which works correctly.

[domints]

Yes, using this, and specifically this version: arm-gnu-toolchain-12.2.rel1 (not the latest 12.3) of toolchain worked for me and created working dfu-app.zip. Neither 12.3 nor gcc-arm-none-eabi-10.3-2021.10 created flashable dfu-app.zip. After changing the toolchain make sure to go to application and run make clean, possibly also do the same in bootloader folder.

[whywilson]

I've followed your step: using arm-gnu-toolchain-12.2.rel1, do make clean in application and bootloader folder, the firmware still cannot be flashed. I'm using MBP14. Tried remove all gcc-arm-none-eabi-10.3-2021.10 and toolchain and restarted. Any suggestions? Thank you in advance.

[m-kozlowski]

You guys are having problem flashing Lite or Ultra device? If it's Lite, then build.sh ignores device type set in Makefile.defs, as a result zip bundle is always built with --hw-version 0, so Lite's bootloader rejects flash attempt.

[domints]

You guys are having problem flashing Lite or Ultra device? If it's Lite, then build.sh ignores device type set in Makefile.defs, as a result zip bundle is always built with --hw-version 0, so Lite's bootloader rejects flash attempt.

Ultra :) Also, I don't think device difference would manifest during flashing phase - it's all nRF52840 after all, so FW should run at both, and fail at runtime when it can't access some hardware.

[m-kozlowski]

Target MCU doesn't matter. "hw version" is built in bootloader https://github.com/RfidResearchGroup/ChameleonUltra/blob/32e0cdf16bc62786f4ef177515721f79b8ca98d7/firmware/common/hw_connect.c#L6

included in firmware bundle https://github.com/RfidResearchGroup/ChameleonUltra/blob/32e0cdf16bc62786f4ef177515721f79b8ca98d7/firmware/build.sh#L38

and it's verified by bootloader before flashing https://github.com/RfidResearchGroup/ChameleonUltra/blob/32e0cdf16bc62786f4ef177515721f79b8ca98d7/firmware/nrf52_sdk/components/libraries/bootloader/dfu/nrf_dfu_ver_validation.c#L284

But that's not the cause of your problem, since you're experiencing it with Ultra variant. Try to fiddle* with --log-level and --log-output of nrfutil, maybe you'll find out something interesting.

*) I was unable to force it to log in human readable format neither to file nor stdout, but after switching to json it became quite chatty;)

[elkentaro]

The nrfutil logs on a Mac are in ~/.nrfutil/logs. Also disconnecting the battery then flash it over usb-c will restore the device. (reattach battery after flashing, but it probably voids warranty, so yea ... ). My ultra was stuck in DFU mode but this method recovered it.