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.

[kilograham]

We won't be providing a software workaround in the SDK as it isn't clear what you'd do. The user can use an external resistor

[recursivenomad]

Inspired by the conditional preprocessed functions for RISC-V, like restore_interrupts_from_disabled(), I've begun adding a conditional pull-down function to my code as one way to address this errata:

static inline void gpio_pull_down_fallback_up(uint gpio) {
    #if PICO_RP2350
        gpio_pull_up(gpio);
    #else
        gpio_pull_down(gpio);
    #endif
}

I use it for rising-edge interrupt pins which require a pull >10k as to not interfere with weak signals. As this is higher resistance than the <8.2k pull-down required by RP2350-E9, and one cannot know in advance when to activate the input for an interrupt, existing errata workarounds are not sufficient. I would prefer rising-edge interrupts to be pulled down so that the interrupt is ensured to be generated by a signal, and not the pulling resistor; but by at least ensuring a pulled state, the interrupt can still function with pull-ups when attached to always-asserted signals, without latching and leaking current to the signal that the interrupt is monitoring.

If this feels in the spirit of the SDK and you'd like a PR for this, I'd be happy to contribute.