Host firmware reports its version on boot with:
{“req”:“dfu.status”,“name”:“user”,“on”:true,“version”:“”}
Notecard mode is continuous.
The host communicates with the Notecard over I2C during normal runtime.
The host application uses the Notecard for telemetry, state sync, and a Blynk-style bridge/downlink system.
During normal operation the host periodically sends telemetry/status and also polls/receives downlink control data.
When our firmware detects an incoming host DFU state, we pause normal Notecard runtime traffic such as telemetry, state sync, Blynk bridge/downlink polling, and manual sync requests for a quiet period.
The Notecard owns the actual flashing transaction. The STM32 application is not manually reading firmware chunks and writing them to flash.
We found this older forum thread:
In that case the solution was to reduce the host-side dfu.get chunk length from 8192 to 4096.
However, that appears to be for a host-driven/in-application DFU flow where the ESP32 firmware manually calls dfu.get with an offset/length and writes chunks itself.
Our case seems different because we are using Notecard Outboard DFU for STM32 via card.dfu, so we do not have a host-side dfu.get chunk size in our STM32 firmware to reduce.
Questions:
For STM32 Outboard DFU using card.dfu with mode:"altdfu", is the internal host flashing chunk size fixed at 8192 bytes?
Is there any Notecard API setting to reduce that internal ODFU chunk size, for example to 4096 bytes?
Is this cannot allocate 8192 bytes error expected to come from the Notecard’s internal memory during the outboard flashing step?
Could normal Notecard traffic before the DFU attempt, such as telemetry/state sync/downlink polling, leave internal memory fragmented or unavailable for ODFU?
Is there a recommended workaround, such as a Notecard firmware version, a reset/cleanup command before retrying ODFU, temporarily disabling sync/downlink activity, or a different DFU configuration?
The update usually works after one or more power cycles/retries, so it feels like the Notecard may eventually free enough memory or reset some internal state. We would like to understand the correct long-term fix.
Great questions - I’ll see if I can answer them all for you here:
For STM32 Outboard DFU using card.dfu with mode:"altdfu", is the internal host flashing chunk size fixed at 8192 bytes?
Yes, that is fixed in Notecard firmware.
Is there any Notecard API setting to reduce that internal ODFU chunk size, for example to 4096 bytes?
Not currently, no.
Is this cannot allocate 8192 bytes error expected to come from the Notecard’s internal memory during the outboard flashing step?
Yes. Because it happens after fw download, your image in flash is fine (nothing is corrupted), it’s likely a transient RAM condition at flash time.
Could normal Notecard traffic before the DFU attempt, such as telemetry/state sync/downlink polling, leave internal memory fragmented or unavailable for ODFU?
It could be the culprit, especially with very long-running continuous mode sessions and non-templated Notefiles that aren’t synced regularly.
Is there a recommended workaround, such as a Notecard firmware version, a reset/cleanup command before retrying ODFU, temporarily disabling sync/downlink activity, or a different DFU configuration?
The number one thing I would look at is using templated Notefiles. This alone could solve all your problems as templates are dramatically more memory efficient. You can also try a hub.sync and waiting for it to complete before you initiate a DFU.
The 8192-byte allocation is internal to Notecard firmware during STM32 Outboard DFU.
There is currently no API setting to reduce that ODFU chunk size.
Since the firmware image has already downloaded successfully, the failure is likely transient Notecard RAM pressure at flash time.
Our normal non-templated .qo traffic could contribute to this.
We will look into using templated Notefiles.
Before changing the implementation, would you recommend separate templated Notefiles for each stable data shape, or one larger superset template in a single Notefile?
Also, some of our values can validly be 0. With templates, should we use full:true on note.add when we need those zero values preserved in Notehub?
For DFU, our host firmware has a “DFU quiet” mode where we temporarily stop normal runtime Notecard traffic, such as telemetry, state updates, downlink polling, and manual sync requests.
Would this sequence make sense?
Detect/predict a host DFU attempt.
Enter DFU quiet mode and stop normal runtime traffic.
Run hub.sync.
Wait for sync/queues to clear.
Let Outboard DFU proceed.
Resume normal traffic after DFU quiet exits or after reboot.
On the template layout question, definitely use separate templated Notefiles, not one superset.
On your 0 value question, yes use "full":true in your scenario.
Also your DFU sequence makes sense but you don’t have to “predict” a DFU attempt when you can use the dfu.status API to query the status. And note that the templating should even make the hub.sync unnecessary!