Bug in Raspberry Pi RP2350 veroorzaakt probleem met pulldownweerstanden

De RP2350-familie van Raspberry Pi bevat een bug, waardoor pins bleven steken op een output van 2,15V wanneer deze met behulp van de interne pulldownweerstanden als input zijn geconfigureerd, bijvoorbeeld met een fysieke knop.

De fout werd ontdekt door Ian Lesnet van Dangerous Prototypes, schrijft Hackster.io. Het probleem doet zich voor als de VDD-input via de GPIO-pinnen loopt via een pulldownweerstand, bijvoorbeeld wanneer gebruikers een aan- of uitknop via de GPIO-header proberen te koppelen. Als die knop wordt ingedrukt, wordt er verbinding gemaakt met 3,3V. Maar na het loslaten van de knop daalt het voltage niet meer volledig, wat wel de bedoeling is. Deze blijft hangen op 2,15V, ontdekte Lesnet.

Luke Wren, engineer bij Raspberry Pi, zegt dat het probleem veroorzaakt wordt door een analoog circuit op een pad van een externe leverancier. Die leverancier werd gevraagd het zogenaamde fault-tolerantpad aan te passen, maar bij nadere inspectie bleek dat specifieke circuit te zijn vervangen door een heel ander circuit. "Dat was een beetje een blinde vlek voor ons in de simulatie, omdat het meegeleverde simulatiemodel dit probleem niet heeft."

Het probleem raakt alle GPIO-pinnen, zegt Raspberry Pi nu. Aangezien het probleem veroorzaakt wordt door een fout in de hardware van de chip, is er niet direct een oplossing. Het bedrijf adviseert gebruikers om de inputbuffer alleen vlak voor het uitlezen aan te zetten en direct daarna weer uit te zetten. Een andere optie is om inputs te configureren via de interne pullupweerstanden, die geen last hebben van de bug.

De RP2350-microcontroller zit onder meer in de recent aangekondigde Raspberry Pi Pico 2 en die wordt dus ook door het probleem getroffen. Bij de aankondiging zei Raspberry Pi nog niet veel voorraad te hebben van de Pico 2, al was deze al wel in volle productie bij Sony. Inmiddels is de Pico 2 bij een aantal webwinkels al wel op voorraad, maar nog niet overal.

Reacties (29)

[Llopigat]

Ik had het al gelezen ja. Ik hoop dat ze het ontwerp in de komende batches aanpassen. Want dit is best onhandig. Sommige componenten vereisen pulldown. Maargoed je kan het wel extern doen gelukkig.

[Christoxz]

Daar lijkt het niet op, althans niet specifiek voor dit probleem.
RP2350-E9 geeft aan 'gefixt' te zijn door aanvullende documentatie.

Since this is the design flow there is no easy fix for it. The Raspberry Pi team naked it as fixed by documentation and recommends enabling the input buffer immediately before reading, and then re-disable immediately afterwards as a workaround. We could also use the inputs with internal pullup resistors instead of pull-down resistors as a workaround.

[Reactie gewijzigd door Christoxz op 29 augustus 2024 14:02]

[Llopigat]

Meh. Slecht gedaan. Maar gelukkig is er een software workaround.

Ze hadden iets dergelijks met de eerste versie van het Rpi display. Die was extreem fel en door een domme fout in de printplaat kon je hem niet dimmen. De latere versie wel maar je kon ze niet omruilen "want ze hadden nooit gezegd dat hij dimbaar zou zijn".

[Lord Anubis]

thanx. Gelijk de laatste Docs binnen gehaald.

Wel een beetje balen als je 'compatible software' en een 'compatible hat' wil gebruiken die nu ineens gevaarlijk kan zijn.

[Reactie gewijzigd door Lord Anubis op 29 augustus 2024 15:05]

[laurxp]

Het aparte is eigenlijk dat dit nu ineens nieuwswaardig is. Deze erratum stond op de dag van de release al in de datasheet, en was voor mij een belangrijke reden om te wachten met het kopen van een paar bordjes.

Het blijft uiteraard wel bijzonder dat ze de chip met zo'n defect gewoon verkopen, maar echt nieuws is het niet.

[ocf81]

Geen nieuws voor de mensen die de errata van chips opzoeken, maar misschien wel voor degenen die gewoon een Pico2 willen kopen?

[The Zep Man]

Die leverancier werd gevraagd het zogenaamde fault-tolerantpad aan te passen, maar bij nadere inspectie bleek dat specifieke circuit te zijn vervangen door een heel ander circuit. "Dat was een beetje een blinde vlek voor ons in de simulatie, omdat het meegeleverde simulatiemodel dit probleem niet heeft."

Het bleef een blinde vlek omdat het uiteindelijke product niet goed getest is. Dit is niet de eerste keer dat Raspberry Pi steekjes laat vallen:

The irony in all of this is that because of these errors, the Raspberry Pi team has unwittingly made it clear to many that testing hardware isn’t hard, it just has to be done.

Nu moeten ze het alleen nog voor zichzelf duidelijk maken.

Prima als een imperfecte Pi bruikbaar is voor je project. Laat je dan niet tegenhouden. In het verleden heb ik ook eerste revisies gebruikt van verschillende modellen. Zolang je de nukken kent en er rekening mee houdt is er niets aan de hand. Als het wel een probleem is, wacht dan nog even op een nieuwe revisie (in ieder geval voor productie) die dit probleem oplost.

[Reactie gewijzigd door The Zep Man op 29 augustus 2024 13:10]

[jopiek]

In theorie is alles relatief makkelijk, zeker als je uit de software wereld komt waar foutjes met een nieuwe release oid eenvoudig te herstellen zijn.

Hardware ontwikkelen is gewoon moeilijk. Hoe zit het met jullie HDL ervaring @The Zep Man en @MneoreJ ? En hoe veel ARM / Risc-V / whatever chips hebben jullie al ontworpen?!

Als een groot chip bedrijf als ST/Microchip/NXP/Renesas/Infineon/whatever dit nou overkomt, maar een klein partijtje zoals Raspberry Pi... Het was ooit allemaal bedoeld voor het onderwijs, dat de industrie er toen door allerlei op zich legitieme redenen mee aan de haal gegaan is is voor het onderwijs nog steeds een beetje dubbel.

On-topic: Uiteraard gaan ze dit t.z.t. oplossen en tot die tijd is het geen groot probleem. Immers kan men als eindgebruiker er prima om heen werken. Oudere microcontrollers hadden niet eens interne pull-ups en pull-downs, de atmega328 (u weet wel van de Arduino UNO) alleen maar pull-ups. Dus ofwel extern regelen met een 10k weerstandje oid of alleen de pull-up gebruiken.

[Reactie gewijzigd door jopiek op 29 augustus 2024 13:31]

[Hans1990]

In princiepe kan je veel accuraat simuleren (incl layout, bond wire enz), maar zoals in dit geval blijkt moet je dat wel doen. Iets met aannames en murphy's law..

Maar in other news: eigenlijk elke hardware heeft tegenwoordig wel silicon bugs. Sommige minder erg dan anderen natuurlijk, bijvoorbeeld dat er X aantal klok cycles tussen bepaalde register acties moet zitten (makkelijke fix). Andere problemen zijn iets erger waarbij de datasheet zegt: deze chip family heeft USB, dus je denkt: oh leuk, ik kan precies een LQFP-64 package kwijt op mijn bord. Vervolgens lees je de errata die zegt: USB werkt niet bij de 64-pin packages.

Het is dus tegenwoordig standaard kost om voor het uitkiezen van een gewenste chip ook die errata sheet door te pluizen. Fabrikanten verzuimen het vaak om hun "brochures"(datasheets) aan te passen..

In dat opzicht is het weinig bijzonder dat op MCU chip van RPi iets mis zit. Ik had een decap video gezien van de RP2350 en ik meen dat ze de eerste chiprevisie al in productie hadden gebracht.

Het is allemaal nog niets in vergelijking met wat Microchip 10 jaar terug deed met de PIC32MZxxEC serie. Die chip was aangekondigd met HS USB, 100Mbit Ethernet, 12-bit 10MSPS+ ADC, enzovoort. Uiteindelijk bleek daar bijna niets goed van te werken. Zelfs de externe crystal/oscillator was niet functioneel.. dus hoe ze zo'n chip de deur uit hebben gestuurd gaat mijn pet te boven, want zonder goede klokref kan je vrij weinig beginnen. Die serie is toen snel EOL gemaakt en vervangen met de EF serie, met dikke koeienletters op de productpaginas: "zie AUB de EF serie".

[Reactie gewijzigd door Hans1990 op 29 augustus 2024 14:01]

[styno]

Elke microcontroller, ook die van de grote partijen zoals STM, TI, NXP etc. hebben bugs die meestal maar niet altijd vermeld zijn in de documentatie (errata). Sommige van die bugs hebben dan een workaround maar er zijn ook zat waardoor bepaalde functies niet of gereduceerd bruikbaar zijn. Is ook niet raar als je ziet hoe complex sommige peripherals zijn (zo ontzettend veel combinaties van instellingen mogelijk). Maar van dit kaliber, waarbij basis I/O functionaliteit niet werkt, is zeldzaam.

[MneoreJ]

Inderdaad een beetje een bizarre reactie. "Ja dit konden we niet weten want het zat niet in de simulatie". Ik snap dat het bord volledig doorlichten ook best een uitdaging kan zijn en je kunt niet alle use cases afvangen op die manier, maar het ging hier nota bene om een component waar een verandering voor gevraagd was. Dan check je toch even of het eindresultaat nog enige binding heeft met je simulatie, wat is dat nou. Het is niet alsof dit een of andere onwaarschijnlijke use case is.

[grobbel]

Was het probleem niet iets meer dan 'doet het niet'? Ik meen gelezen te hebben dat de pull down initieel wel werkt, en pas na een trigger op 2v blijft staan. Dat maakt testen best een gedoe lijkt me.

[Sissors]

Als hij nou op 1V was blijven staan, dan was dat erg lastig geweest. Dan had je of een multimeter eraan moeten hangen, of mogelijk in voedingsstroom terug kunnen zien.

Maar wanneer hij op 2V hangt, betekend het gewoon dat hij eerste keer dat hij geactiveerd wordt, ook meteen laatste keer is, en hij nooit kan deactiveren. Dat is natuurlijk niet de meest onmogelijke om te vinden.

[EraYaN]

Nee maar als je dat dan vindt is het te laat dus alles wat je kan doen dan is een workaround opschrijven en het in de datasheet zetten.

[Sissors]

Nou ja, ligt eraan wanneer je het vindt dus. Als ze het op test-silicon vinden kan er gewoon nog een volgende tape-out komen.

[MneoreJ]

Ik struikel meer over het feit dat het product dat ze kregen blijkbaar niet overeen kwam met wat ze ontworpen hadden en opgenomen in de simulatie. Dat alleen al zou een dikke rode vlag hebben moeten zijn die op z'n minst grondiger testen had moeten triggeren.

En testen is inderdaad best een gedoe, dus ik snap wel dat ze daar liever op besparen na de smoke test... maar dat is natuurlijk geen goed excuus.

[B_FORCE]

Het is in dezelfde trend als "ik heb er geen actieve herinnering aan".

Meest schokkende is dat mensen en bedrijven ermee wegkomen.


Sorry, maar ik geloof er in dit geval geen ene bal van.
Een pull-down situatie zoals hier beschreven is toch een van de meest simpele en basale use cases.

Zal nog zeer lastige situaties opleveren wanneer een bedrijf een paar duizend van deze dingen in order heeft staan.
Voor zoiets simpels zou ik als engineer en dus als bedrijf alles behalve blij zijn.
Dat is nogal een understatement om het netjes te formuleren.

[EraYaN]

Ieder bedrijf dat embedded hardware maakt is hier al lang aan gewend. Dit is nou eenmaal hoe IC design werkt. Er zijn altijd wel wat bugs, sommige erger dan andere. Daarom zetten ze die ook netjes in de datasheets.

[Lord Anubis]

De significante discrepantie tussen het ontvangen product en het oorspronkelijk ontworpen en gesimuleerde ontwerp is uiterst zorgwekkend en had als een kritieke indicator moeten worden beschouwd, wat had moeten resulteren in uitgebreide en grondige testprocedures.

Het toeleveringsbedrijf schiet hier tevens tekort door een simulatie aan te leveren die niet overeenkomt met de geleverde hardware, wat onacceptabel is.

Hoewel het begrijpelijk is dat het testen na de initiële test als omslachtig en tijdrovend kan worden ervaren, biedt dit in deze context geen rechtvaardiging om de testactiviteiten te verminderen.

Maar ja, we zijn mensen en als we denken dat het goed is en werkt dan zal het wel werken.

Ik had wat RP2350 en Pico's in bestelling staan, maar gelukkig kunnen annuleren. Je zou er denk ik wel omheen kunnen werken, maar vereist extra HW.

[Reactie gewijzigd door Lord Anubis op 29 augustus 2024 13:52]

[EraYaN]

De extra hardware is een R in deze voldoende voor een externe pulldown of een andere netlist (pull up werkt gewoon). Allemaal niet zo spannend, soms werkt een hele peripheral niet in een bepaald package bijvoorbeeld.

[Lord Anubis]

Voorlopig kan ik nog met een rp2040 overweg, maar wacht voor deze even af. Zit geen tijdspanne aan. Was eigenlijk ook te voorbarig om ze te bestellen.

Tuurlijk is het niet spannend, maar om een pcb/ontwerp aan te passen met de gedachte dat ik nu met deze chips werk en later er andere zijn lijkt me niet handig. Ik heb diverse keren via jlc printjes laten maken en bestukken en ik kan niet op hun onderdelen database 100% vertrouwen dan ik dan ooit de juiste rp versie ga krijgen die dan met mijn extra 0ohm, geen of 1k (noem maar wat ) weerstand er naast heb zitten.

Weet trouwens niet eens op ik 9 weerstandjes er nog op krijg. En dubbelzijdig bestukken ziet mijn portemonnee niet zitten.

[imqqmi]

Het komt vaker voor helaas. Voor alle MCUs geldt dat je de errata documentatie goed in de gaten moet houden voordat je een keuze maakt om deze te gebruiken. En omdat dat meestal voor nieuwe MCUs niet aanwezig is kun je het beste tried and tested MCUs gebruiken en moet je nieuwe zien als 'beta test'.

Zo had ik een PIC mcu gekozen dat meerdere kanalen zou moeten hebben voor de ADC echter in de praktijk bleek dit niet te werken, even in de errata documentatie kijken en bij de revisie van de MCU die ik had was inderdaad een probleem met ADC kanalen.

Nu vind ik een pull down resistor fout niet het einde van de wereld als de pull up wel werkt. Slordig is het wel. Hopelijk is dat in een revisie opgelost.

[jeroenathome]

Is het niet mogelijk om dit met een externe pull-down weerstand op te lossen?

Is geen mooie oplossing, maar naar mijn inziens werkt dit wel.

[Sir.roYa]

Ja dat lijkt mij wel, alleen het geschreven artikel verwijst hier naar een interne pullup weerstand waar ze volgens mij op hetzelfde doelen.

[laurxp]

Afhankelijk van de toepassing. Werkt voor sommige toepassingen prima, maar er zijn ook signalen waar je de pull-down dynamisch aan en uit wil zetten. Dat gaat met een externe pull-down een stukje lastiger - dan is een software workaround waarschijnlijk een betere optie.

[Ryen]

Voor de duidelijkheid; het gat hier om de RP pico microcontrollers. Heel andere beestjes dan de bekendere Pi single board computertjes.

[justinkb]

ben benieuwd hoe lang het duurt tot de A0-A2 stepping stock op is... wilde een paar van deze bestellen, maar daar wacht ik nu maar even mee

[laurxp]

De bug lijkt trouwens serieuzer te zijn dan de E9-erratum zegt. Zie bijvoorbeeld dit Github issue, waarbij een input pin óók vast blijft hangen na een hoge input als er helemaal geen gebruikt wordt gemaakt van pullup/pulldown weerstanden - en zelfs een (zwakke) externe pulldown niet werkt. Het lijkt de inputs ook onbruikbaar te maken voor sommige analoge toepassingen.

In essentie heb je, als je toepassing pulldowns nodig heeft, dus altijd een externe pulldown van 9kΩ of sterker nodig - en het is niet iets waar je met software omheen kan werken! Dat is voor veel toepassingen een serieuze dealbreaker.

[Reactie gewijzigd door laurxp op 30 augustus 2024 00:51]

[as400]

Ik vrees dat je gelijk hebt :

The official statement by Raspberry Pi is still that ‘they are investigating’. Presumably there will be a Bx stepping at some point, but for now it is clear that the RP2350’s A2 stepping is probably best avoided.

https://hackaday.com/2024...350-e9-erratum-situation/