Annoying behaviors related to SPI GPIO mapping

[duskwuff]

I recently spent a couple of hours debugging a mystery issue with an SPI display that turned out to be caused by some painful "gotchas" related to GPIO handling in the RP2 port:

1. The SPI class will automatically set pins to the SPI alternate function, but will not reset them when it is reinitialized or GCed. This can lead to unused GPIOs being left set to the SPI function.
2. GPIOs are not reinitialized during soft reboot. Any pins whose configurations were changed during a previous session will stay in that state.

The most problematic case here is if any extraneous SPI RX pins are left set to that function. When this occurs, the state of those pins will all be ORed together, potentially causing received data to be corrupted. (In my case, the extra pin was pulled up, so I was unable to read data at all.)

Questions:

1. Would it be appropriate for the RP2 SPI class to automatically loop through all RX pins for its associated instance and deinitialize any which aren't intended to be used?
2. Would it be appropriate for the RP2 port to reinitialize some or all GPIOs during soft reboot - at a minimum, to switch them off of non-SIO functions? Or is this expected behavior?

[scruss]

Would this issue go away if you tied all unused pins to ground and configured them as outputs, set low? This information is often omitted from hardware notes, and as a (mostly) software person, I often forget to do it. The RP2 datasheet doesn't have anything explicit about requiring this.

[Josverl]

There are actual differences between the different reset methods, especially with regards to external hardware (obviously) but also on chip periphials.
The details are spread through documentation, spec sheets and and issue comments

I started on this diagram, but still need to finish it.
I hope it helps in understanding what you are experiencing

https://github.com/orgs/micropython/discussions/18954