I purchased a ADAFRUIT FEATHER NRF52840 EXPRESS to work with my NoteCarrier F and Notecard Cellular. I am following the tutorial here on my Windows computer in Arduino to perfom OTA updates. After uploading the bootloader (UF2 Bootloader 0.7.0-15-g62b53ae-dirty shown in INFO_UF2.TXT) running the arduino code and get the binpack file everything seems to function.
As soon as I go to upload the binpack file to notehub and update a device I get an error of cannot update host: unrecognized firmware type {odfu-fail}
The microcontroller seems to lose its serial connection, and the red led blinks super quick until I hit the reset button on the microcontroller. I am following the tutoral to uplaod the fast blink sketch.
I am wondering if I can get some guidance in troubleshooting this. Where is this error coming from and what should I look into further?
Thanks
Hey @taudylan, welcome to the Blues community!
I have an Adafruit Feather nRF52840 here as well, so I’ll try to reproduce this and get back to you shortly. In the meantime, can you please confirm that you’ve set the correct DFU type on your Notecard by sending the following request:
{"req":"card.dfu","name":"nrf52"}
This setting is persistent, so you can confirm it’s correctly applied by connecting directly to your Notecard and issuing:
{"req":"card.dfu"}
If the DFU type is correctly set and you’re still seeing the {odfu-fail}
error, can you also confirm that the binpack file was created using the step outlined here?
notecard -output arduino-fast.binpack -binpack nrf52 fast.ino.zip
Once we have these points confirmed, I’ll have what I need to try reproducing this on my side.
Thanks
Youssif
1 Like
Hi,
When running the request, I get:
> {"req":"card.dfu"}
{
"mode": "aux",
"name": "nrf52"
}
I am using the following as stated to create the binpack
notecard -output arduino-fast.binpack -binpack nrf52 fast.ino.zip
Hey @taudylan, thanks for providing these details. I’ve been able to reproduce the behaviour you’re seeing, and I can confirm that this is expected: we have officially removed support for Arduino-based nRF52 ODFU in the Notecard. The currently supported ODFU types are STM32, ESP32, and MCUBoot as can be seen from the links below:-
For context, Nordic has officially migrated to using Zephyr going forward (full statement available here), and because of this, we recommend using Zephyr on your Feather nRF52840 instead of Arduino. The good news is that ODFU is supported via MCUBoot on Zephyr, and we have an example detailing how to achieve this on the feather nRF52840 here.
Below are a few additional reference links you may find useful:-
We will update our documentation to remove the Arduino examples to avoid confusion going forward. In the meantime, please let us know if you need any assistance getting started with note-zephyr on your nRF52840. We’re happy to help with the transition if you decide to proceed with this approach.
Thanks
Youssif
Hi Youssif,
I had a question about Zephyr and the flashing the nrf. I have been following the example you linked above. When I build the project there is no /build/zephyr/app_update.bin
I cloned the repository, so slow and fast blink code should be correct
Hi @Colton_b, welcome to the Blues community!
I believe this might happen if you are using pure Zephyr rather than the NRF Connect SDK (NCS). The guide you are following assumes you are using NCS, which automatically signs your firmware and generates app_update.bin as part of the normal west build flow when MCUboot is enabled.
If you are using pure Zephyr, the build system does not generate app_update.bin automatically during west build
. Instead, you have two options (this assumes that you followed the Custom Signing Key Step):
Option 1: Add the following to your prj.conf to enable automatic signing during build:
CONFIG_MCUBOOT_SIGNATURE_KEY_FILE="child_image/priv.pem"
Option 2: Use west sign after building to generate a signed DFU image:
west sign -t imgtool -- --key child_image/priv.pem
This will produce a zephyr.signed.bin file inside build/zephyr, which is functionally equivalent to app_update.bin for MCUboot DFU workflows. You can rename it to app_update.bin if needed for consistency.
I haven’t personally tested either of these approaches on pure Zephyr with this exact workflow yet, but they should work as is. If you try either option and it doesn’t work, please let me know and share a few details about your setup so I can try and replicate here. Alternatively, using NCS instead of pure Zephyr might be the safest bet, as it fully aligns with the guide.
Thanks
Youssif