Swatantra-66 opened a new pull request, #20908: URL: https://github.com/apache/nuttx/pull/20908
## Summary Follow up on #19793 (commit `62b41ad9b40d5a513486a3b7f9be86ed8cdfe0e5`) to address and completely close #19792. ### Background & Problem In the STM32 SDMMC/SDIO drivers, `stm32_waitresponse()` (or `gd32_wait_response` / `at32_waitresponse`) polls the status register (`STA`/`STAT`) waiting for command completion flags (`CMDDONE` or `RESPDONE`). Previously, the timeout mechanism was bounded solely by an iteration counter: - `SDMMC_CMDTIMEOUT` = `100000` - `SDMMC_LONGTIMEOUT` = `0x7fffffff` (~2.14 billion iterations) The hardware `CTIMEOUT` flag in the status register is intended to signal a missing response, but it relies on the Command Path State Machine (CPSM) and card clock running. If the SD card is abruptly removed, the card clock stops, or the peripheral freezes/fails: 1. `STA`/`STAT` never updates with `CTIMEOUT` or `RESPDONE`. 2. The software loop spins for `INT32_MAX` (2.14 billion) iterations, consuming 100% CPU time for seconds or even minutes. 3. Because the calling thread often holds the VFS filesystem mount/inode lock (and may be boosted via priority inheritance), lower-priority threads are completely starved. 4. With higher-level `mmcsd` retries, the system remains unresponsive indefinitely. While PR #19793 fixed this in `arch/arm/src/common/stm32/stm32_sdio_m3m4_v1.c`, issue #19792 remained open because all other STM32 family variants and clone architectures shared the exact same iteration-counter loop. ### What This PR Does This patch replaces the loop-count timeouts with deterministic, tick-based timeouts (`clock_systime_ticks()`) across all remaining affected drivers: - `arch/arm/src/stm32f7/stm32_sdmmc.c` - `arch/arm/src/stm32h5/stm32_sdmmc.c` - `arch/arm/src/stm32h7/stm32_sdmmc.c` - `arch/arm/src/stm32l4/stm32l4_sdmmc.c` - `arch/arm/src/at32/at32_sdio.c` - `arch/arm/src/gd32f4/gd32f4xx_sdio.c` ### Timeout Values & Design - **`SDMMC_LONGTIMEOUT_MS` (250 ms)**: Configured using `MSEC2TICK(250)` for response-bearing commands (`R1`, `R1B`, `R2`, `R4`, `R5`, `R6`). 250 ms is the maximum response timeout defined by the SD Physical Layer Specification for busy operations. - **`SDMMC_CMDTIMEOUT_MS` (10 ms)**: Configured using `MSEC2TICK(10)` for commands with no response, `R3`, or `R7`. - **Hardware vs. Software Exit**: Under normal operating conditions, the hardware `CTIMEOUT` flag still detects missing card responses within microseconds. The software tick timeout acts strictly as a safety backstop when the hardware peripheral or card clock is unresponsive, gracefully returning `-ETIMEDOUT` so the higher-level `mmcsd` error recovery and retry logic can execute. Fixes #19792 ## Impact - **Is new feature added?** No. - **Is existing feature changed?** Yes (SDMMC/SDIO command response wait loop). - **User impact:** Eliminates system hangs, CPU starvation, and priority inversion when SD cards fail or are removed on STM32F7, STM32H5, STM32H7, STM32L4, AT32, and GD32F4 platforms. - **Build / ABI / API impact:** None. Fully compatible with existing drivers and configurations. ## Testing - **Style & Static Check:** Ran `./tools/checkpatch.sh -m -g HEAD` on the commit; all style and commit message checks pass without warnings or errors. - **Consistency Verification:** Timeout semantics and implementation match the merged reference commit `62b41ad9b40d5a513486a3b7f9be86ed8cdfe0e5` (`arch/arm/src/common/stm32/stm32_sdio_m3m4_v1.c`). -- 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]
