pico-sdk support for RP2350-E9 workarounds?

[dhalbert]

Now that erratum RP2350-E9 is well characterized (raspberrypi/pico-feedback#401 (comment)), are there plans for pico-sdk to provide support for the suggested workarounds for reading a GPIO pin? Or if not in pico-sdk, some examples of workaround code could be added to pico-examples.

Assuming I understand correctly, there are several scenarios:

• Internal pullup is enabled: no workaround needed.
• External pullup is present: no workaround needed.
• Internal pulldown is enabled: workaround needed. GPIO0.IE should be disabled when the pin is set up for input. When the pin is read, input is enabled, the pin is immediately read, and then input is disabled again.
• No internal pulls enabled:
  • External signal is strong and can overcome the leakage current: no workaround needed. No need to disable input (GPIO0.IE).
  • External signal is weak: workaround needed, as above.

Given that the pin should be read immediately after GPIO0.IE is enabled, I think this implies the enable and read should be inside a critical section (cf. earlephilhower/arduino-pico#2380 (comment)).

In some cases, if workaround support is provided, the sdk can determine what to do, and in other cases the sdk must be informed of the use case. At the Hardware API level, whether the workaround is needed or not is only if the internal pulls are enabled. If there is a High Level API wrapper, it cold keep track of the specified use case.

[dhalbert]

Policy followup re what CircuitPython is going to do:

Recently we CircuitPython discussed internally what to do about the E9 workaround. Without adding additional API specifically to support the RP2350, there is no way to inform CircuitPython in various use cases, "well, yes, this is a weak input signal, so do the workaround". The only hint would be if you enabled the internal pulldown, but there are other cases as well. We do not right now want to make a special-case API for the RP2350.

So our conclusion is to not implement the workaround, at least for now, but simply to document the restrictions that make it unnecessary: don't expect the internal pulldown to work, use an external pulldown 8.2k or lower if you need a pulldown, or make sure your input signal can sink enough current to override the leakage current. This is defining the problem away.