Oh noes... I broke my Picos

[marcdraco1-gif]

I've found a probable fix for my latest "whoopsie" - but perhaps someone else has experienced this?

To be clear, the following discussion describes some electronics which are all running at 3v3 (there are 5V parts in there but they are all behind the 3v3 regulator).

I had the Pico configured to receive I2S from an external board which doesn't use any current limit but now (after another day of failures) I've just read that the input current on Pico PIOs is limited. Easy fix, naturally - just a small resistor and better I find this now before I finalise the board! :)

I wonder if any one else has run into this. I'm familiar with not trying to source too much current from a pin but never experienced it pulling too much current. I was assuming I was driving the MOSFET's gate which is essentially a small capacitor, but you know what "assume" did. Looks like I'd better get stuck back into the RP2040 datasheet before I jigger another one.

Something new for the book. Better I make mistakes now than have someone else chase me with a big stick later.

I don't have a differential scope probe to measure the current during high-speed transitions so I'll try put some series resistors in there and see what happens.

This is probably in the datasheet somewhere - maybe someone else knows if there's schematic for the inputs? Man do I feel like a doofus - again.

I guess this the cost of a configurable device where the same "pin" can be an output or an input.

[earlephilhower]

I don't think I've read of such a limit on an input on the RP2040. Input current is going to be on the order of uA by design, if that, in normal operation. The datasheet would be the reference there, section 5.5.3.4.

That said, there are ESD diodes which should never engage in normal operating mode that will have current limits (i.e. if you go over Vcc or below GND on an input) before they die.

[marcdraco1-gif]

Exactly that Earl, yes. My own custom board runs at 3,3v (it can go lower) but the problem is that I've been powering the custom side of things from its own USB and then applying power to the Pico. Even 3,3 is enough to push too much current through them it seems

This is almost certain to have jiggered the ESD diodes because I was assuming (wrongly) that I was driving a MOSFET gate and the effect would be harmlessly charging the gate capacitance.

I'm a little shocked this isn't more widely promoted as a feature (not a bug) in the hardware since it's a bit of a show stopper. I don't know how much current the controller can kick out on its own digital ports, but it's clearly more than enough to do damage.

Had I mounted a Pico (just the MCU) on the same board, it would have time to power up before the other chips went "live" (about 500 mS) but to keep costs reasonable I figured it would be smart to use a Pico module. This means adding some protection resistors as I'm creating what you might call a TAH (a HAT in reverse). The Pico mounts on top of the I2S module for ease of programming via Circuit Python or C++ via USB vs. the SWD port.

I did see a reference (which of course, I can't find just now) that suggested 1 K current limit although, as you said, the actual impedance is so astronomical, a much larger value will still work. I'll try this on some other ports to see if it comes to life - after I've had time to check they are actually dead.

A schematic of the input circuit would have helped here so I knew what I was dealing with rather than just assume it was like all the stuff I fiddled with back in the 1980s (yes, I'm really crawling out of that electronic primordial ooze).

The really weird thing is that both busted Picos (so far as I can tell with minimal testing) both report the same value for the Left and Right inputs - all the time. L stuck at 15 and R was stuck at 384 on both boards. I pulled a third (brand new one) out of box of spares and sure enough - 0:0 for L&R with no signal applied.

The same fault on two Picos can either be a code error, and that's not possible since this is mature code or some external factor and that only leaves an over-current or static discharge.

I'll try this later today and get back to you - it might be an "edge case" for the hardware but it's better that we know about this in advance. If I'd managed to make the full board and HAT - without discovering this I'd be crying into my beer. (Well, my empty glass, because I've ploughed my beer fund into this project sufficient to keep the town drunk for a month.)

And (shocker) swapped to some alternative PIO pins on a "busted" board and what do you know? 0:0 (no signal in, so no data out). I know you know this Earl, but I'm cognisant of other people picking these discussions up, not to mention AI (artificial ignorance) which tends to create as many, if not more, problems than it actually solves. The short-sighted greed of companies like OpenAI ("open"... oh my life), Microsoft and Google is rotting the Internet as we knew it faster than I ever imagined possible.

It's rather strange (and I'm not about to sacrifice even more PIOs to find out at this stage) that the breakage would reflect the same value in both PIOs. You're more familiar with the guts of this thing than I'll ever be so perhaps you have a better guess?

So yeah, looks like not powering the Pico ahead of the controller is enough to make it go "poof".

Well darn - put resistors in the circuit (larger than I figured I'd need) and still nuffin'. I wonder if there's something going on inside the PC? The grounds should be common via the USB shields, etc. but maybe I've missed something else.

For anyone following along: the board has a fixed I2S slave and fixed master, both at 3,3 volts (I'm just tapping off) another slave - and it works without so much as a blip. The 3v3 power is regulated by an LDO to the other devices and it's stable.

Time isn't on my side (never is) so I'm gonna see if I can replicate this issue with an old ESP32 or and I think I even have a black pill lying in a drawer somewhere. I've got an STM32 nucleo but I really don't want to blow that up! I can sacrifice a Pico or two if it means getting to the bottom of this.

[earlephilhower]

I did see a reference (which of course, I can't find just now) that suggested 1 K current limit although, as you said, the actual impedance is so astronomical, a much larger value will still work. I'll try this on some other ports to see if it comes to life - after I've had time to check they are actually dead.

As electricians say, it's the current and not the voltage that kills you. The ESD diodes I'm familiar with are great for high breakdown voltages but little actual current. Assuming the 3.3V source impedence is ~0 for sake of argument, and the Vdiode = 0.5 (probably wrong, but I'm sure it's specified in the datasheet or addendum), then you have a (3.3 - 0.5) / 1K = 2.8mA in that situation. I can't seem to find any specs in the datasheet on that (IIRC other devices have something like 5-10mA limits), but if you post this question on the RPI Pico Other Boards forum I'm sure an engineer from RPi wll have some good input. 😆

But maybe that's a red herring This doesn't make any sense to me from a physical damage perspective:

L stuck at 15 and R was stuck at 384 on both boards.

Are you saying the I2S input PIO is returning constant values, but different per L/R channel? If things were busted I would expect either constant 1 or 0 or random noise. Returning 15 is actually very hard to do, if the input pins are damaged. Not only is it a series of 1s and 0s on the I2SIN pin, but that sequence needs to be perfectly synchronized to another output pin driven by the PIO to make that happen. The PIO FIFO where this data is stored before DMA to RAM is very far from the input pins, and it's driven off of the ISR (input shift register, not interrupt) register.

I'd check the actual I2S bus (they're slow enough a $10 logic analyzer and pulseview can verify them in most cases) at the pins of the RP2040 chip. Maybe there's something fishy with the actual inputs.

You could also do basic sanity tests using digitalWrite and logic probing pins, or digitalRead while driving from the outside...