The worsening Raspberry Pi RP2350 E9 erratum situation | Hacker News Reader

The worsening Raspberry Pi RP2350 E9 erratum situation

hackaday.com

94 pointsirdc19 comments

After this was published, RPi concluded the problem was a leakage current and updated the datasheet [1]. Roughly, a tiny trickle of electricity, about 100 microamps, flows out via the pin when it shouldn't. This can raise the voltage to around 2V unless you provide a path to drain it away.

I've ordered one and am confident for anything I'd do it's not an issue. Usually any input I have is connected directly to the output of something else and that provides the path for the leakage current. If that isn't true, e.g. a button, then I'm using a pull-up and thus also not affected. Certain analog measurements could be affected, but again not if they have a low impedance (i.e. strong) source. The current is around 100 microamps so it's not stressing the source much.

It's unfortunate that this is happening in the chip that so massively improved the low power sleep states. Designs needing wake from sleep on pin change with an active high / inactive high-z signal are not going to be good. That requires a strong external pulldown and will be constantly burning those 100ish microamps. That doesn't sound like much, but it's a lot of power for being asleep.

Still I'm very excited for the improved CPU performance and even more RAM. Once mine arrives I'm going to see how much faster it can do some fixed point DSP than the RP2040.

[1] https://github.com/raspberrypi/pico-feedback/issues/401#issu...

See https://community.element14.com/products/raspberry-pi/f/foru... for some really wild scope traces demonstrating the soft latching problem (hat tip to Ian in the Hackaday comments section).

I wonder if the self-imposed deadline of announcing it at DEFCON caused them to rush validation more than they would have otherwise. If not for that then they could have quietly delayed the announcement until the next stepping was ready, and nobody would have been the wiser.

I would be very surprised if they provide a stepping for this

Why? They're going to be making this for years, and the issue must surely affect sales.

RPi should have never gone public on the stock exchange.

Most technology companies shouldn't. Sometimes its the final stage for enshitifcation and other times like now it is the beginning.

It was nice using RPI's in their golden era. That is now over. This story will continue to repeat itself until we take a more honest look at our current economic systems at play.

Ehh these were in stock at Adafruit a couple days ago and I decided not to order due to having no immediate use for them. I think I'll wait. The main bug I remember in the RP2040 was some mistake in the ADC causing precision loss. The RP2040 is ridiculously powerful for an MCU so I think most of us either can do without the RP2350 for a while, or really need a Linux board anyway.

You might be waiting for a looong time. If RPi Ltd planned to ship the next chip in two or three years time anyhow, I doubt they'll bother with an update to the RP2350.

iiuc, it's a leakage current at an IO pin configured as input and connected to a high impedance output (or left floating). Not the most common situation (leaving an input unconnected is bad practice anyhow) and there are workarounds (expect an updated errata with those soonish). The RP2350 has some features which make it interesting for applications where a RP2040 doesn't fit (e.g. secure OTP storage).

This bug makes these chips practically useless for high-impedance inputs such as touch sensors and multi-drop buses. Basically anything with an impedance above 8,2 kΩ. This is really a problem.

shrug and for those, limited, situations you could insert a buffer chip between signal and Mcu, or add an RP2040 chip, or just use an RP2040. These things are so dirt cheap that even the workarounds aren’t expensive.

And for the vast majority of cases the chip is fine, I2C is fine, the ADC is fine (despite what hackaday says), the SPI is fine, GPIO output is fine, GPIO input-with-pull-up is fine, GPIO input-with-pull-down needs a stronger pull than usual, 4K7 works great.

The use-cases where you have problems are being blown way out of proportion IMHO. All chips have errata, there are workarounds to most of this one’s issues, and there are alternate solutions for the few cases where it can’t be worked around. This is normal.

I’d also point out that there’s a guy on the RPi pico forum who’s successfully linked a touch-sensor input to the RP2350 without problems…

Agreed with the sentiment that this isn't that bad. As far as chip errata go, it's definitely unusually broad impact. So yeah, it's an abnormally bad bug. But for your average Pi Pico user, they still will never notice. The only possible thing I could imagine your average micropython tinkerer needs to know is "use pullups not pulldowns with buttons on the Pi Pico 2". Everything the entry level hobbyist is likely to encounter is a sufficiently strong drive to avoid the issue. Capacitive touch buttons might not work without external components, but I don't know.

Bigger picture, RPi is doing their third ever chip fab. The errata (silicon bug) list for the prior RP2040 is shorter than some I've seen from companies five times their age.[1] This issue isn't a logic error and wasn't going to be found by digital simulation. This is analog weirdness. Their documentation, including of errata, is among the best I (moderately experienced hobbyist) have ever encountered for a microcontroller. RPi is doing an excellent job and this is a but a hiccup. Maybe it's concerning for industrial customers, but as a hobbyist I'm still excited for my Pico 2 to arrive.

[1] Favorite errata warstory: Radio chip will lock up and need to be power cycled if a received packet has a particular corrupt length field, one bit flip away from one we used. Official solution: don't allow packet corruption. Turns out radios don't work like that.

If they hover around 2V, the means no mosfet gates too without an additional pull up/down? Seems like an issue that couldn’t possibly have made it past the first QC test.

The GPIOs work fine for output, only input is a problem, so controlling MOSFETs should pose no problem.

If I assign the pin to input like I want to leave a gate floating or not effect it’s pull-up /pull-down or I don’t get to chose because I am in an unprogrammed or reset state… then what happens?

Input on a pin tied to gate happens all the time.

I believe they shipped an update to the RP2040 to fix the ADC. This discussion has been helpful though. We'll see how well RPi documents the RP2350 bug.

It had sounded to me like the input pins were going to burn an extra 100uA or so per pin, over potentially dozens of pins. That's a lot of power for an MCU. Do I misunderstand?

I'd recommend taking a look at the Teensy. It's much more powerful.

At similar pin count it is 6 times more expensive so yes it can. The advantage of the rp2 series chips is that they are also pretty inexpensive to integrate directly on your own boards. They are not playing in the same categories here.

I think the main competitor to the Pico is the various ESP32 series boards that are out there. From earlier generations there are still variants of the Blue Pill at maybe $2 per board. I could imagine using a Teensy for something more serious where the cost was justified. But, I think we need a successor to the Pocket Beagle, or maybe a cross between the Pi Zero and the Pico.

Reply on news.ycombinator.com