The Raspberry PI PICO 2, now has extra RISC-V cores

[MK14]

As far as I understand it, when using the ADC on a pin its digital input is supposed to be disabled therefore the bug doesn't affect ADC operation. Right at the end of the part you quoted :

As normal, if ADC channels are being used on a pin, clear the relevant GPIO input enable as stated in Section 12.4.3.

Thanks, I didn't notice that bit.

The thing is, having this weird (latched) fault state, with (what appears to me as) this extremely long winded, complicated technical details on how and when to avoid it.

Is just asking for trouble and possible weaknesses in peoples designs.

The RP2350 manual, seems to be 1,349 pages long, currently.

I think it is asking too much, to expect all users, to realize/remember and technically handle this overly-complicated possible fault situation.  Also, how do users, extensively check their designs for this possible short-coming.

Some (perhaps many) users, just want to use an Arduino library function (or similar methodology), connect some standard (pre-assembled), hardware to it, and then have fun with their project.

Not have to read all of a datasheets 1,349 pages, understand complicated technical issues, then consider if each of their hardware inputs, will meet all of E9's, errata specifications.

Some sources, seem to state, that the majority of Pico2 units, will be used in educational and (by implication, beginner/hobbyist) environments, such as Schools and Universities.  Some of whom, shouldn't really have to deal with such technical difficulties.

So in summary, since this product (at least the Pico2 development boards), seem to be aimed, at beginners, early-education, and other non-expert (yet), users.  It seems to me, to be unfair for them to have to deal with this problem, themselves.

I.e. I consider these (current version) of Pico2 boards, to be (technically) faulty, and unsuited to their task.

The fact that hardened/experienced, electronics engineers (and similar), should be able to handle this shortcoming of the Pico2's inputs, via the errata (E9), shouldn't stop them from properly creating and releasing a 'fixed' later version of these chips (RP2350), assuming the costs and other practicalities, allow them to do so.   

[SpacedCowboy]

> I.e. I consider these (current version) of Pico2 boards, to be (technically) faulty, and unsuited to their task.

I don't think it's as bad as that. Most chips have errata and you use workarounds. Bottom line seems to be that:

• Inputs with external pullups of 10k will work
• Inputs with external pulldowns of less than 8k2 will work
• Driven outputs will work

It means you can't connect high-impedance devices to an input port without going through a buffer but otherwise it seems still a reasonable part to use. They recently updated the E9 text to make it clearer what the issue is, and where it will occur. I agree it's a bit wordy, but the above seems to hold.

[MK14]

> I.e. I consider these (current version) of Pico2 boards, to be (technically) faulty, and unsuited to their task.

I don't think it's as bad as that. Most chips have errata and you use workarounds. Bottom line seems to be that:

• Inputs with external pullups of 10k will work
• Inputs with external pulldowns of less than 8k2 will work
• Driven outputs will work

It means you can't connect high-impedance devices to an input port without going through a buffer but otherwise it seems still a reasonable part to use. They recently updated the E9 text to make it clearer what the issue is, and where it will occur. I agree it's a bit wordy, but the above seems to hold.

That is NOT how I see it at all.

The parts BASIC specification, that a competent engineer/hobbyist/person would reasonably expect, should follow the NORMs.  I.e. General normal/usual inputs should be (as with most modern day, logic/MCU/similar devices), have a high impedance, and not need external pull up/down resistors, or much current, at all, under standard/normal/usual conditions.
They also, should NOT exhibit latch-up behavior, under reasonable/normal conditions.

To rely on them specifically checking the datasheet and/or errata, on a supposedly working, tested and under-full production part (i.e. NOT a specialist device, or very early prototype part etc), is risky and (opinions can vary) NOT reasonable.

E.g. A teacher/lecturer, of reasonable background electronics knowledge and abilities.  Should be able to walk into a classroom, full of pupils/students, with Raspberry Pi Pico2's at the ready.
Then draw up a circuit on the white-board/projector etc, showing a simple push switch, a 47k ohm resistor, as pull-up or pull-down, and some simple code, used to set up the appropriate pins as inputs, read the input(s), and process that input, perhaps lighting an LED, when the switch is pressed, or toggling its state.

To rely/assume the teacher will already know about this issue and/or have read the entire, very long datasheet and/or will have carefully read/checked the errata, is (opinions can vary), a bad (or even terrible) idea.

That is just one example, out of millions (and probably a lot more), on how this situation could easily cause undesirable effects.

Yes, technically speaking it can be sorted out, with appropriate hardware changes, IF YOU KNOW ABOUT THIS PROBLEM, in advance.

But (opinions can vary) I seriously doubt, everyone will know about it, or do the due diligence (check the errata etc).

[SiliconWizard]

I consider both issues found so far (susceptibility of the internal buck converter and this IO problem) pretty "severe" to consider it for any serious use and can't see how it can be sold as is as a part for any commercial product.

For hobbyist use, as long as you follow the workarounds, that should be usable.

[PCB.Wiz]

The thing is, having this weird (latched) fault state, with (what appears to me as) this extremely long winded, complicated technical details on how and when to avoid it.

The pin current source effect only really impacts light pulldown designs.

i2c use will be fine, which is to me a key reality check.
Even open-drain RC monostable type delays are ok, as the assist source current only appears after the pin passes the logic threshold.

Their graphs are a little suss, (too few points & poor correlation to pin state ) but it looks very similar to the classic 8051 quasi bidirectional port.
Billions of those parts shipped, and continue to be used.
Newer 8051 variants have more port controls so users can enable/disable the quasi bidirectional action.

Note the PFET nearest the PIN, has input positive feedback so a held low pin has no Icc current, but a rising pin gets an acceleration when the threshold is reached.
Any light pulldown needs to briefly overcome that upward assist. 
80C51 Port Pin design

I.e. I consider these (current version) of Pico2 boards, to be (technically) faulty, and unsuited to their task.

That's cool. You are entirely free to never use it then. 

[brucehoult]

I consider both issues found so far (susceptibility of the internal buck converter and this IO problem) pretty "severe" to consider it for any serious use and can't see how it can be sold as is as a part for any commercial product.

For hobbyist use, as long as you follow the workarounds, that should be usable.

I would have thought the other way around. Professionals embedding it inside something else, which they are designing, should be capable of designing so as to avoid the problems. It's non-ideal, but then so are transistors!

It's hobbyists who are far more likely to run into problems. Especially as they probably don't read the manual in full.

[PCB.Wiz]

This is how Atmel specify the Port pins, Raspberry Pi should include a similar pin diagram and pin spec.
Note

Atmel AT89LP51 ITL Logic 1 to 0 Transition Current VIN = 2V, VDD = 5V ± 10%    MAX   -750 μA

RaspPi say 8k2 pulldown is ok, so that suggests the RP2350 has a 3v3  ITL Logic 1 to 0 Transition Current    MAX   -150 μA

[PCB.Wiz]

> I.e. I consider these (current version) of Pico2 boards, to be (technically) faulty, and unsuited to their task.

I don't think it's as bad as that. Most chips have errata and you use workarounds. Bottom line seems to be that:

• Inputs with external pullups of 10k will work
• Inputs with external pulldowns of less than 8k2 will work
• Driven outputs will work

It means you can't connect high-impedance devices to an input port without going through a buffer but otherwise it seems still a reasonable part to use. They recently updated the E9 text to make it clearer what the issue is, and where it will occur. I agree it's a bit wordy, but the above seems to hold.

They are prone to be very wordy !
I had trouble following what they were trying to say, until I saw the current plots. It's a light regenerative P-FET.

It means inputs with any external pullups will work, they do not need to be 10k.

Any pull down needs to exceed the pin supplied current  ITL Logic 1 to 0 Transition Current    MAX   -150 μA
ie even a somewhat feeble optocoupler will be ok.  Transistors, MOSFETS and i2c parts will all be fine.

Someone using ESD protection resistors should use less than the 8k2, to give themselves some noise margin.
eg a 4k7 resistor will pull low with 0.5V of VOL or ground differential.

[MK14]

The thing is, having this weird (latched) fault state, with (what appears to me as) this extremely long winded, complicated technical details on how and when to avoid it.

The pin current source effect only really impacts light pulldown designs.

i2c use will be fine, which is to me a key reality check.
Even open-drain RC monostable type delays are ok, as the assist source current only appears after the pin passes the logic threshold.

Their graphs are a little suss, (too few points & poor correlation to pin state ) but it looks very similar to the classic 8051 quasi bidirectional port.
Billions of those parts shipped, and continue to be used.
Newer 8051 variants have more port controls so users can enable/disable the quasi bidirectional action.

Note the PFET nearest the PIN, has input positive feedback so a held low pin has no Icc current, but a rising pin gets an acceleration when the threshold is reached.
Any light pulldown needs to briefly overcome that upward assist. 
80C51 Port Pin design
(Attachment Link)

I.e. I consider these (current version) of Pico2 boards, to be (technically) faulty, and unsuited to their task.

That's cool. You are entirely free to never use it then. 

I have to admit, I don't yet properly/fully understand (technically), this fault mechanism.  So I accept, I could easily be badly over-estimating how much of an issue, it really is.

In the past, when there use to be chips (very early CMOS ones, come to mind), that could latch up, if even slightly abused.  I remember (hearing), it caused nothing but problems and annoyances.  Resulting in later chips, boasting that they were 'Latchup free'.

It is NOT so obvious, even if I did more fully understand the fault, when and how, in real life situations.  It would cause a problem/issue.

[SpacedCowboy]

> I.e. I consider these (current version) of Pico2 boards, to be (technically) faulty, and unsuited to their task.

I don't think it's as bad as that. Most chips have errata and you use workarounds. Bottom line seems to be that:

• Inputs with external pullups of 10k will work
• Inputs with external pulldowns of less than 8k2 will work
• Driven outputs will work

It means you can't connect high-impedance devices to an input port without going through a buffer but otherwise it seems still a reasonable part to use. They recently updated the E9 text to make it clearer what the issue is, and where it will occur. I agree it's a bit wordy, but the above seems to hold.

They are prone to be very wordy !
I had trouble following what they were trying to say, until I saw the current plots. It's a light regenerative P-FET.

It means inputs with any external pullups will work, they do not need to be 10k.

Yeah, I didn't mean to specify you needed 10k pull-ups - 10k is my go-to standard for a light pull-up on something active-low. Somehow that translated to "you must use 10k" between my brain and the keyboard....

Agreed on the 4K7, in fact that's what I changed my 10k pull-downs to.

Also agreed on the wordiness. But I prefer wordy to overly-laconic, which some data sheets are IMHO.

[PCB.Wiz]

I have to admit, I don't yet properly/fully understand (technically), this fault mechanism.  So I accept, I could easily be badly over-estimating how much of an issue, it really is.

Their very wordy prose does not help
Go straight to the graphs, where it becomes much clearer.

In the past, when there use to be chips (very early CMOS ones, come to mind), that could latch up, if even slightly abused.  I remember (hearing), it caused nothing but problems and annoyances.  Resulting in later chips, boasting that they were 'Latchup free'.

Latchup is more serious, it is a crowbar parasitic SCR that appears across the supply rails. These days, it takes hundreds of mA to trigger it.
I know some alarm companies who insist on power removal watchdogs, as simply firing the reset pin does not recover from all failure modes.

It is NOT so obvious, even if I did more fully understand the fault, when and how, in real life situations.  It would cause a problem/issue.

It only sources current ( < 150uA), so only has an effect on light pulldown cases, that might struggle to counter that 150uA.
i2c, N-MOSFET, NPN transistor and even a PNP emitter follower can drive the pin low ok.

eg someone may have designed a keypad matrix with (high) 10k ESD resistors, what would work on a CMOS input but not work here, without a value change, to lower the sum < 8k2.

[MK14]

[[Very nice post - Click above to see]]

Thanks!
That was VERY helpful.

Now you mention it, I remember it better now.  Yes, the CMOS latch-up, would (attempt to) overheat, to destruction, the chip, if the power supply, and perhaps other factors would let it.

It only sources current ( < 150uA), so only has an effect on light pulldown cases, that might struggle to counter that 150uA.
i2c, N-MOSFET, NPN transistor and even a PNP emitter follower can drive the pin low ok.

That makes me feel a lot better about it, and helps a lot with my understand of the problem, as well.   

I've also realized, most (maybe heading towards all), other MCUs, also have one or more typical issues, even if they are working and designed, 100% perfectly in every way.

Which is, that (current technology, as well as many technologies in the past), doesn't handle floating inputs, at around half the supply voltage, well/perfectly.  As it tends to make both the top and bottom FETs conduct at the same time (shoot-through).
At best it can just cause excessive power consumption, of perhaps a few milliamps (extra), instead of microamps or less, at other voltage levels.

But at its worst, it may be able to cause unintended functional changes (off-hand, I'm not 100% sure).

With the 'big' (full) Raspberry Pi's, there have been various, 'first release version', faults/bugs/issues, in many cases.

Such as (IIRC) USB-C power-adapter incompatibilities, with ones (power adapters) from high end phones.

One which had a light sensitive chip (as it didn't have any covering), which had some effect(s).  I think EEVblog, did a video about it.  I can't remember, quickly, what issue(s) it caused.

Early edition Pico's, had error(s), or missing, floating point, built in ROM libraries (missing floating point doubles library?).

[brucehoult]

It is NOT so obvious, even if I did more fully understand the fault, when and how, in real life situations.  It would cause a problem/issue.

Well, for example if you wire a switch/button from the input pin to Vcc, and use either internal pull-down or a weak external pull-down to make a lo input when the switch is open.

If you put a 2nd resistor in series with the switch. comparable to the pull-down resistor, and take the input from the junction of the two resistors, then you won't be pulling the input hi hard enough to make it latch up. Anything from maybe 40% to 80% of Vcc should be fine.

[MK14]

It is NOT so obvious, even if I did more fully understand the fault, when and how, in real life situations.  It would cause a problem/issue.

Well, for example if you wire a switch/button from the input pin to Vcc, and use either internal pull-down or a weak external pull-down to make a lo input when the switch is open.

If you put a 2nd resistor in series with the switch. comparable to the pull-down resistor, and take the input from the junction of the two resistors, then you won't be pulling the input hi hard enough to make it latch up. Anything from maybe 40% to 80% of Vcc should be fine.

Thanks, that has improved my understanding of the situation a lot.  I didn't realize, that this issue, varied at various voltage levels, between 0 and 3.3 V.  Partly because of lack of time spent in my studying of the issue and partly because the information available, is not that easy to understand.

EDIT: Complete rewrite of post, previous one was too long, and had unnecessary details.

[MK14]

Quick Update, on Errata E9:

Some seem to be saying, that they are determining, if it can be sorted, by a quick fix (just the metal layers?), or will take major reworking.

Which will affect, how long it takes to create and roll out, fixed chips.  Estimates (if it is a big fix), seem to go as high as 2 years.  Presumably because of the time to redesign, check, new masks etc, then go through all the chip producing and packaging stages.  Then eventually reaching the shelves, again.
Not to mention, enormous costs as well.

There is also, lots of bickering, as to how often, this problem will occur in practice, and how easy, it is to fix.  Especially with some designs/needs, being sensitive to the 120 microamps of input current, pulling it towards about 2 volts, in some circumstances.  E.g. unbuffered analogue circuitry.
Also, concerns about it leading to too high current consumption, due to all the stronger pulldown resistors (where needed), wasting power, if running on small batteries.

EDIT: Information based on reading various forum and similar posts.  So not 100% confirmed.  But, I find it interesting, until we get later official announcements, about what is going to happen.

[PCB.Wiz]

There is also, lots of bickering, as to how often, this problem will occur in practice, and how easy, it is to fix.  Especially with some designs/needs, being sensitive to the 120 microamps of input current, pulling it towards about 2 volts, in some circumstances.  E.g. unbuffered analogue circuitry.
Also, concerns about it leading to too high current consumption, due to all the stronger pulldown resistors (where needed), wasting power, if running on small batteries.

It does not pull toward 2 volts.
 Think of it as half a pin keeper, that can only pull up, when above the threshold.
Once pulled down, to below the threshold there is no current adder.

[MK14]

There is also, lots of bickering, as to how often, this problem will occur in practice, and how easy, it is to fix.  Especially with some designs/needs, being sensitive to the 120 microamps of input current, pulling it towards about 2 volts, in some circumstances.  E.g. unbuffered analogue circuitry.
Also, concerns about it leading to too high current consumption, due to all the stronger pulldown resistors (where needed), wasting power, if running on small batteries.

It does not pull toward 2 volts.
 Think of it as half a pin keeper, that can only pull up, when above the threshold.
Once pulled down, to below the threshold there is no current adder.

Well, the following thread, with details of practical examples, and a number of oscilloscope traces.  Doesn't seem to fully agree with what you just seemed to say at a quick glance (or a much longer one, as I try and digest, all this information, and summarize it).

I wish I had one (or some) now, so I could play around with the I/O and find out.  Because, they are very interesting (at least to me), even just as a somewhat powerful (for the money), MCU, as long as you don't try and do too much with the inputs, as regards errata E9.

EDIT:  Sorry, here it is:
https://community.element14.com/products/raspberry-pi/f/forum/55046/rp2350-gpio-pull-down-latching-bug/223658

EDIT2:  If anyone hasn't got the time or interest to look at that thread, my quick summary, is:
When the input(s), are setup in such a way, that they can exhibit the bug/fault.  Sweeping the input, across its range, via a 10k resistor, and watching it with an oscilloscope, seem to show it at certain voltages, to varying extents, sourcing or sinking currents, when it SHOULD NOT be, in a worrying manner, not fully described by the errata E9, at around or before, the time they made their post.

[newbrain]

to varying extents, sourcing or sinking currents

I do not see any current sinking. In the scope traces, the voltage is always above the sine, indicating that the pin is sourcing current into the generator, never the opposite.

[MK14]

to varying extents, sourcing or sinking currents

I do not see any current sinking. In the scope traces, the voltage is always above the sine, indicating that the pin is sourcing current into the generator, never the opposite.

If you look at the picture (from the thread I linked to), in the middle of the picture, the sine wave, seems to be (suddenly, at perhaps 1.5 V) dragged down (i.e. the input would be sinking current).

EDIT:  Also, on reflection.  It is suddenly dropping by around 1 centimeter (crude monitor screen measurement/estimate), which is about a volt, so for a 10k ohm resistor, should represent a current change of around 100 microamps, which sounds about right.  I presume, it is caused by the hysteresis mechanism coming into play (switching states) or something like that.

[MK14]

I've changed my mind.  Maybe you were right.
Perhaps what I'm seeing, is the input suddenly, pulling 100 microamps, LESS source current.  Confusing me.

[newbrain]

seems to be (suddenly, at perhaps 1.5 V) dragged down (i.e. the input would be sinking current).

Still, it does not go anywhere under what the sine should have been, as the crude picture I put together shows.
So, no sinking.

I've changed my mind.  Maybe you were right.
Perhaps what I'm seeing, is the input suddenly, pulling 100 microamps, LESS source current.  Confusing me.

Great! but I made the picture, so here's the post nonetheless 

[MK14]

seems to be (suddenly, at perhaps 1.5 V) dragged down (i.e. the input would be sinking current).

Still, it does not go anywhere under what the sine should have been, as the crude picture I put together shows.
So, no sinking.

(Attachment Link)

I've changed my mind.  Maybe you were right.
Perhaps what I'm seeing, is the input suddenly, pulling 100 microamps, LESS source current.  Confusing me.

Great! but I made the picture, so here's the post nonetheless 

That trace (picture), was EXACTLY! what I wanted.

Ideally I'd have set a scope (none of these scope traces were done by me), to capture both the unaffected sine wave and the messed around one, and then show both on the screen (by storing and recalling one trace), to better see what is really going on.

[MK14]

There is also, lots of bickering, as to how often, this problem will occur in practice, and how easy, it is to fix.  Especially with some designs/needs, being sensitive to the 120 microamps of input current, pulling it towards about 2 volts, in some circumstances.  E.g. unbuffered analogue circuitry.
Also, concerns about it leading to too high current consumption, due to all the stronger pulldown resistors (where needed), wasting power, if running on small batteries.

It does not pull toward 2 volts.
 Think of it as half a pin keeper, that can only pull up, when above the threshold.
Once pulled down, to below the threshold there is no current adder.

Sorry, you were right, that is what it looks like.

Remark(s) by people in the other thread, and the way, some of the oscilloscope trace(s) look, confused me.

That misshapen  sine wave, seems to have a number of defects/distortions applied to it.  Which at a quick and simple (initial) glance, makes it look like various/funny sourcing and sinking of current, at various points, taking place.

I now stand corrected, by yourself, Newbrain (and me, as I eventually noticed myself, as well).

[tszaboo]

Anyway, I suggest changing the topic title from "now has extra RISC-V cores" to "now has extra Errata issues".

[MK14]

Anyway, I suggest changing the topic title from "now has extra RISC-V cores" to "now has extra Errata issues".

I've been wondering, what smart and clever, nifty external circuits, could be built.  Without utilizing its CPUs or inbuilt feature set.  Just by utilizing, the input(s) set to their problematic mode, then putting some passive(s) around it, to exploit its voltage/current characteristics, to make things.

Maybe the latching effect, would make a nice monostable timer.

Perhaps a comparator, related circuit, with one of its pins, preconnected internally to 1.5 V to 2.2 V.

A bit like the old radio circuits, in some electronics magazines, that could reportedly been made from the first generation ('A'), of 4000 series CMOS logic gates (hex inverters, or maybe it was (6) straight, non-inverting buffers?, IIRC).

Until the later, 'improved' B series, with an (IIRC) extra internal transistor (per logic device/gate/inverter), and (not sure if the following also affected it, IIRC) improved EMC (static) protection, stopped it from working, viably, as the gain effect capability, almost completely disappeared.