Closed TzOk83 closed 2 years ago
Ignoring the /RESET line was a poor design choice I made back in the old pre-1.0 days.
Unfortunately it's much more complex than connecting /RESET to the reset pin of the blue pill. A direct connection would make debug impossible (STM32 reset triggers the bootloader in dev mode) and would be problematic for the few SD cards that take a long time to boot (especially for the people with many SD cards). Also, you don't want to reset in the middle of SD card communications to avoid damage.
Since I don't want to make incompatible changes to the pins for v2.x versions, I will keep the design as it is right now. 2.3 has many refinements to avoid false command triggering so the issue is low priority. If a version 3.x ever comes, I will incorporate that modification if possible. I'll keep this issue opened as a reminder of this good idea.
I guess you don't need to literally reset the STM32 on ST reset, but rather perform a kind of soft-reset when /RESET signal on ST is asserted. So use the /RESET line as an IRQ source, rather than bind it to the STM32's reset pin.
Done it in 3.0a ! 3.0a is marked alpha because the new integrated driver is still a mess, but if you don't use it you are probably fine. /RESET connects to PA15.
ACSI has a /RESET signal, which can be used. ST pulls /RESET low at power-on, this could resolve the issues with power cycling ST requiring to manually reset the "blue pill".