Luka-Filipovic opened a new pull request, #19793:
URL: https://github.com/apache/nuttx/pull/19793
## Summary
Fixes #19792.
`stm32_waitresponse()` in `arch/arm/src/common/stm32/stm32_sdio_m3m4_v1.c`
polls `SDIO_STA` in a busy loop bounded only by an iteration count
(`SDIO_LONGTIMEOUT` = `0x7fffffff` for response-bearing commands). The
hardware `CTIMEOUT` flag normally ends the wait within microseconds, but it
is only generated while the card clock is running and the command state
machine is in its Wait state. If the peripheral gets into a bad state,
`SDIO_STA` never changes and the loop spins for minutes at 100% CPU while
holding the FAT semaphore. With `CONFIG_PRIORITY_INHERITANCE=y` the
spinning thread inherits the priority of the highest waiter blocked on the
filesystem, starving every task at or below that priority (details in
#19792).
Bound the wait by time instead: 250 ms for response-bearing commands (the
same value #3669 used for the F7/H7 data path timeout) and 10 ms for the
no-response/R3/R7 cases. `CTIMEOUT` remains the normal exit; the software
bound only fires when the peripheral is stuck, and returns `-ETIMEDOUT` so
the existing mmcsd error handling can run.
The same pattern exists in `stm32f7/stm32_sdmmc.c`, `stm32h7/stm32_sdmmc.c`,
`at32/at32_sdio.c` and `gd32f4/gd32f4xx_sdio.c`.
## Impact
- No behavior change for working hardware: the loop still exits via
`CMDREND`/`CCRCFAIL`/`CTIMEOUT` within microseconds.
- A stuck peripheral now produces `-ETIMEDOUT` after 250 ms instead of an
unbounded spin (previously CPU-frequency dependent, ~2.5 minutes at
168 MHz).
- No configuration or API changes. `SDIO_CMDTIMEOUT`/`SDIO_LONGTIMEOUT`
had no remaining users and are removed.
## Testing
Host: Ubuntu 26.04 x86_64, `ghcr.io/apache/nuttx/apache-nuttx-ci-linux`.
- Built `stm32f401rc-rs485:sdcard` (`CONFIG_STM32_SDIO=y`) - clean:
```
LD: nuttx
Memory region Used Size Region Size %age Used
flash: 119660 B 256 KB 45.65%
sram: 8268 B 64 KB 12.62%
CP: nuttx.hex
CP: nuttx.bin
```
- nxstyle clean on the changed file.
- On STM32F427 hardware running the identical change: `sd_bench` works as
expected, and no problems were found in
regular usage (card init at 400 kHz, FAT mount, continuous logging at
the full transfer clock).
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
