stm32/sdcard: Add support for UHS-I SD cards. - #19623

Summary

This adds UHS-I support (1.8V signalling, SDR50/SDR104) to the stm32 port's SD card driver, for boards whose hardware can switch the SD bus I/O rail between 3.3V and 1.8V, and enables it on the OPENMV_N6 board at SDR104/200MHz.

On the OpenMV N6, same board/card/workload (16MB file, 512KB chunks), unpatched vs patched firmware:

SDR50 at 100MHz (43.5 MB/s raw reads) is available as a conservative alternative via one board macro.

A board opts in by defining MICROPY_HW_SDCARD_VSELECT_PIN (drives the SD rail voltage select) and MICROPY_HW_SDCARD_RESET_PIN (active-low SD card power). The reset pin doubles as a hardware-revision detect: it is sampled at startup and reads high only on UHS-I capable hardware, so one firmware supports old and new board revisions. The voltage switch itself (ACMD41 S18R / CMD11) is the HAL's USE_SD_TRANSCEIVER flow; the transceiver callback drives the select pin and, on STM32N6, moves the configured VDDIO domain (MICROPY_HW_SDCARD_VDDIO, defaulting from the SDMMC instance) to the 1.8V pad range. Cards that don't support 1.8V get a proper CMD6 high-speed switch at 3.3V; any UHS failure power-cycles the card via the reset pin and falls back to the existing 3.3V behaviour.

Two STM32N6 hardware findings shaped the implementation:

1. The SDMMC data-path status flags read stale after the 1.8V switch until the FIFO is accessed. Command-path flags are fine and IDMA/IRQ transfers are unaffected, but any CPU-polled receive loop that gates FIFO reads on RXFIFOHF/DATAEND deadlocks — which is exactly what the HAL's own SD_UltraHighSpeed()/SD_SwitchSpeed() do (against a 0xFFFFFFFF ms software timeout), so HAL_SD_ConfigSpeedBusOperation() hangs forever on this part. The driver therefore performs the CMD6 switch itself using the CMDTRANS mechanism, drains the 64-byte status from the FIFO after the transfer time has elapsed, and only then consults the (by then refreshed) status flags. This was proven at register level: the FIFO contained the complete, correct switch status while STA/DCOUNT still claimed no data had arrived.

2. VDDIOxVRSEL writes are silently ignored unless the matching HSLV_VDDIOx OTP fuse is programmed. Without the fuse the pads stay in 3.3V mode: the (slow) initialisation still passes, then every transfer at UHS rates fails. Verified by A/B on two boards (fused vs unfused). The driver reads the range back after switching and treats a non-stick as a failed attempt, so unfused boards cleanly fall back to 3.3V — and once a bootloader update programs the fuse, the same firmware starts running SDR104 automatically. The OPENMV_N6 board commit programs the fuse (RM0486 Table 18, OTP word 124 bit 14) alongside the existing VDDIO2/3 fuses.

Testing

• OpenMV N6 (STM32N657, fused): SDR104 at 200MHz — numbers above, data CRC-verified against 3.3V-mode reads of the same blocks, 10/10 power-cycle/init soak loops at both SDR104 and SDR50, plus 16MB file write/read-back CRC verification.
• OpenMV N6 (second board, OTP fuse unprogrammed): VRSEL non-stick detected, clean automatic fallback to 3.3V/50MHz — 10/10 init soaks, 22.35 MB/s (identical to unpatched firmware), OTP verified untouched before/after.
• Regression on non-UHS boards: builds without the new config macros compile to byte-identical binaries (verified by hash for four board targets — the feature preprocesses away entirely). On-hardware SD regression runs (raw reads, file write/read, CRC verification) passed on STM32F427, STM32F765 and STM32H743 (x2 boards) hardware with speeds unchanged.
• Build-tested: PYBV11, NUCLEO_F767ZI, NUCLEO_H743ZI, NUCLEO_N657X0 (the latter verifying the USE_SD_TRANSCEIVER=0 default path on N6).
• Non-UHS boards keep ClockPowerSave enabled and the exact current init sequence; UHS-I init disables clock power saving (as the ST BSPs do) because the voltage-switch and CMD6 sequences stall with it enabled.

Trade-offs and Alternatives

• Code size: +992 bytes text on OPENMV_N6 (the board that enables it). Zero impact on all other boards — without the config macros the binaries are byte-identical.
• Using the HAL's HAL_SD_ConfigSpeedBusOperation() instead of a driver-side CMD6: attempted first, but it hard-hangs on the N6 (finding 1 above), so the CMD6 transaction is implemented in sdcard.c with the same command-transfer mechanism regular block reads use.
• Unfused/older hardware cost: on UHS-capable board revisions whose OTP fuse isn't programmed yet, each SD init spends two failed UHS attempts (two card power cycles, ~300-400ms) before falling back to 3.3V. This is once per mount and buys automatic activation when the fuse is later programmed; caching the result to skip retries was considered but rejected as unnecessary complexity for a once-per-boot cost.
• SDR104 vs SDR50 default: the generic driver defaults to the conservative SDR50; OPENMV_N6 explicitly selects SDR104, which soaked cleanly. The receive path uses the feedback clock via the delay block with its default configuration, matching what the ST HAL does for UHS modes; per-unit DLYB tuning was not needed at 200MHz but could be added later if a marginal card/board combination shows CRC errors.