Notecard Outboard DFU support for large (>1.5MB) binaries

Our project uses an ESP32-S3 with 16MB flash. At present, the firmware fits within the 1.5MB outboard DFU limit, so this is not an immediate concern.

Thinking ahead, the host firmware may expand beyond that limit - the Wi-Fi and Bluetooth stacks on ESP32 add a lot of overhead to the binary, and it’s pretty close to the limit when those features are compiled in.

Has anyone managed or have any thoughts on how to overcome the Notecard’s host firmware size limit?

Thinking aloud, perhaps splitting the binary into 1MB chunks and putting these in a series of binpack files, each with the correct memory offset?

This might be workable, so long as the ESP32 doesn’t attempt to boot/apply the firmware until all binpack files have been downloaded, which I believe is handled by the ESPs secondary bootloader.

Perhaps Blues already have this on their roadmap so that Notecard can scale with larger memory devices?

When the time comes, I’ll experiment a little. Who knows, it might just work as is!

Hi @devElert,

Thanks for reaching out.

I’ve been doing a bunch of work on the ODFU code for ESP32-based hosts lately, specifically the S3. I’m going to run some experiments to better understand the size limitations and get back to you.

Best,

Hayden Roche
Blues staff firmware engineer

After some research and discussion with the team, I’ve found 1.5 MB is the limit. The Notecard’s DFU design downloads the entire image, verifies it, and then begins programming. This requires buffering the image somewhere, and 1.5 MB is that buffer size. For certain Notecard SKUs, you may find that you can push beyond 1.5 MB, but this is out of spec, and proper behavior is not guaranteed.

I can imagine a different design where we stay connected to Notehub and buffer image chunks instead. While technically feasible, this approach is incompatible with the Notecard’s current design.