CMD_CLEAR_FLASH clears sectors beyond the user-data partition, bricks the interface firmware

[nedseb]

Summary

Running the CMD_CLEAR_FLASH command from the host I2C bridge protocol
(used by both steamicc/arduino-steami-lib and
steamicc/micropython-steami-lib via their respective daplink_flash
drivers) puts the STeaMi's on-board STM32F103 into DAPLink maintenance
mode. After the command lands, the board no longer enumerates as a
normal CMSIS-DAP + mass-storage device — the interface firmware has
to be re-flashed by drag-dropping the firmware binary onto the
maintenance mass-storage volume.

Reproduction

From a clean Arduino sketch on a STeaMi with DaplinkBridge +
DaplinkFlash from steamicc/arduino-steami-lib:

DaplinkBridge bridge(internalI2C);
DaplinkFlash flash(bridge);
flash.begin();
flash.clearFlash();   // ← chip reboots into maintenance mode here

Equivalent reproduction from the integration suite in
steamicc/arduino-steami-lib PR ARMmbed#167 (since reverted exactly because
of this bug):

make test-integration   # against integration/test_daplink_flash

Expected behaviour

CMD_CLEAR_FLASH should clear only the user-data partition (where
filenames and file content live), and leave the interface firmware
sectors and the bootloader untouched. The driver advertises this as a
user-data wipe — the contract should hold.

Observed behaviour

The whole F103 internal flash (or at least the interface-firmware
section) is erased. On the next reset / reboot the STM32 falls back
to its hardware DFU bootloader and re-enumerates as maintenance.

Suggested fix

Audit the sector-erase loop that backs CMD_CLEAR_FLASH: cap the
erase range to the user-data partition only. Anything covering the
interface firmware, bootloader, or maintenance metadata should be
protected.

Cross-references

• arduino-steami-lib: integration test reverted in commit 7108328
  on branch feat/daplink-flash-driver (will land in PR Update board_id for FRDM-KW24 ARMmbed/DAPLink#167).
• micropython-steami-lib: likely affected too — WSEN_HIDS-style
  cross-impl confirmation issue can be filed there once this is
  understood.

[nedseb]

Follow-up after comparing the Arduino driver code to the working
MicroPython one, since they hit the same bug.

Same wire transaction either way

The Arduino `DaplinkFlash::clearFlash()` → `DaplinkBridge::sendCommand(0x10)`
emits exactly one I²C frame: `START | ADDR_W | 0x10 | STOP`. The
MicroPython `DaplinkFlash.clear_flash()` → `DaplinkBridge._write_cmd(0x10)`
emits the same. Same address (0x3B), same command code (0x10), no
extra payload, no extra framing.

The only host-side difference is that the Arduino `sendCommand()`
calls `waitNotBusy()` AND `error()` after the write (two extra
read-only reads of `REG_STATUS` / `REG_ERROR`). MicroPython does
`_wait_busy` before the write only. Both are read-only register
reads on the bridge — they shouldn't trigger flash activity.

So the driver layer is innocent in both implementations.

What the firmware actually does

Tracing `steami_i2c.c` → `steami32.c` → `steami_flash.c` on the
`release_letssteam` branch:

1. cmd 0x10 → `TASK_CLEAR_FLASH` → `steami_flash_erase()`.
2. `steami_flash_erase()` reads `steami_flash_get_size()` (offset
   of the first `0xFF` byte from `STEAMI_FLASH_FILE_ADDR`) and
   erases that many bytes on the external W25Q64 SPI flash.
3. Bounds: `FILE_ADDR=0x000000`, `FILE_SIZE=8384512` (8 MB − 4 KB),
   `NAME_ADDR=0x7FF000`. Erase is confined to W25Q64 user-data.

The DAPLink interface firmware lives on the F103 internal flash, not
on the W25Q64. So a static read of the code does NOT show how this
could brick the interface firmware.

Two hypotheses left

1. Firmware version drift. The code I read is on
   `steamicc/DAPLink@release_letssteam` (and in the build artifacts
   that ship with `micropython-steami-lib`). The actual firmware
   flashed on the affected board may be different (older release,
   factory image, etc.) and may have the bug.
2. Re-entrancy / timing. Arduino does two extra register reads
   inside the erase window (STATUS and ERROR right after writing
   `0x10`, while the W25Q64 is mid-erase across multiple 64 KB
   blocks for ~20 s if the partition was full). If the firmware's
   I²C interrupt handler isn't fully re-entrant against the SPI
   erase loop on the W25Q64, the polling could nudge it into an
   unhealthy state. MicroPython doesn't poll-after, so it wouldn't
   trip this.

Could someone with admin access:

• Confirm which firmware revision ships on production STeaMi boards
  today vs. `release_letssteam` HEAD?
• Sanity-check the I²C ↔ SPI re-entrancy story around the erase loop
  (especially whether `STATUS` reads during `TASK_WAIT_FLASH_BUSY`
  are safe)?