How Did El Doctor Gusman resolve the Pico 2 Errata E9 GPIO Pad Problems?

[Ian-Grant]

Hi all,

I'd be interested to know how Dr Gusman's design deals with the Pico 2 floating pad leakage problem. Is it just that it is not really a problem except when sampling a high-impedance state on inputs? I have searched the GitHub repo for Errata and only see the one mention in "Pico 2 Born Dead" in the README. I want to know because I am working on a project to allow programmed control of 5v TTL logic using Pi Pico 2.

[gusmanb]

There are two main components that solve the problem.

First of all, V2 does not allow to be used without the level shifters. With V1.0 the shifters where optional, and thus, if you used the Pico2 without them it failed miserably, you got random values often. Thankfully the shifters that I use are push-pull and do a very good job at keeping the levels even when the input is floating, so by making them an integral part of the design it solved this problem. I still preserve the v1.0 PCB version active because of this, if you are going to use the analyzer with regular modern components having the shifters offer no benefit and if you want to build yourself the analyzer is a lot simpler to still use V1.0 (but of course, you are restricted to the original Pico, what for a lot of use cases is more than enough).

The second one is the triggering/chaining mechanism, I interconnect two IOs in the Pico to intercomunicate the trigger PIO machine and the capture PIO machine, this in the original design was simply a short between them, with the RP2040 it works flawlessly, but with the RP2350 sometimes the trigger was stuck. As the analyzers can be chained, when the trigger machine is disabled I set the output pin to high impedance, and then in subsequent captures it happened that sometimes the capture machine was reading a trigger before the trigger was really raised. It could be solved via software but it would also introduce some safety concerns as the chaining mechanism is nothing else but connecting all the devices trigger networks together, and if by any chance two of these picos instead of placing their outputs to high impedance placed them as outputs, one to hi and other to lo, it could cause a shortcircuit and fry the IOs. You can think on placing diodes in the network but that would be against the design of the device, I need to trigger all the devices at the same time, in an interval of less than 2.5ns, and fast diodes have a propagation delay around 4ns, that would mess up the readings between the multiple chained analyzers.

So, what was the solution for the second problem? A simple resistor tied to ground. This brings down the current on the GPIO input when the outputs are set to high impedance and "unstucks" the inputs.

Keep in mind that the problem is only when you use the IOs as input (even the ADCs have some problem with these, but I haven't used them so I cannot speak about how it affects the designs), so if you are going to control TTL logic and not reading it you will be 100% safe. Also, even if you read from TTL logic and it is not tri-stated you should also be good. Just in the case that you are going to read tri-stated inputs (like the analyzer did in V1.0 without the level shifters) you will hit the problem, adding a 8k2 resistor to ground on each of the inputs will get rid of the problem.

Hope it helps you :=)

[Ian-Grant]

That is a great help, thank you! And congratulations on a seriously impressive project!

[frohro]

This is fixed in the new RP2350 A4 version from Raspberry Pi!