Raspberry Pi RP2350 A4 update fixes old bugs and dares you to break it again The Raspberry Pi team has released an update to the RP2350 microcontroller with bug fixes, hardening, and a GPIO tweak that will delight retro hardware enthusiasts. The A4 stepping brings several improvements, including remedies for the glitches identified in the company's 2024 hacking challenge (though a spokesperson was …
I've got a few projects already on the go which I was planning to stick into 5V systems, I'd be happy to use them myself "as-is" but would have wanted to include level shifters if I was going to open source them, now I don't need to bother and they'll be even easier to implement, just needs a transposer board to get the pin outs right
You need to temper the "Five Volt Tolerant" joy, as it does not mean you can simply hook up 5v signals to the logic pins. See "New RP235X silicon released" over at the Pico/General forum https://forums.raspberrypi.com/viewtopic.php?t=390423. the commend by "hippy" which clarifies:
<quote>
"I do wish Eben would refrain from using that term when the RP235X silicon doesn't meet the capabilities that term invariably conjures up; mainly that you can arbitrarily connect GPIO (FT) pins to any notional 5V signal, job done, nothing to worry about.
It's not "5V tolerant" as I, and I believe others, would take that to mean. It will only "tolerate 5V under specific circumstances".
At least the datasheet doesn't say "5V tolerant" anywhere, more correctly IMO says GPIO (FT) pins "will tolerate voltages up to 5.5 V, provided IOVDD is powered to 3.3 V".
<end quote>
So this is a pay careful attention to the datasheet on just what is meant by the improved 5v handling on the new pico. I was a bit surprised too.
Also 5V 74LS TTL actually works well with 3.3V logic and not with 5V 74HC series, or 4000 series at 5V, because logic 1 is actually about 2.7V!
Still, flexibility is good. I had an early Pi and gave it away. I bought a cheap Pi4B, though it's very limited in RAM for Linux, it can just about run Firefox, LO Writer and Calibre (with only one or two tabs on Firefox). If I'd been wanting to use it seriously the 5 was then available, or a 4 with twice the RAM.
The A4 stepping brings several improvements, including remedies for the glitches identified in the company's 2024 hacking challenge (though a spokesperson was quick to note they all required physical access to the hardware)
To me that sounds like company can't be arsed to hire proper talent and instead look for mugs to do R&D work for some beads.
No wonder there were so many bugs in the first place.
Why the downvotes?
If you condone such behaviour then imagine in the future a hospital announces a "Surgery Jam" where anyone with a scalpel can come in and try fixing patients.
"If you discover how not to kill them, you win a day's wage!"
Meanwhile, the hospital’s board pats itself on the back for “community involvement” - all while refusing to invest in actual surgeons.
That’s what this is.
Companies no longer want to hire talent - they just dangle some bling and let desperate devs do unpaid R&D in their spare time.
Bug bounties are a symptom of corporate rot.
Companies slash budgets for engineers and QA, ship barely-tested products, then hand out peanuts to the few clever mugs who find the landmines after release.
It’s outsourcing R&D to hobbyists so the execs can buy another yacht.
Defcon? That’s a grassroots event.
This? A close to billion pound company.
Because no silicon was ever released with bugs ever before Raspberry Pi launched their RP2350..
Pi foundation made it public, owned the flaws, worked to fix it, announced revised silicon and data, that's pretty much the dream for people who do embedded, an awful lot of silicon never gets fixed if the manufacturers even admit there are flaws.
That’s the dream?
If your dream is “they admitted it and eventually fixed it”, then we’ve truly hit rock bottom.
We’ve normalised the idea that flawed silicon is just fine - as long as the company admits it later, throws a new revision out the door…
…and organises a hackathon so the unpaid masses can help test it.
I hate to break it to you but there have been bugs and flaws in silicon forever, the 6502 has several and so does the Intel 4004 so it's far from a new problem.
There are also plenty of cases where bugs are known but not admitted to unless you happen to stumble over them with "fixes" and work rounds being available from FAEs, even then some are under NDA (yes, I've been subject to a few) so, yeah, a company that openly admits its mistakes, documents them and actually fixes them is kinda nice to have.
Yes, the 6502 had bugs - it was 1975, built on a shoestring without modern tooling. But here’s the difference: they didn’t run hackathons to fix them. They hired engineers. They respected engineers.
Same with Intel in the early days.
The 4004 wasn’t flawless, but Intel didn’t crowdsource silicon validation. They built internal teams, owned the risk, and treated chip design as serious engineering - not a game where you shake the treat bag and hope some eager dev rolls over and finds your flaws.
So when a modern company ships flawed silicon, launches a public “challenge” to finish validating it, and then praises itself for transparency - no, that’s not “nice to have.”
That’s normalising decay.
And let’s not pretend this is some bloke in a shed asking mates for help with his "chip".
This is a nearly £900 million company choosing to act like it’s broke - because they know engineers will still show up, tails wagging.
Well, again, I hate to be the one who breaks your wished for cosy little world of imagined fairytale perfection, but there are still bugs in the modern iterations of the 65C02 and "bug bounties" as well as "hacking competitions" have existed in one form or another for many centuries if not actually millennia.
Anyway, try not to let your hatred of flawed silicon eat you from the inside out and have a nice day.
"Yes, the 6502 had bugs - it was 1975, built on a shoestring without modern tooling. But here’s the difference: they didn’t run hackathons to fix them. They hired engineers."
The truth is the NMOS 6502 was never actually fixed. Some might have been, but some might do different weird things with unknown opcodes - remember, more than one company made the 6502.
A lot of the oddities were fixed in the 65C02 which was some seven years later and an entirely different company, though the JSR address bug was never fixed, it's just assumed that "that's how it works". Helps keep things more compatible that way.
Yes, the 6502 had bugs - it was 1975, built on a shoestring without modern tooling. But here’s the difference: they didn’t run hackathons to fix them. They hired engineers. They respected engineers.
Eh? The 6502 had bugs... they got found when it was released... the engineers didn't do a good enough job (by your standards) but it was the 70s and they were heroes so it's okay?
Also, lets be real here, it wasn't built 'on a shoestring' by some enterprising heroes, it was build by some ex Motarola engineers who chose to leave their employment and set up on their own; the circumstances and finances were entirely in their control. They should've had more money and hired better engineers too.
Same with Intel in the early days.
The 4004 wasn’t flawless, but Intel didn’t crowdsource silicon validation. They built internal teams, owned the risk, and treated chip design as serious engineering - not a game where you shake the treat bag and hope some eager dev rolls over and finds your flaws.
Yet the 286. What were these heroic engineers doing with their time? (I won't search the 386 as I assume you think the rot had set in by then... lets not mention FDIV...)
Nowadays a company must release 100% perfect silicon, despite it being an order of magnetude more complex, and the only reason they don't is "corporate greed"? What a load of shit.
One day you might grow up and work in the world, I hope when you do the first time you ever make a mistake you're immediatly fired and barred from working in the industry again, as by your own admissions imperfections aren't a thing, you were just being lazy, or greedy.
To put it bluntly... spinning a chip revision takes 3 months... there's a point that you consider it 'good enough' and ship it.
Personaly, I admire what the Raspberry Pi people are doing. At the end of the day... you don't have to expend any of your own effort if you don't want to, but the end result is still a better, more secure chip, that will be used in a shitload of stuff. That's a good thing surely?
I was very disappointed that the GPIO problem was missed in design and testing. Apparently due to a design change since they have been doing GPIO pins without this problem for many years now. My biggest concern was that after that design change testing clearly fell short. That said I have seen multiple Errata sheets for fairly complex to very complex microcontrollers from every major manufacturer that run for several pages. So while it was disappointing it was not without ample precedent. It took a little nudging but they did own up to it and help find workarounds that were easy and only slightly annoying to implement. This fix finally allows me to proceed with a delayed project that has already gone through more than one design iteration using different processor(s) that were really overkill for the project even though they did have hardware support for some things that will have to be done in software with the RP2350 (ah, bit/byte diddling what would I do without you). The 5V tolerant GPIO pins gives me some flexibility that I can and will use.
Much of the beta testing was 'outsourced' to the likes of Adafruit, Pimoroni and other maker industry influencers. However, they just took the lazy opportunity to respin their RP2040-based products and didn't do any 'testing' as we'd understand the term. Hence the GPIO bug lay undiscovered. Of course it shouldn't have happened in the first place. The GPIO silicon is 3rd party IP that was bought-in to an RPi specification. That's by no means unusual; so are the UART, SPI and I2C peripherals, as well as the Arm cores of course. Another reason is that very few people in the maker world use pulldowns, mainly because earlier MCUs only had open-drain inputs, so we're only used to inverse logic, i.e. pull-up to +V and short to ground to signal some action.
Beware the 5V tolerance claim. It only works if the chip itself is powered. If you attach a 5V signal to an unpowered chip it'll fry the pad. Upton mentions this in the blog post, but it's particularly challenging for consumer-focused products where you can't control what non-technical users will do. It may need some power sequencing. Again, not surprising but it will catch out a few people who only read the simple message.
This is a ridiculous argument. They can rely on the security hacking efforts of their internal engineers or they can expand the exposure to the entire world. Which would be the most effective? Which would be the closest to the real world?
Even a giant organisation like Intel couldn't economically maintain a team of the very best security hackers from every institution around the world. The Raspberry Pi strategy makes total sense and the outcome is a robust device and useful contributions to the next devices they create.
Hands up anyone who knows how modern chip design and testing is done!
Not you elsergiovolador.
You really are showing a lack of knowledge of the domain here. Have you actually read the hacking challenge results and seen what was done to "hack" the original RP2350? It's pretty heavy duty stuff. In the same way that software, despite much testing, still has vulnerabilities, so does hardware. Hackers are clever people, especially the ones who figure out all these glitching attacks. And they also have lots of time to target very specific areas. If companies had as much time to do the same over the whole chip, they would do it, but it would take 20 years to get product out of the door and instead of 90cents, the RP2350 would cost $50. As a company, you simply cannot think of everything, or get it perfectly right all the time, and timescales limit the total testing possible. The RP2350 was designed and tested by very experienced people and went through a year of testing.
Meanwhile Intel had severe reliability issues on high-powered 13 and 14th gen Core CPUs, and many software glitches and bugs in Gigabyte, ASUS, etc. products even for recent products.
No company is good, and at least Raspberry holds competitions to find them versus relying on a third party to find an exploit and email it to them.
So, going back to your analogy: while everyone else is finding random issues and complications with various surgeons' handiworks but only long-term, one hospital effectively decided to study differing techniques of their surgeons to discover flaws in their practice, so that in the future these mistakes are rectified.
Unless you want a surgeon who runs a procedure without stress-testing it in a controlled environment, I'd stick to liking but bounty programs and hackathons.
The downvotes are because you clearly have no idea. Everything has bugs. Doesn't matter how many engineers you hire, there will be something that seeps through. This applies to both hardware and software; sometimes a hardware bug can be bypassed through software but not always.
Raspberry Pi started with a team from Broadcom. They know a thing or two about chips. But also Eben & Liz Upton literally had to remortgage their house to launch the first Pi... would you put that level of commitment to a product if you didn't have faith in the team? (They nearly got screwed with the first batch as well - the manufacturing plant took it on themselves to replace the specified RJ45 socket with a cheaper one that didn't have isolation, which meant the networking didn't work)
We're not talking about a school project with obvious bugs; we're talking about highly skilled engineers with a lot at stake. The only difference is that they're open about the development process, which is a refreshing thing to see.
The hacker community have a lot of ingenious minds and they enjoy trying to break things. Why wouldn't you run things past them if you want to find any bugs which you may have missed?
You're so right, because performing surgery on patients is EXACTLY like searching for bugs in a piece of hardware or software. The parallels just leap out at you.
Surgeons haven't yet figured out the correct way to do an appendectomy, remove a tumour, fix an undescended testicle or perform a c-section, so they've been inviting "surgery-curious" people off the street to find better ways. It's been largely successful, with people learning how to do things like cataract removal with a fork, that sort of thing.
> No wonder there were so many bugs in the first place
Care to list out this massive set of bugs you know of? How long is it really? And compared to any other errata (let alone the non-published, shush, we'll get away with it, internal addendum)?
Anything in that list that prevented the device from being useful in the majority of cases?
The GPIO pullup issue is unfortunate, but then some of us were used to having to solder pullups/pulldowns on absolutely everything and view these built-in ones as a bit of a luxury[1] (oh, ok, it adds a couple of pennies to the BOM - IFF your design actually hit it). Actually, I know of a few small run builds - not with the RPi - where the guys were hardware- rather than software-oriented and added all the pullups anyway, as that was easier and more cost-effective from their p.o.v. than worrying if they'd set up the registers properly in their code.[2]
As for the glitching mentioned - you did understand, didn't you, that this is not talking about glitches in the silicon design but is about people introducing glitches in power lines etc from outside the device and feeding those in, with the intent to make it misfire? So operating way outside normal and specifically to see if they could break security features?
The public bounty for breaking security features is a Good Thing - it encourages the participation of some truly devious minds to have a go AND talk openly about what they are doing on the forums.
> company can't be arsed to hire proper talent
And just how do you expect a company to find these talents without setting this kind of challenge? You may find it hard to understand, but some of them actually consider etching off packaging and probing around under the microscope to be a fun hobby.
[1] cue "pullups? You were luck! We had to tie 60V to our toe and stick fingers on the i/o lines"
[2] and yes, their code was very pedestrian and could be "improved" - especially for readability! - but that is the joy of small-run: Done. Out the door. Next.
"No wonder there were so many bugs in the first place."
For anyone who actually wants to know about the bugs rather than just grandstanding, all the known errata are listed in the datasheet, and this also states which have been fixed and which have been mitigated in the A4 stepping. https://datasheets.raspberrypi.com/rp2350/rp2350-datasheet.pdf, appendices C and E. 28 known errata on the A2, 11 full fixes in A3/A4, with a further 6 mitigated, leaving about 11, mostly very obscure but the datasheet has workarounds.
I believe it is still going to output at most 3.3V and according to the datasheet Voh(min) is 2.62@3.3V IOVDD. Input voltage can be as much as 5.5V with IOVDD of 3.3. But they do warn not to apply such a thing to a pad if IOVDD is not powered. Looks like all sorts of options to set Vil/Vih thresholds. Should be fine as all the 5V stuff I know of would treat 2.6V as a "1".
Just as the RP2040 was originally (and rather conservatively) specified for 133MHz operation and then later qualified for 200MHz. I wouldn't be surprised if the 2350 gets a 'speed bump' at some point. An intern at RPi got one working at 1GHz although the chip didn't last long !
Geektime...
Well, it's 5V *tolerant*, but only while IOVDD is powered from at least 3.3V. Connect a 5V supply or pull-up to GPIO pins while the power to the RP2350 is off and you run a serious risk of damaging the chip. That can happen so easily and it's not time to throw out the level shifters yet!
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
