# Outboard DFU failure with larger binaries **URL:** \ **Category:** Uncategorized\ **Created:** [February 12, 2024, 10:43am UTC](https://discuss.blues.com/t/outboard-dfu-failure-with-larger-binaries/1947 "2024-02-12T10:43:05Z")\ **Posts on this page:** 9\ **Page:** 1
**Author:** ![calcut](https://avatars.discourse-cdn.com/v4/letter/c/ecae2f/32.png) [@calcut](https://discuss.blues.com/u/calcut)\ **Post date:** [February 12, 2024, 10:43am UTC](https://discuss.blues.com/t/outboard-dfu-failure-with-larger-binaries/1947/1 "2024-02-12T10:43:05Z")
I’m hoping to get some input from Blues on an ongoing issue with outboard DFU. My previous topic hasn’t had any response, > [@Outboard DFU issue - error: esp: erasing flash failed](https://discuss.blues.com/t/outboard-dfu-issue-error-esp-erasing-flash-failed/1548): > > Hi I’ve been testing outboard DFU, and have had success with my hardware setup. However my firmware image now includes more libraries and is larger, and I’m seeing a failure. (The binpack file is 622KB rather than 379KB, so I don’t think I’m hitting the 1.5MB limit) Using Notecard FW 4.4.1.4015700 and CLI version 1.2.1 I’ve pasted the notecard trace output below at the end The offending line seems to be S52:54.66 loader: erasing flash for firmware.bin from 0x00010000 len 0x000e3690 As a … but having encountered it with different hardware combinations I’m convinced it is a real issue. I’ll try to break it down to a minimal reproducible example. Hardware: Host- ESP32-S3, Unexpected Maker FeatherS3 board Notecard ESP1.4 (aka Wifi Version 2), latest firmware 6.1.1.16332 Notecarrier-F (wired as per [ESP32-S2 Outboard DFU](https://discuss.blues.com/t/esp32-s2-outboard-dfu/1125)) Host Firmware: This is a super simple arduino firmware that just includes variable length audio data so I can control the size. [2024-02-12-102331\_audio\_490kB.binpack.txt](https://discuss.blues.com/uploads/short-url/rhcS8YjIeW4pwMrRmtzHRjcBg4Y.txt) (478.6 KB) [2024-02-12-101251\_audio\_578kB.binpack.txt](https://discuss.blues.com/uploads/short-url/wZ6cRqFjhwAM3kucAR8LSUNBfJ4.txt) (565.3 KB) I’m attaching 2 versions (remove the .txt extension to use), the smaller one works, the larger one fails with: ```auto S47:20.51 loader: loaded partitions.bin 0x00008116 off 278 len 00000278 (0/7914/557524 remaining) S47:20.55 loader: flash verified for partitions.bin S47:20.55 loader: end-to-end bin verified for partitions.bin S47:20.55 loader: programming completed for partitions.bin S47:20.55 loader: resetting source offset to 0x00003459 to align image to page boundary S47:20.55 loader: reading source offset 0x00003459 len 0x00002000 leaving 0x000880be remaining S47:20.56 loader: processing firmware.bin off 0 (565438/8192/557246 remaining) S47:20.56 loader: erasing flash for firmware.bin from 0x00010000 len 0x000ac650 S47:23.92 loader: 2971ms timeout waiting for reply S47:23.92 ***loader program_begin err esp: erasing flash failed (reason #2)*** (err 0) S47:23.93 loader: programming error: esp: erasing flash failed (reason #2) S47:24.63 AUX deactivated S47:26.14 _health.qo: outboard DFU of esp32 firmware: esp: erasing flash failed (reason #2) S47:26.25 dfu: disabled DFU mode S47:26.25 sync: wakeup: dfu disabled S47:26.25 dfu: cannot update host: esp: erasing flash failed (reason #2) S47:26.25 dfu: retry #10 ``` My best guess at the root cause is the `2971ms timeout waiting for reply` might be too short. Although I’m noticing messages like `U42:25.28 *** WARNING: LARGE ALLOCATION size:72734 remaining:593560` Which might be relevant Also attaching logs [success\_audio\_490kB.log](https://discuss.blues.com/uploads/short-url/qJFxEZ6iGLjsiWAwE61vuGKtveJ.log) (75.6 KB) [fail\_audio\_578kB.log](https://discuss.blues.com/uploads/short-url/hoBCTlH6KrpS4uE030MFeB07eN3.log) (68.3 KB) I’ve seen some inconsistency when reproducing this error that I can’t explain. i.e. it does occasionally work with larger firmware. (As per my last comment on my original topic) ---
**Author:** ![calcut](https://avatars.discourse-cdn.com/v4/letter/c/ecae2f/32.png) [@calcut](https://discuss.blues.com/u/calcut)\ **Post date:** [February 12, 2024, 12:02pm UTC](https://discuss.blues.com/t/outboard-dfu-failure-with-larger-binaries/1947/2 "2024-02-12T12:02:54Z")
Out of curiosity, I tried this with a Blues Swan host too. It works OK with a ~920kB firmware, but I did see it fail at ~1344kB This looks like a completely different error, but I did expect this to work given the DFU limit of 1.5MB and the flash size of 2MB ```auto S04:19.73 sync: advancing last sync time from 11:50:10Z to 11:50:21Z S04:20.52 dfu user: begin 2024-02-12-114905_audio_1344kB_STM32$20240212114959.binpack (1344407 bytes) S06:10.38 _health.qo: DFU of host firmware aborted: error appending to local file: error writing file S06:10.38 _health.qo: can't add note: can't exceed 80% of filesystem (currently 100%) {file-storage-full} S06:10.70 sync: wakeup: dfu SetStateToError S06:10.70 env: environment modified S06:10.73 env: updated _state_vars_dfu S06:10.73 env: dfu updated ``` ---
**Author:** ![calcut](https://avatars.discourse-cdn.com/v4/letter/c/ecae2f/32.png) [@calcut](https://discuss.blues.com/u/calcut)\ **Post date:** [February 12, 2024, 1:22pm UTC](https://discuss.blues.com/t/outboard-dfu-failure-with-larger-binaries/1947/3 "2024-02-12T13:22:48Z")
I think I have a reliable workaround. Only a little bit ugly. Should have thought of this earlier! I can split the firmware.bin into parts and add them individually to binpack so they get flashed sequentially. e.g. using the “split” command on macOS/linux to keep sizes below 300kB ```auto split -b 300K .pio/build/um_feathers3/firmware.bin ./split_firmware_ ~/git/Notecard-DFU/note-cli_1.2.1_macOS_arm64/notecard -binpack esp32 \ 0x0:.pio/build/um_feathers3/bootloader.bin \ 0x8000:.pio/build/um_feathers3/partitions.bin \ 0x10000:split_firmware_aa \ 0x5B000:split_firmware_ab \ 0xA6000:split_firmware_ac ``` ---
**Author:** ![RobLauer](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.blues.com/roblauer/32/1567_2.png) [@RobLauer](https://discuss.blues.com/u/RobLauer)\ **Post date:** [February 12, 2024, 3:33pm UTC](https://discuss.blues.com/t/outboard-dfu-failure-with-larger-binaries/1947/4 "2024-02-12T15:33:57Z")
Hi @calcut, I’m looking into this now and will get back to you when we have some updates. I just wanted to confirm you’re on the latest LTS release (6.1.1) and using only the Notecard WiFi v2? Thanks, Rob ---
**Author:** ![RobLauer](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.blues.com/roblauer/32/1567_2.png) [@RobLauer](https://discuss.blues.com/u/RobLauer)\ **Post date:** [February 12, 2024, 4:33pm UTC](https://discuss.blues.com/t/outboard-dfu-failure-with-larger-binaries/1947/5 "2024-02-12T16:33:41Z")
Also @calcut can you please post a picture of your wiring when using the ESP32-S3? ---
**Author:** ![calcut](https://avatars.discourse-cdn.com/v4/letter/c/ecae2f/32.png) [@calcut](https://discuss.blues.com/u/calcut)\ **Post date:** [February 12, 2024, 7:18pm UTC](https://discuss.blues.com/t/outboard-dfu-failure-with-larger-binaries/1947/6 "2024-02-12T19:18:29Z")
Yes. on the latest LTS 6.1.1.16332, but also observed with older FW. I’ve seen this on Wifi v2 and v1 and 99% sure with WBEX cellular ones too. I’ve seen it with ESP32, ESP32-S2 and ESP32-S3 Notecarrier B and Notecarrier F, and a custom board. Photos below, which is the same setup as discussed in [ESP32-S2 Outboard DFU](https://discuss.blues.com/t/esp32-s2-outboard-dfu/1125) ![IMG_1729](https://us1.discourse-cdn.com/flex020/uploads/blues/original/2X/c/cc8fa44b5a9b7fca846a6a9433986a0333b1a416.jpeg) ![IMG_1728](https://us1.discourse-cdn.com/flex020/uploads/blues/original/2X/3/38d21e66481e4c3f20515dcecb923d4b48ef68b6.jpeg) ---
**Author:** ![calcut](https://avatars.discourse-cdn.com/v4/letter/c/ecae2f/32.png) [@calcut](https://discuss.blues.com/u/calcut)\ **Post date:** [February 21, 2024, 4:28pm UTC](https://discuss.blues.com/t/outboard-dfu-failure-with-larger-binaries/1947/7 "2024-02-21T16:28:05Z")
Any success recreating the issue? ---
**Author:** ![devElert](https://avatars.discourse-cdn.com/v4/letter/d/8e8cbc/32.png) [@devElert](https://discuss.blues.com/u/devElert)\ **Post date:** [October 1, 2024, 4:44am UTC](https://discuss.blues.com/t/outboard-dfu-failure-with-larger-binaries/1947/8 "2024-10-01T04:44:13Z")
@calcut Thank you for posting the workaround. We have an ESP32-S3 custom board, and we are seeing the same behavior when the binary is not split up. With the file split workaround, ODFU works as expected. It does seem like the Notecard firmware would need to increase the delay when erasing the flash in order to account for the erase time for each page and number of pages. ---
**Author:** ![hroche](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.blues.com/hroche/32/1442_2.png) [@hroche](https://discuss.blues.com/u/hroche)\ **Post date:** [January 16, 2025, 1:02am UTC](https://discuss.blues.com/t/outboard-dfu-failure-with-larger-binaries/1947/9 "2025-01-16T01:02:12Z")
Hi @calcut, I’m sorry we took so long to get around to fixing this problem. I believe I’ve found the source of the issue. Take a look at the `timeout_per_mb` function from [esp-serial-flasher](https://github.com/espressif/esp-serial-flasher/tree/master): ```auto static uint32_t timeout_per_mb(uint32_t size_bytes, uint32_t time_per_mb) { uint32_t timeout = time_per_mb * (size_bytes / 1e6); return MAX(timeout, DEFAULT_FLASH_TIMEOUT); } ``` _EDIT: The root problem was that in our code we were using 1000000 (integer) rather than 1e6 (float)._ With your .binpack, flashing firmware.bin was eventually hitting this function with `size_bytes` of 706560. 706560 / 1000000 == 0, so DEFAULT\_FLASH\_TIMEOUT gets used, and the timeout isn’t scaled based on the size to erase. I fixed the math for this in the Notecard firmware, and I see a 7065 ms timeout being used instead of 3000 ms, and the ODFU succeeds. We will make sure this fix gets into our next firmware release. Thanks, Hayden