Repository navigation
Show DFU mode on the device screen instead of leaving the last frame up #11683
Description
Problem
When a device is put into DFU mode for a firmware update, the screen keeps showing whatever frame was drawn last. To anyone looking at the device it just looks frozen: the UI is stuck, nothing responds, and there is no indication that the device is waiting to be flashed.
This is confusing on its own, and it is worse when an update fails partway. The device is left sitting in its bootloader with a stale screen, and the only clue is the blinking LED, which most people won't read as "this device is in DFU mode".
Request
Draw a DFU screen before jumping to the bootloader, so the device says what state it is in. Something minimal is enough:
- "DFU Mode" or "Firmware Update"
- a short line telling the user not to power the device off
- ideally the device name or address, so it can be matched to the device shown in the updater app
The bootloader itself has no display driver, so this needs to be drawn by the firmware immediately before the reboot into DFU. Clearing the screen instead of leaving the stale frame would already be an improvement over what happens today.
Why it matters
Clients drive DFU over BLE, and the update can take a while or fail and leave the device waiting. Right now the device gives the user nothing to go on, so a normal update looks like a crash, and a failed one looks like a bricked device.
Activity
Xaositek commentedon Sep 1, 2026
This was done a long time ago - #8970
Leverage the "case meshtastic_AdminMessage_enter_dfu_mode_request_tag: {"
Confirmed it works through flasher.meshtastic.org, are we doing something different with the apps?
garthvh commentedon Sep 1, 2026
@rcarteraz and I were testing on a NRF device and just got a frozen screen
jp-bennett commentedon Sep 20, 2026
@garthvh which device, and how did you put it in DFU?
garthvh commentedon Sep 20, 2026
L1 from the app button
Xaositek commentedon Sep 21, 2026
Tested with Wio Tracker L1 Pro against Web Flasher via USB connection. Video attached showing DFU screen being properly called.
trim.E3F36FF8-6F85-42AB-95FF-B33BF1B8E10B.MOV
rcarteraz commentedon Sep 21, 2026
IMG_7373.MOV
Honestly this issue can likely be closed because it's not a firmware issue, it's a boot loader issue. There's a draft PR, but we have to decide if we want to eat the flash space for it. meshtastic/Adafruit_nRF52_Bootloader_OTAFIX#40
rcarteraz commentedon Sep 21, 2026
This could actually be the alternative option to take up the flash space. Display a similar frame, stating it's in DFU mode so that it's frozen on that instead of the last frame.
Xaositek commentedon Sep 21, 2026
Just looking at the code, are the apps NOT sending Admin messages to enter DFU mode? We only capture the initial intent in that single manner.
This is the code here:
case meshtastic_AdminMessage_enter_dfu_mode_request_tag: {LOG_INFO("Client requesting to enter DFU mode");#if HAS_SCREENIF_SCREEN(screen->showSimpleBanner("Device is rebooting\ninto DFU mode.", 0));#endifrcarteraz commentedon Sep 21, 2026
Given @caveman99's recent flash savings, we could actually be able to afford it: #11873never mind, I am dumb. App Image and OTA are on different partitions. duh.