I'm sad these seem to not have the fix for the E9 errata, making them entirely unsuitable for a lot of projects. I'll keep using the RP2040 instead, but the extra oomph of the M33's over the M0+'s would've been very welcome in a few places.
I have 0 experience in ASIC design, but it's not clear to me that this is fixable at all with just metal layer changes (which are around $50K a pop) like the fixes to previous errata's of the rp2040.
And a complete set of new masks at 40nm would probably cost them around $1M which I can't imagine would make financial sense for them, unless their contract with the pad designer includes compensation for that kind of issue.
So sadly I don't think this is likely to get fixed.
$1m is peanuts if your making chips. They should have done a respin for such a fundamental issue. This errata will be one of the first things you see when you research the part even if they later fix it. You can see even here it's half the discussion so far.
The RP2350 is 2.65x the die size of the RP2040, so about 8000 chips per 3000$ TSMC 40nm wafer gives you $~0.35 per die. Say 10 cents per die for singulation and testing, and another 10 cents for packaging and processing into reels. I have no idea what the M33 per-unit license is, but something like 5-10 cents seems reasonable, so let's assume 5.
So that's a cost of $0.60 with a reel price of $0.80 for a $0.20 gross profit per chip. So the break even point for full respin of the masks is around 5 million sold chips, 10 million chips when we're including the original masks. For comparison, according to Eben Upton, 10 million RP2040s have been made (but not necessarily sold) from 2021 to 2023.
Would a fix result in 5 million additional chips being sold? Maybe, and for all we know they could be working on doing that just now. Maybe their contract with the pad design provider even pays for a new mask set and it actually costs them nothing. Maybe all of this can be fixed with a cheaper metal layer fix.
But either way this isn't 'peanuts' and it's not a clear cut if doing it is economically viable.
I can't really even understand what the defect is - what kind of projects does it affect? I'm only interested in fairly basic applications of the rpi but I don't have the technical chops to know if I'm setting myself up for failure...
So normally when you have a microcontroller pin and you configure it as an input, you expect it to SINK current (as in, take voltage 'in'). The bug is that if the external voltage is between 1V and 2.5V (I don't remember the exact voltages, don't quote me on that) the pin will SOURCE current, acting almost as if you'd set it to be an output pin. It's not a lot of current, but it's enough to hold the pin at 2.2V.
This happens on all microcontrollers btw. Random charge accumulates and pushes the voltage on your pin to some arbitrary point. The way you fix this normally is by providing a path for that charge to escape in the form of a pull-down resistor. Usually you need something in the 100k range. Because of this bug you need something more in the 5k range.
For some circuits that's fine, for others it's more problematic.
> This happens on all microcontrollers btw. Random charge accumulates and pushes the voltage on your pin to some arbitrary point. The way you fix this normally is by providing a path for that charge to escape in the form of a pull-down resistor. Usually you need something in the 100k range. Because of this bug you need something more in the 5k range.
Many microcontrollers provide an internal, selectable pull-up or pull-down resistor (or neither). For example, on the STM32, it's a 30-50k, and individually selectable on a per-pin basis:
It's normal for pins to float, it's not normal for them to both lack an internal bias option and to float to a condition where they source significant current. You don't typically put a very low impedance external pull-down resistor on every single input pin.
> when you have a microcontroller pin and you configure it as an input, you expect it to SINK current (as in, take voltage 'in').
That's not how it works; input does not mean sink current. An OUTPUT low sinks current, and an output high sources current.
In a "normal" microcontroller (with no silicon bugs), an input pin is in a high-impedance state ("Hi-Z"), meaning it doesn't sink or source current -- but it can be configured to have an internal pull-up or pull-down resistor, in which case it will (respectively) source or sink a little bit of current, enough to keep it at high or low voltage (i.e., enough for a logical high or low) unless there's something else driving it.
The problem with the RP2350 is that (under some circumstances) there's a current leakage between the pin and the voltage rail, so when a pin is configured as input with a pull-down resistor, the voltage will not go down to the low level it needs to read a logical low as expected: it will be at around 2.2V, which is in the "undefined" region.
You are, of course, 100% correct. In my haste to explain the 'sourcing' behaviour of the errata I accidentally jumped to the sinking verbiage. Input pins are "pressure gauges", not "flow meters".
Simplifed when used as digital input a GPIO pin has three voltage ranges: 0V up to the logical low threshold, VCC down to the logical high threshold, and an and undefined range in the middle. The RP2350 burns a lot of power while in this middle range when any proper MCU shouldn't, because its quite common for this to happen. The "cure" is almost as bad as the problem because to stay out of this range you have to apply a strong external pull-up/pull-down resistor. This too wastes power, just not quite as much.
I haven't completely thought through this, but I can see issues with porting PIO-USB [0] for example. USB relies on a few different pulls to Vcc and Gnd with pre-defined values. On the host side you have to pull your signal lines to ground with 15k resistors. Those aren't strong enough to overcome the current leakage. The tricks where you enabled pad inputs only when you're reading the pin don't work here either as you can't do that in PIO.
Things like logic analyzers are going to have similar issues where their inputs will have to be buffered to provide a suitably low impedance path.
It's not insurmountable but it's enough for me to just fall back on the RP2040 in situations where I don't want to spend the effort to validate the RP2350.
It's not an issue for PIO-USB, since the pullup/pulldowns in USB are just used for device and speed detection. And for the pulldowns to do anything the pins have to be high impedance which you can't do in PIO code anyway. So just making sure to drive the pins low for 1 cycle before putting them in high impedance mode is sufficient as a workaround.
Could be an issue for logic analyzers, though usually you'd have a voltage translator in front of that anyway.
In situations where the power wasted by such a strong external pull-down or pull-up is inacceptable e.g. everything running of a small battery for more than a few hours. The resistors can easily burn more power than the whole chip.
