[High] Flash settings commit can silently drop while a write is already pending

[cursor]

Severity

High — silent data loss for settings / pairings

Location

library/HOJA-LIB-RP2040 (submodule)

• src/hal/rp2040/flash_hal.c — flash_hal_write() (~L44–54)
• src/utilities/settings.c — settings_commit_blocks() (~L120–128)

Summary

flash_hal_write() returns false if a write is already pending (_flash_go), but settings_commit_blocks() ignores the return value:

bool flash_hal_write(...) {
    if(_flash_go) return false;
    // ...
    _flash_go = true;
    return true;
}

void settings_commit_blocks() {
    MUTEX_HAL_ENTER_BLOCKING(&_settings_mutex);
    flash_hal_write((uint8_t *) &live_settings, sizeof(settings_live_s), 0); // return ignored
    MUTEX_HAL_EXIT(&_settings_mutex);
}

A second save (e.g. Switch pairing commit overlapping GAMEPAD_CMD_SAVE_ALL, or rapid WebUSB saves) fails with no retry or error to the host. GAMEPAD_CMD_SAVE_ALL still reports success via callback.

Impact

User believes calibration, remaps, or BT pairing data were saved; power cycle reverts them.

Suggested fix

Queue or retry failed flash writes; surface failure to WebUSB (cb(..., false, ...)); do not report success when flash_hal_write returns false.

Found by

Automated code review (Cursor cloud agent)