Der neue Prozessor RP2350 im Pico2 hat einen Fehler (RP2350-E9 im
Datenblatt)
https://hackaday.com/2024/08/28/hardware-bug-in-raspberry-pis-rp2350-causes-faulty-pull-down-behavior/
The newly released RP2350 microcontroller has a confirmed new bug in the
current A2 stepping, affecting GPIO pull-down behavior. Listed in the
Raspberry Pi RP2350 datasheet as errata RP2350-E9, it involves a
situation where a GPIO pin is configured as a pull-down with input
buffer enabled. After this pin is then driven to Vdd (e.g. 3.3V) and
then disconnected, it will stay at around 2.1 – 2.2 V for a Vdd of 3.3V.
This issue was discovered by [Ian Lesnet] of [Dangerous Prototypes]
while working on an early hardware design using this MCU
Laut Fehlerbeschreibung sind Eingänge mit Pull-Down betroffen. Ich habs
ausprobieert und bei mir tritt der Fehler auch auf wenn kein Pull-Down
aktiviert ist. Wenn man das angehängte Programm laufen lässt und dann
den Pin kurz mit Plus verbindet bleibt der Eingang, wie bei der
Fehlerbeschreibung gesagt, bei ca. 2.2V hängen. Verbindet man den
Eingang dann niederohmig (kleiner 1k) mit GND kann man den Eingang
zurückholen.
Kann jemand das mal nachprüfen und überprüfen ob ich irrtümlich doch
einen Pull-Down aktiviert habe?
Martin O. schrieb:> und bei mir tritt der Fehler auch auf wenn kein Pull-Down> aktiviert ist.
Isso! E9 ist diesbezüglich unklar.
Kleiner 1kΩ wäre aber nochmals deutlich schlimmer als befürchtet.
Das scheint leider wirklich so übel zu sein.
Ich habe es gerade mal mit ein paar Zeilen Micropython getestet: einmal
einen Eingang mit dem internen pull-up aktiviert bekomme ich ihn mit dem
pull-down nicht wieder auf 0, auch nicht wenn ich länger warte.
Martin O. schrieb:> Verbindet man den> Eingang dann niederohmig (kleiner 1k) mit GND kann man den Eingang> zurückholen.
Bei meinem Pico2 muss ich nicht so niederohmig ran. Mit einem 10k
Widerstand zwischen einem Aus-und einem Eingang erhalte ich am Eingang
immer den erwarteten Wert, auch dann, wenn ich den Eingang zwischenduch
hart auf 3,3V lege.
Gibt es angesichts dieser nicht gerade unerheblichen Bugs (wurde der ADC
des RP2040 verbessert?) eigentlich überhaupt einen objektiven Grund,
sich privat mit diesen RP-MCUs auseinanderzusetzen, anstatt z.B. mit
STM32? Also wenn der Preisunterschied nicht die große Rolle spielt.
Ich habe es einmal mit einem 30k Widerstand zwischen GPIO 0 als Ausgang
und GPIO 3 als Eingang getestet und einmal mit einem 10k Widerstand und
die Spannung an GPIO 3 mit einem Einfachstoszilloskop aufgezeichnet.
1
from machine import Pin
2
from time import sleep_us
3
4
po = Pin(0, Pin.OUT, value=0)
5
pi = Pin(3, Pin.IN, pull=None)
6
7
po.on()
8
sleep_us(20)
9
po.off()
10
sleep_us(100)
11
12
Pin(3, Pin.OUT, value=0)
Mit dem 30k Widerstand bleibt GPIO 3 nach dem Herunterschalten des
Ausgangs bei gut 2V hängen bis ich GPIO 3 als Ausgang auf 0 schalte.
Mit dem 10k Widerstand sieht alle normal aus.
Die fallende Flanke will ich mir noch mit einem besseren Oszilloskop
ansehen. Für die Bilder hatte ich des Owon ohne Tastkopf mit etwas
Zwillingslitze an den Pico2 angeschlossen, das reicht nicht für schnelle
Signale.
Johannes Fe schrieb:> Gibt es angesichts dieser nicht gerade unerheblichen Bugs
Also aus sicht eines Hardware-Entwicklers betrifft das Erata ein
"Luxus-feature" wie interne PullUps.
problematisch ist hier eher eine Software, die dies Luxus-Feature
default aktiviert und/oder einen Firmware-Entwickler mindestens mit eine
Warnung auf mögliches Probleme bei Nutzung dieses Features hinweist.
Wenn man den pico auf einem Steckbrett einsetzt steckt man einen
Widerstand dazu und gut ist, baut man ein PCB um den SMD Chip sieht man
pads für den Pull vor und gut ist.
Bradward B. schrieb:> Also aus sicht eines Hardware-Entwicklers betrifft das Erata ein> "Luxus-feature" wie interne PullUps.> problematisch ist hier eher eine Software, die dies Luxus-Feature> default aktiviert und/oder einen Firmware-Entwickler mindestens mit eine> Warnung auf mögliches Probleme bei Nutzung dieses Features hinweist.
Das Problem tritt auch ohne aktivierte interne Pullups oder Pulldowns
auf!
Hochohmige Eingänge sind so ohne weiters kompiziert oder ohne
Zusatzbeschaltung unmöglich. Ich sehe noch keinen Weg wie man sinnvoll
direkt mit einem hochohmigen Signal, das normalerweise high ist und
aktiv low, umgehen soll.
Bradward B. schrieb:> Also aus sicht eines Hardware-Entwicklers betrifft das Erata ein> "Luxus-feature" wie interne PullUps.
Eben nicht und Luxus ist das auch nicht. Probleme gibt es auch ohne
'pullies' und wer weiß, was noch hinzukommt. Selber werde ich um die
RP2350 einen Bogen machen.
Johannes Fe schrieb:> Gibt es angesichts dieser nicht gerade unerheblichen Bugs (wurde der ADC> des RP2040 verbessert?) eigentlich überhaupt einen objektiven Grund,> sich privat mit diesen RP-MCUs auseinanderzusetzen, anstatt z.B. mit> STM32? Also wenn der Preisunterschied nicht die große Rolle spielt.
Etwas hinzuzulernen schadet nie!
Selber haben mir die Teile einen TFT-Controller ermöglicht, während
andere Chip-Hersteller nicht liefern konnten. Die PIOs sind nett, wenn
man sie braucht. Restliche IO-Geschichten sind schlicht und
überschaubar. Brauchbare Timer mit capture-Funktion sind nicht
vorhanden.
Es gibt viel RAM auf dem Chip und viel Flash-ROM, indem das Programm
aber völlig ungeschützt liegt, was sehr negativ sein kann. Da sind
Programme in einem STM32 (o.ä.) oder ATtiny besser vor Fremdkopieren
geschützt und ein AVR hat bezüglich der Genauigkeit einen besseren ADC
als ein RP2040, geringere Stromaufnahme, +++
Ansonsten wird jeder seine eigenen objektiven Gründe haben ;-)
Bradward B. schrieb:> Also aus sicht eines Hardware-Entwicklers betrifft das Erata ein> "Luxus-feature" wie interne PullUps.
So wie ich diesen Thread verstehe, ist ja das Problem nicht, dass dieses
"Luxus-Feature" nicht funktioniere wenn aktiviert, sondern dass es
Probleme mache, auch wenn nicht aktiviert. Somit wäre es kein
Luxusproblem, dass man so einfach mit externem Widerstand umgehen
könnte, zumindest nicht bei hochimpedanten Eingangssignalen.
Mi N. schrieb:> Etwas hinzuzulernen schadet nie!
Ja, das stimmt schon, aber die Frage wäre für mich, ob ich meine Zeit,
die ich zum Lernen ja brauche, dann nicht sinnvoller in STM32
investiere, statt mich mit den Hardware Bugs der RP-MCUs herumärgern zu
müssen – was den Spaß am Lernen für mich persönlich mindern würde. Da
werde ich lieber ein paar Euros mehr für einige (originale)
STM32-Exemplare ausgeben, die dann aber zuverlässig und genau (ADC)
funktionieren. Aber das kann natürlich jeder für sich selbst
entscheiden.
>> Also aus sicht eines Hardware-Entwicklers betrifft das Erata ein>> "Luxus-feature" wie interne PullUps.>> problematisch ist hier eher eine Software, die dies Luxus-Feature>> default aktiviert und/oder einen Firmware-Entwickler mindestens mit eine>> Warnung auf mögliches Probleme bei Nutzung dieses Features hinweist.>> Das Problem tritt auch ohne aktivierte interne Pullups oder Pulldowns> auf!
Das kannst du sicher mit einem link auf das entspreche3nde Erata
belegen.
Die ich so weit kenne, beschreiben immer eine Situation bei der die
internen Pulls zumindest in der Historie schon mal enabled waren.
> Hochohmige Eingänge sind so ohne weiters kompiziert oder ohne> Zusatzbeschaltung unmöglich.
??? die Inputs sind ohnehin hochohmig, Was du meinst ist tristate-Stufe
und das sind sinnvollerweise Outputs. Wenn einem der widerstand am Input
zu gering ist dann erhöht man den ohnehin nicht über einen Pull sondern
über einen serien- (auch Brems-widerstand genannt) Widerstand.
> Ich sehe noch keinen Weg wie man sinnvoll> direkt mit einem hochohmigen Signal, das normalerweise high ist und> aktiv low, umgehen soll.
Indem man einen externen Pull einbaut. Und das der Pico ublicherweise
auf Steckbretter aufsteckbar ist, ist das auch kein problem.
Und dann wäre noch die Frage, ob man diese auch hochohmigen Signale
überhaupt im Design hat und ob man diese mit einem GPIO und nicht mit
einem dediziert dafür entworfenen Peripheral (bspw. integrierten
I²C-Slave) bedient.
> So wie ich diesen Thread verstehe, ist ja das Problem nicht, dass dieses> "Luxus-Feature" nicht funktioniere wenn aktiviert, sondern dass es> Probleme mache, auch wenn nicht aktiviert.
Nun ich habe die Erfahrung gemacht, das die threads in diesem Forum zu
einem nicht unerheblichen Teil subjektive und falsche Informationen
enthalten.
Die Darstellung des problems im Erata nennt jedenfalls für die
Reproduktion des Fehlers zumindest historisch aktive Pulls an einem als
Input betriebenen GPIO.
Bradward B. schrieb:> Die Darstellung des problems im Erata nennt jedenfalls für die> Reproduktion des Fehlers zumindest historisch aktive Pulls an einem als> Input betriebenen GPIO.
Bei so einem frischen Chip muss man allerdings erwägen, dass das Errata
noch unvollständig sein könnte.
Bradward B. schrieb:>> Das Problem tritt auch ohne aktivierte interne Pullups oder Pulldowns>> auf!>> Das kannst du sicher mit einem link auf das entspreche3nde Erata> belegen.
Noch nicht. Allein in diesem Thread gibt es aber schon drei Pico2
Besitzer die dieses Verhalten beobachtet haben und keinen bei den der
Controller sich so verhält wie in Fehler E9 beschrieben. In einer
zukünftigen Version des Datenblattes wird die Fehlerbeschreibung
sicherlich an das reale Verhalten des Controllers angepasst und dann
hoffentlich möglichst bald der Fehler in einer neuen Chiprevision
beseitigt.
Bradward B. schrieb:>> Hochohmige Eingänge sind so ohne weiters kompiziert oder ohne>> Zusatzbeschaltung unmöglich.>> ??? die Inputs sind ohnehin hochohmig, .
Ein Input den ich mit einem 30k Widerstand nicht auf low ziehen kann
wenn er einmal auf high war ist wohl kaum hochohmig, da fließt schon ein
nennenswerter Strom.
> Was du meinst ist tristate-Stufe> und das sind sinnvollerweise Outputs.
Nein und nein!
> Wenn einem der widerstand am Input> zu gering ist dann erhöht man den ohnehin nicht über einen Pull sondern> über einen serien- (auch Brems-widerstand genannt) Widerstand
Ein Serienwiderstand wäre hier kontraproduktiv.
Bradward B. schrieb:>> Ich sehe noch keinen Weg wie man sinnvoll>> direkt mit einem hochohmigen Signal, das normalerweise high ist und>> aktiv low, umgehen soll.>> Indem man einen externen Pull einbaut. Und das der Pico ublicherweise> auf Steckbretter aufsteckbar ist, ist das auch kein problem.
Bei einem Signal das möglichst gering belasten werden darf vergrößert
ein externer Pull-Widerstand den Eingangswiderstand - erstaunlich.
Bradward B. schrieb:> Nun ich habe die Erfahrung gemacht, das die threads in diesem Forum zu> einem nicht unerheblichen Teil subjektive und falsche Informationen> enthalten.
Oh, wie recht Du hast.
Ich habe folgendes Experiment mit einem RP2350 Eingang gemacht. Ich habe
ein 1 k Poti an GND und 3V3 angesschlossen, so dass ich mit dem
Mittelabgriff eine Spannung von Null bis 3V3 einstellen kann. Den
Mittelabgriff des Poti verbinde ich über einen 100k Widerstand mit einem
GPIO Pin des RP2350. Den GPIO Pin stelle ich auf Eingang, keine
Pull-Ups, ein. Dann erhöhe ich die Spannung des Eingangs von Null
beginnend. Dabei messe ich die Spannung am GPIO-Pin.
Erst folgt die GPIO-Pin Spannung der eingestellten Spannung, das heisst
der Eingang verhält sich hochohmig. Bei 1.37 Volt springt die Spannung
am GPIO Pin auf 2.26 Volt und der Eingang "hängt" auf dieser Spannung.
Wenn man den 100k Widerstand weglässt verhält der Eingang sich "normal",
d.h. man merkt nichts vom klemmen auf 2.26V.
Bradward B. schrieb:> Die Darstellung des problems im Erata nennt jedenfalls für die> Reproduktion des Fehlers zumindest historisch aktive Pulls an einem als> Input betriebenen GPIO
Wie kann man "historisch aktiv" vermeiden wenn der Reset-Zustand aller
normalen GPIOs laut Datenblatt "Pull-Down" ist?
Beim nächsten Experiment habe ich den 100k Widerstand zwischen Poti
Mittelabgriff und GPIOpin durch einen 4k7 Widerstand ersetzt und ich
starte mit 3V3 und erniedrige langsam die Spannung. Bis 1.37V folgt die
GPIO Spannung dem Poti und der Pin "hängt" soweit, dann springt die GPIO
Spannung auf 0.8V und der GPIO Pin hängt nicht mehr.
stk:
Wie kann man "historisch aktiv" vermeiden wen der Reset-Zustand aller
normalen GPIOs laut Datenblatt "Pull-Down" ist?
Antwort: Gar Nicht (Meiner Meinung Nach)
Bei meinem Experiment habe ich den PULL-DOWN ausgeschaltet. Bei dem
Experiment mit 100k in Reihe zum Pin merkt man dass kein Pull-Up oder
Pull-Down aktiv ist.
Martin O. schrieb:> Bis 1.37V folgt die> GPIO Spannung dem Poti und der Pin "hängt" soweit, dann springt die GPIO> Spannung auf 0.8V und der GPIO Pin hängt nicht mehr.
Das bedeutet wohl, daß die ADC-Eingänge ohne niedrige Quellimpedanz
nicht brauchbar sind.
Ich habe jetzt einen ADC-Eingang getestet. Quelle ist wie oben das 1k
Poti zwischen GND und 3V3 mit 100k in Serie zwischen Mittelabgriff und
GPIOpin 26 = ADC0. Laut gpio_is_pulled_down(ADCpin) ist der Pull-Down
enabled. Aber ich merke keine Wirkung. Der ADC Eingang ist hochohmig und
der GPIO-Fehler tritt nicht auf. Den ADC kann man anscheinend ohne
Fehler benutzen.
Ich hab mal nen Push-Button Test gemacht (angehängtes Programm).
GPIO Pin auf Input und Pull-Up enabled, Pull-Down disabled. Dann einfach
Pin-Zustand mit gpio_get() lesen. Funktioniert einwandfrei. Der Kontakt
nach Masse ist ja auch niederohmig genug um den GPIO-pin aus dem
"Hängen" Zustand zu holen.
Martin O. schrieb:> Laut gpio_is_pulled_down(ADCpin) ist der Pull-Down enabled.> Aber ich merke keine Wirkung. Der ADC Eingang ist hochohmig und> der GPIO-Fehler tritt nicht auf. Den ADC kann man anscheinend ohne> Fehler benutzen.
Weil an dem Pin alle digitalen Funktionen abgeschaltet sind. Das wird
deine lib schon richtig erledigen. gpio_is_pulled_down() kann ja einen
internen Zustand liefern, evt. sogar intern in der lib.
Anscheinend kann man "historisch aktiv" doch vermeiden. Wenigstens,
solange jede Pin-Funktion vom Start weg definiert wird und später nicht
geändert wird.
Martin O. schrieb:> Wie kann man "historisch aktiv" vermeiden wen der Reset-Zustand aller> normalen GPIOs laut Datenblatt "Pull-Down" ist?> Antwort: Gar Nicht (Meiner Meinung Nach)
> Ich hab mal nen Push-Button Test gemacht (angehängtes Programm).> GPIO Pin auf Input und Pull-Up enabled, Pull-Down disabled. Dann einfach> Pin-Zustand mit gpio_get() lesen. Funktioniert einwandfrei.
Ok, danke für den Test.
Also kann man die bisherige dünne Datenlage so zusammenfassen, das der
"Bug" unter Laborbedingungen reproduzierbar ist, aber bisher keine
praktische Relevanz ("Exploit") hat?
Also alle bisher untersuchten "real-world" Anwendung verhalten sich
gleich, egal ob Pico 1 oder Pico 2 ? (Nochmals, nach der sehr dünnen
aktuellen Datenlage) ?
> Bei so einem frischen Chip muss man allerdings erwägen, dass das Errata> noch unvollständig sein könnte.
Klar, aber das gilt fuer jeden Mikrocontroller da draussen und da gibt
es sicher noch welche mit schraegeren Bugs.
Vanye
Bauform B. schrieb:> Weil an dem Pin alle digitalen Funktionen abgeschaltet sind.
Da ich ein Labornetzteil schneller gefunden habe als ein Poti habe ich
das als einstellbare Spannungsquelle genutzt. Nur als analoger Eingang
genutzt liefer der ADC plausible Werte und das Netzteil zeigt im
gesamten Spannungsbereich von 0V bis 3,3V praktisch keinen Strom an, die
Anzeige wechselt zwischen 0,00mA und 0,01mA.
Lustig wird es wenn man den Pin auch als digitalen Eingang definiert,
auch ohne Pullup oder Pulldown.
Von 0 bis etwa 1,3V ist das Verhalten normal, der ADC liefer plausible
Werte, das Netzteil zeigt 0 Strom an und der digitale Eingang liefert 0.
Bei Spannungserhöhung über 1,3V wechselt der digitale Eingangswert auf 1
und das Netzteil zeigt -0,11mA an. Bei weiterer Spannungserhöhung fällt
die Stromaufnahme durch das Netzteils, erreich bei etwa 2,3V wieder 0
und bleibt auch bei bis zu 3,3V bei 0.
Erniedrigt man die Spannung wieder wechselt das Verhalten bei den
gleichen Spannungen zurück.
Das Ganze wirkt als wäre bei einer Spannung zwischen 1,3V und 2,3V am
Pin ein interner Pullup aktiv.
Bradward B. schrieb:> Ok, danke für den Test.> Also kann man die bisherige dünne Datenlage so zusammenfassen, das der> "Bug" unter Laborbedingungen reproduzierbar ist, aber bisher keine> praktische Relevanz ("Exploit") hat?
Das sieht sicher nicht nur Ian, der Finder des Fehlers, anders:
"I know the dreaded 2.15volts because my logic analyzer has bus hold
pins that sit at 2.15volts when connected to the Bus Pirate. It freaks
me out every time. Rpi confirmed the issue and added it to the
datasheet."
https://forum.buspirate.com/t/rp2350-bus-pirate-5xl-and-6/529?ref=buspirate.com
Weiter unten auf der Seite ist ein Eintrag von ihm von gesten:
"There is a silicon bug that causes the pins to latch up, and the pin
pull-downs are defective/insufficient. It was in the errata (I reported
it!), but it turns out to be MUCH more extensive than documented. Any
open drain type bus mode will not work (1-Wire, I2C, etc).
One possible solution I tested is replacing the 100K pull-downs on the
GPIO with 4.7K pull-downs. This does get the pins working “correctly”.
...
We’re still waiting to hear what the plan is from Raspberry Pi. When
there is a fix we’ll send everyone updated hardware.
I suspected we might have an issue in the first batch, so replacing
hardware is already baked into the price. I just thought it would be a
me bug, not a silicon bug."
> Das sieht sicher nicht nur der Finder des Fehlers anders:> "I know the dreaded 2.15volts because my logic analyzer has bus hold> pins that sit at 2.15volts when connected to the Bus Pirate. It freaks> me out every time. Rpi confirmed the issue and added it to the> datasheet."> https://forum.buspirate.com/t/rp2350-bus-pirate-5xl-and-6/529?ref=buspirate.com
Naja, "freaks me out" ist nicht gerade eine klare Beschreibung eines
Fehlerbildes.
Unklar bleibt ebenfalls, ob jetzt der Logicanalyzer nicht funktioniert,
weil da ein Pico 2 tut, oder lediglich das Debuggen am Bus mit diesem
speziellen Tool erschwert (?) ist.
Und hier "freaken" manche wegen der Zeichensetzung ihrer Zeitgenossen
aus.
> Any open drain type bus mode will not work (1-Wire, I2C, etc).
Gerade diese Vermutung sollte man mal testen, der Push-button sollte
nach der Fehlerbeschreibung auch nicht funktionieren - tut aber.
Stefan K. schrieb:> Lustig wird es wenn man den Pin auch als digitalen Eingang definiert,> auch ohne Pullup oder Pulldown.> Das Ganze wirkt als wäre bei einer Spannung zwischen 1,3V und 2,3V am> Pin ein interner Pullup aktiv.
Man kann einen Schmitt-Trigger bauen aus einem nicht-invertierendem
Gatter und einem Widerstand vom Ausgang zum Eingang. An so einem Eingang
würde man ein ähnliches Verhalten sehen.
Mach mal den gleichen Versuch, aber schalte den Schmitt-Trigger ab.
Bradward B. schrieb:> Gerade diese Vermutung sollte man mal testen, der Push-button sollte> nach der Fehlerbeschreibung auch nicht funktionieren - tut aber.
Du hast es nicht begriffen.
Bradward B. schrieb:> Danke, gleichfalls.
Denk nochmal nach. Was niederohmig bedeutet zum Beispiel. Und ob das was
mit deinem Push-Button-Beispiel zu tun hat. Vielleicht klickt's ja dann
irgendwann und deine Logik bleibt dann auch nicht mehr hängen.
> Vielleicht klickt's ja dann> irgendwann und deine Logik bleibt dann auch nicht mehr hängen.
Und, wer zeigt jetzt eine ausgemessene Anwendung, die mit dem Pico 1
tut, aber nicht mit Pico 2 ?
Passender Alt-Herren-Spruch dazu:
"Kriterium der Wahrheit ist die Praxis." (nicht die logik, oder der
Beifall der Mitläufer) ;-)
Gerade diese Vermutung sollte man mal testen, der Push-button sollte
nach der Fehlerbeschreibung auch nicht funktionieren - tut aber.
Der Push-Button funktioniert meiner Meinung nach folgendermassen: Wenn
der Button nicht gedrückt ist zieht der Pull-Up den Pin nach 3.3V (hab
ich gemessen). Dabei durchläuft der Pin den "Hängen" Mechanismus. Wenn
man den Button drückt geht der Pin auf 0 und weil das niederohmig ist
wird der "Hängen" Mechanismus rückwärts durchlaufen und man liest 0.
Lässt man den Button wieder los zieht der Pull-Up den Pin wieder auf 3.3
und man liest wieder 1.
Wenn man den Pin niederohmig genug ansteuert funktioniert der Pin als
Eingang.
Und, wer zeigt jetzt eine ausgemessene Anwendung, die mit dem Pico 1
tut, aber nicht mit Pico 2 ?
Siehe oben: Eingang über 100k mit variabler Spannung ansteuern. Wenn man
die Eingangsspannung einmal über 1.4V erhöht hat bleibt der Pico2 auf
2.2V hängen, der Pico1 nicht.
> Siehe oben: Eingang über 100k mit variabler Spannung ansteuern. Wenn man> die Eingangsspannung einmal über 1.4V erhöht hat bleibt der Pico2 auf> 2.2V hängen, der Pico1 nicht.
Das ist keine Anwendung, das ist eine "Labormessung" wie ein Pin auf
Signale im verbotenen Logigpegelbereich regiert.
https://de.wikipedia.org/wiki/Logikpegel
Ein Serienwiderstand von 100k ist auch nicht sonderlich realistisch für
eine elektrische Verbindung zwischen einer (digitalen) Quelle und Senke.
Stell Dir vor Du steuerst den GPIO-Pin über einen Transistor als
Emitterfolger an mit 100k Emitterwiderstand weil Du low-Power Ekektronik
machst. Dann wird aus meiner Messung eine Anwendung.
Martin O. schrieb:> Stell Dir vor Du steuerst den GPIO-Pin über einen Transistor als> Emitterfolger an mit 100k Emitterwiderstand weil Du low-Power Ekektronik> machst. Dann wird aus meiner Messung eine Anwendung.
Eine Imagination/Vorstellung ist keine Anwendung )außer vielleicht für
Tagträumer ;-) )
Was einen Emitterfolger besonders stromsparend machen soll, erschliesst
sich auch nicht, besonders stromsparend wäre eine CMOS-Stufe / FET als
Schaltertreiber (siehe Anhang).
Aber wir kommen weiter von der ursprünglichen Frage ab, wie verhält sich
nun ein I²C Bus an einem Pico 2 (Praktischer Nachweis)? Sind da
Anpassungen (Geschwindigkeit, Bauteildimensionierung, ..) notwendig oder
sinnvoll ?
Bradward B. schrieb:> Das ist keine Anwendung, das ist eine "Labormessung" wie ein Pin auf> Signale im verbotenen Logigpegelbereich regiert.
Wie soll deiner Meinung nach ein beliebiges Signal, das von low nach
high wechselt (und umgekehrt), den "verbotenen Bereich" meiden? Etwa
durch Quantensprung, Magie, Telepathie, Gotteskraft etc.?
Bradward B. schrieb:>> Siehe oben: Eingang über 100k mit variabler Spannung ansteuern. Wenn man>> die Eingangsspannung einmal über 1.4V erhöht hat bleibt der Pico2 auf>> 2.2V hängen, der Pico1 nicht.>> Das ist keine Anwendung, das ist eine "Labormessung" wie ein Pin auf> Signale im verbotenen Logigpegelbereich regiert.> https://de.wikipedia.org/wiki/Logikpegel
Man muß schon ganz schön krank sein, wenn man auf solch einen an den
Haaren herbeigezogenen Stuss kommt ...
Bradward B. schrieb:> Aber wir kommen weiter von der ursprünglichen Frage ab, wie verhält sich
Ach ...
Jens G. schrieb:> Man [Anm. Bradward B.] muß schon ganz schön krank sein, wenn man auf solch einen
an den
> Haaren herbeigezogenen Stuss kommt ...
Je mehr ich von Bradward B. lese, umso mehr komme ich zu der
Überzeugung, dass da viel Wahres dran sein könnte, leider!
Pat A. schrieb:> Je mehr ich von Bradward B. lese, umso mehr komme ich zu der> Überzeugung,
Der unter E9 genannte Fehler ging von aktivem pulldown-Widerstand aus.
Die Anwendung von Bradward B. ist eine andere. Ist das so schwer zu
sehen?
Ich habe Anwendungen, wo ich mit pullup-/down Touch-Folien bzw. Taster
hochohmig abfrage. Da habe ich keinerlei Bedarf, daß dort durch latchup
etwas hängen bleibt. Und ich habe keinen Bedarf an noch nicht entdeckten
Seiteneffekten, die daraus entstehen könnten. Sollte ein IIC-Bus hängen
bleiben, hört der Spaß auf.
Mag sich B.B. seine Welt schön träumen, ich habe keinen Bedarf am RP2350
und gehöre sicherlich auch nicht zur Zielgruppe. Der Rp2040 reicht mit
seinen Möglichkeiten und seinen Einschränkungen. Kritikpunkte an den
RPxxxx hatte ich ja schon angedeutet.
Bauform B. schrieb:> Mach mal den gleichen Versuch, aber schalte den Schmitt-Trigger ab.
Die Spannungsanzeige des Labornetzteils hat eine zu geringe Auflösung,
ich habe jetzt noch ein Multimeter parallel angeschlossen.
Bei zurückgesetztem Pad isolation Bit, gesetztem Input enable Bit und
mit Schmitt-Trigger liegt die Schwelle bei der der Effekt bei steigender
Spannung auftritt bei 1,44V und die bei er bei fallender Spannung
verschwindet bei 1,12V. Bei abgeschaltetem Schmitt-Trigger tritt der
Effekt ebenfalls auf, die Schwellen liegen mit etwa 1,37V und 1,35V nur
deutlich dichter beieinander.
Falls jemand das auch mal mit Micropython testen will:
Wenn man mit einem kräftigen Signal den Pin aus seinem 'hängen'
rausbekommt, legt das allerdings auch die Vermutung nahe, das da
deutlicher Strom in den Eingang fliessen muss. Das ist nicht das, was
man sich an einem Input wünscht.
Der RP2040 spricht von 1µA (leakage Current) am digitalen Eingang und
100kOhm Impedanz am ADC Eingang.
Mit 1µA wird man beim RP2350 vermutlich nicht viel reissen -
Killerkriterium.
Matthias S. schrieb:> Wenn man mit einem kräftigen Signal den Pin aus seinem 'hängen'> rausbekommt, legt das allerdings auch die Vermutung nahe, das da> deutlicher Strom in den Eingang fliessen muss.Stefan K. schrieb:> Von 0 bis etwa 1,3V ist das Verhalten normal, der ADC liefer plausible> Werte, das Netzteil zeigt 0 Strom an und der digitale Eingang liefert 0.> Bei Spannungserhöhung über 1,3V wechselt der digitale Eingangswert auf 1> und das Netzteil zeigt -0,11mA an. Bei weiterer Spannungserhöhung fällt> die Stromaufnahme durch das Netzteils, erreich bei etwa 2,3V wieder 0> und bleibt auch bei bis zu 3,3V bei 0.Stefan K. schrieb:> Bei abgeschaltetem Schmitt-Trigger tritt der> Effekt ebenfalls auf, die Schwellen liegen mit etwa 1,37V und 1,35V nur> deutlich dichter beieinander.
In dem Zustand fließt wahrscheinlich kaum weniger Strom. I2C mit
vernünftigen Pull-Up sollte aber immer funktionieren. Und es ist ein
ganz anderes Problem als die Pull-Down Geschichte. Ein wirklich
"interessanter" Chip, so viel Abenteuer...
Matthias S. schrieb:> Wenn man mit einem kräftigen Signal den Pin aus seinem 'hängen'> rausbekommt, legt das allerdings auch die Vermutung nahe, das da> deutlicher Strom in den Eingang fliessen muss.
Bei meinem Pico2 sind es an der Schaltschwelle gut 110µA die aus dem
Eingang gezogen werden müssen um von high auf low zu kommen. In
Gegenrichtung reicht ein 3M Widerstand nach 3,3V aus. Von 0V bis zur
Schaltschwelle und oberhalb von 2,5V bis zur Versorgungsspannung ist der
Eingang hochohmig. In den beiden Bereichen zeigt mein Multimeter
praktisch keinen Strom an, die Anzeige springt höchstens mal von den
0,01µA die es ohne Strom anzeigt auf 0,02µA.
Bauform B. schrieb:> In dem Zustand fließt wahrscheinlich kaum weniger Strom. I2C mit> vernünftigen Pull-Up sollte aber immer funktionieren. Und es ist ein> ganz anderes Problem als die Pull-Down Geschichte. Ein wirklich> "interessanter" Chip, so viel Abenteuer...
Der Strom ist gleich, nur die Schaltschwellen sind verschoben.
Es ist wahrscheinlich doch genau dieses Verhalten, das zum Erratum
RP2350-E9 im Datenblatt geführt hat. Das war ein Schnellschuss nachdem
der Fehler gemeldet wurde und weder dem Finder noch RPi ganz klar war
was genau da passiert.
Es soll wohl in einem sehr späten Entwicklungsschritt Änderungen an den
von RPi zugekauften PAD-Macorozellen gegeben haben die sich anders
verhalten als die dazu gelieferte Simulation oder die zuvor gefertigten
Muster.
Stefan K. schrieb:> gut 110µA die aus dem> Eingang gezogen werden müssen
Ja danke, hatte ich zuerst überlesen. So ein Verhalten möchte ich nicht
bei einem Standardport wie einem GPIO. Damit ist der erstmal raus.
Ich habe mal in einem Diagramm den Strom den GPIO27 bei gesetztem Input
enable Bit und eingeschaltetem Schmitt-Trigger liefert über die
niederohmig angelegte Spannung aufgetragen: Strom in µA, blau bei
steigender Spannung und rot bei fallender.
Ein 10k Pulldown reicht knapp um den GPIO von high wieder auf low zu
ziehen, mit einem 30k ist bei gut 2V Schluss.
Bei mehreren Eingängen gleichzeitig wird sich das wohl proportional
verhalten. Mal sehen, ob ein neueres Datenblatt Informationen dazu
liefert und ob es überhaupt eine korrigierte Version geben wird.
Andere Mütter ...
Stefan K. schrieb:> Ich habe mal in einem Diagramm den Strom den GPIO27 bei gesetztem Input> enable Bit und eingeschaltetem Schmitt-Trigger liefert über die> niederohmig angelegte Spannung aufgetragen
Vielen Dank für deine Mühe - leider haben die Herren aus der
Qualitätssicherung sich diese Arbeit erspart.
Ich bleibe erstmal beim RP2040.
Im element14-Forum hat jemand ein 0-3,3V Sinussignal über einen 10k
Widerstand mit einem GPIO-verbunden. Bei zurückgesetztem IE-Bit sieht
das normal aus, bei aktiviertem Eingang stark verzerrt. Dass dabei die
fallende Flanke stärker verzerrt ist als die steigende hatte ich so
erwartet.
https://community.element14.com/products/raspberry-pi/f/forum/55046/rp2350-gpio-pull-down-latching-bug/223658
Bei Ansteuerung mit einem nicht zu schwachen Push-Pull Ausgang sollte es
wenig Probleme geben, mit einem beliebig großen Pull-Up und einem nicht
zu schwachen OC/OD Ausgang ebenso. Falls man einen Pull-Down Widerstand
nutzen will sollte der kleiner als 10k sein.
Nicht schön, aber für viele Anwendungen auch nicht ganz schlimm.
Ein sinusförmiges Signal an einem Digitaleingang fand ich doch etwas
seltsam, ich habe es jetzt selbst mit einem Rechteckpuls und einem
trapezförmigen Puls aufgezeichnet. Blau ist jeweils das Ausgangssignal
eines Funktionsgenerators und rot die Spannung an einem über einen 10k
Widerstand angeschlossenen GPIO.
Bei nicht gesetztem Input Enable Bit sieht alles normal aus für einen
derartig hochohmig angesteuerten Eingang mit parallel direkt
angeschlossenem Oszilloskop.
Mit gesetztem IE-Bit sieht man wieder den merkwürdigen Pull-Up Effekt.
Beim Rechteckpuls ist die steigende Flanke etwas steiler, sieht sonst
aber normal aus. Die fallende Flanke ist stark verformt und so die Zeit
die der Controller ein High erkennt deutlich velängert.
Mit dem trapezförmigen Signal sieht man auch auf der steigenden Flanke
den Pull-Up Effekt und auf der fallenden Flanke mehr Details.
Martin O. schrieb:> Frage: ist der Pull-Down bei den Messungen> aktiviert?
Die liegen im Bereich zwischen 50…80kΩ.
Gefüttert über einen 10kΩ Widerstand dürfte die resultierende
Eingangsspannung bestenfalls irgendwo zwischen 2.93…2.75V landen.
Der Pull-Down war abgeschaltet.
Der Schmitt-Trigger aber war aktiv was man auch an der Kurve erkennt.
Ich werde heute Abend die Kurve mit dem linearen Anstieg und Abfall noch
mal deutlich länger machen um die sichtbaren Effekte durch umzuladende
Kapazitäten zu verringern und dann auch einmal ohne Schmitt-Trigger am
Eingang messen.
Stefan K. schrieb:> Der Schmitt-Trigger aber war aktiv was man auch an der Kurve erkennt.
Da wäre ich eher skeptisch. Beim RP2040 sind die Schmitt-Trigger
Schwellen bei 1.55V und 1.75V. Und in diesem Bereich sieht das alles
noch unverdächtig aus.
Interessant ist allerdings, dass beim Anstieg der Flanke eine scheinbare
Kapazität von (rundgeschätzen) knapp 30pF erscheint, beim Abfall (durch
den Fehler) jedoch wesentlich mehr.
Die negative Flanke sieht so aus, als würde bei 15kΩ, vielleicht schon
bei 12kΩ, die interne Logik nicht mehr zurück ›schnappen‹ können.
Der Eingang sollte dennoch einen Low Zustand melden.
Norbert schrieb:> Interessant ist allerdings, dass beim Anstieg der Flanke eine scheinbare> Kapazität von (rundgeschätzen) knapp 30pF erscheint, beim Abfall (durch> den Fehler) jedoch wesentlich mehr.
Bei beiden Flanken kann man wegen des merkwürdigen Pull-Up Effektes auf
etwa 2,5V bei gesetztem Input Enable Bit aus der Kurvenform kaum auf die
Eingangskapazität schließen.
Bei abgeschaltetem IE sieht man wohl eher die tatsächliche Kapazität
wenn man das Oszilloskop mit 1MΩ ∥ 13pF Eingang, das ich direkt ohne
Tastkopf über 5cm lange Leitungen angeschlossen hatte, berücksichtigt.
Norbert schrieb:> Die negative Flanke sieht so aus, als würde bei 15kΩ, vielleicht schon> bei 12kΩ, die interne Logik nicht mehr zurück ›schnappen‹ können.> Der Eingang sollte dennoch einen Low Zustand melden.
Exemplarabhängig können auch 10k schon zu viel sein. Und auch bei 10k
sieht bei meinem Pico2 eine symmetrisches 20kHz Rechteckwelle am Eingang
sehr "interessant" aus.
Auf den vom Controller erkannten Zustand hatte ich jetzt nicht geachtet,
ich hatte nur die Bits im Pad-Konfigurationsregister gesetzt. Ich meine
aber, dass bei vorherigen Tests der Eingang immer High meldete wenn der
Eingang "hing".
Bei eingeschaltetem Schmitt-Trigger folgt bei einer langsam steigenden
Flanke die Spannung am Eingang hinter dem 10k Widerstand bis ca. 1,45V
direkt der Spannung des Funktionsgenerators, "springt" dann auf gut 2V
und nähert sich dann wieder an die FG-Spannung an. Bei der fallenden
Flanke passiert der "Sprung" nach unten erst ganz kurz vor Ende des
Eingangspulses bei ca. 1,15V. 10k scheint schon sehr nahe an der oberen
Grenze zu sein bei der der Eingang wieder heruntergezogen werden kann.
Bei ausgeschaltetem Schmitt-Trigger erfolgen beide "Sprünge" bei ca.
1,35V, mit dem 10k Widerstand bleiben da etwas größere Reserven.
Norbert schrieb:> Da wäre ich eher skeptisch. Beim RP2040 sind die Schmitt-Trigger> Schwellen bei 1.55V und 1.75V. Und in diesem Bereich sieht das alles> noch unverdächtig aus
Mit eingeschaltetem Schmitt-Trigger lese bei langsam hochgeregelter
Spannung an einem GPIO meines PICO2 bis etwa 1,45V Low ein und darüber
High. Zurück auf Low gehr es dann erst wieder bei ca. 1,15V.
Die Schmitt-Trigger Schwellen liegen damit deutlich niedriger.
Egal ob mit oder ohne Schmitt-Trigger, der merkwürdige Pull-Up Effekt
beginnt bzw endet an den Punkten an denen ein Wechsel des logischen
Pegels erkannt wird. Der Spannungsrippel der roten Kurve könnte vom
Schaltregler auf dem Pico2 kommen.
Scheint meine schlimmsten Vermutungen zu bestätigen. Hysterese breiter,
Schwellen deutlich niedriger, heftige Rückfütterung in die ansteuernde
Schaltung.
Entweder prügelt man verdammt niederohmig in die Eingänge hinein, oder
man nutzt das Ding nur für Ausgaben an den GPIOs. Bin gespannt ob's eine
vernünftig arbeitende nächste Revision geben wird, oder sie das Ding
komplett abgeschrieben haben. Vier Kerne für die Katz'.
Norbert schrieb:> Bin gespannt ob's eine> vernünftig arbeitende nächste Revision geben wird, oder sie das Ding> komplett abgeschrieben haben.
So, wie ich das verstanden habe, wollen sie am Chip erstmal nichts
machen, sondern nur die Dokumentation/Errata ergänzen :-O
Das wäre natürlich nur kurieren am Symptom.
Ist schon schade, wäre sicher ein interessanter MC geworden. Aber so...
Stefan K. schrieb:> Egal ob mit oder ohne Schmitt-Trigger, der merkwürdige Pull-Up Effekt> beginnt bzw endet an den Punkten an denen ein Wechsel des logischen> Pegels erkannt wird.
Klingt irgendwie nach aktiver bus-keeper Schaltung.
https://en.wikipedia.org/wiki/Bus-holder
Matthias S. schrieb:> So, wie ich das verstanden habe, wollen sie am Chip erstmal nichts> machen, sondern nur die Dokumentation/Errata ergänzen :-O> Das wäre natürlich nur kurieren am Symptom.> Ist schon schade, wäre sicher ein interessanter MC geworden. Aber so...
Es gibt Hardware Probleme die man zwar dokumentieren, jedoch nicht per
Software lösen kann. Dies ist eines. Mal schauen ob das noch zu denen
durchdringt.
Falls nicht…
Tja, dann isser wohl für Ernsthaftes gestorben. Andererseits, eine LED
blinken lassen kann man ja damit. Und für Knöppsche sind die ›I‹ der
GPIOs ja auch zu gebrauchen.
Also kommen die Dinger auf Arduino Boards und gut iss. Da sehe ich schon
bald die Beiträge eintrudeln: Mein Taster geht nicht, was soll ich tun?
Edit:
Die Modifikation der PADS sollte ja wohl der Stromersparnis dienen.
Dieses Ziel ist nahezu perfekt erreicht … wenn die Dinger in den Regalen
herum schimmeln.
Norbert schrieb:> Entweder prügelt man verdammt niederohmig in die Eingänge hinein, oder> man nutzt das Ding nur für Ausgaben an den GPIOs.
Bei schnellen und damit steilen Signalen sind die sehr kurzen maximal
etwa 0,1mA gegenüber den Strömen zum Umladen der Eingangskapazität und
der diversen zusätzlichen Kapazitäten in der Schaltung darumherum wohl
meist zu vernachlässigen.
Matthias S. schrieb:> So, wie ich das verstanden habe, wollen sie am Chip erstmal nichts> machen, sondern nur die Dokumentation/Errata ergänzen :-O
So, wie ich das verstanden habe, konnten sie bisher nicht einmal das von
inzwischen vielen geschilderte Verhalten reproduzieren.
Peter D. schrieb:> Klingt irgendwie nach aktiver bus-keeper Schaltung.> https://en.wikipedia.org/wiki/Bus-holder
Nicht wirklich, so wie sie jetzt ist hilft die Schaltung zwar ein High
am Eingang zu halten nicht aber ein Low. Und auch bei High hält sie ihn
selbst unbelastet nur auf 2,5V.
Norbert schrieb:> Edit:> Die Modifikation der PADS sollte ja wohl der Stromersparnis dienen.> Dieses Ziel ist nahezu perfekt erreicht … wenn die Dinger in den Regalen> herum schimmeln.
Ich meine, es ging um Fehlertoleranz bei 5V Eingangssignalen.
Egal was es war, das jetzt beobachte Verhalten hatte man bei RPi sicher
nicht gewollt.
Stefan K. schrieb:> Bei schnellen und damit steilen Signalen sind die sehr kurzen maximal> etwa 0,1mA gegenüber den Strömen zum Umladen der Eingangskapazität und> der diversen zusätzlichen Kapazitäten in der Schaltung darumherum wohl> meist zu vernachlässigen.
Ich finde es ja nett, das du probierst, den Bug zu entschuldigen, aber
selbst 100µA pro GPIO sind in einer modernen Schaltung einfach nur
Verschwendung, um einen GPIO loszutreten. Das läppert sich mal schnell,
wenn du mehrere benutzt.
Bei dem RP2350 geht es wohl eher darum, eine Eierlegendewollmilchsau als
Ersatz/Ergänzung zu den RPIs anzubieten, auf denen Linux in Größe einer
Briefmarke läuft. Dafür werden die großen Speicherbereiche gebraucht.
GPIO geht keinen mehr etwas an und wird nur durch fertige LIBs
angesprochen.
Daß im GPIO-Bereich Knickeier zu finden sind, stört nur die paar
Spinner, die TTL-Pegel nicht mehr kennen. Die bringen keinen
nennenswerten Umsatz. Wozu RISC-V als 'minderwertiges' Beiwerk gut sein
soll, erschließt sich mir nicht. Durch die vorhandnen ARM-Kerne sind
Lizenzkosten im Kaufpreis schon enthalten.
Durch den günstigen Preis werden aus Gründen des Wettbewerbes vielleicht
zum Beispiel STM32 für das normale Volk preiswerter. Positiv denken ;-)
Norbert schrieb:> Tja, dann isser wohl für Ernsthaftes gestorben.
OK, Übertreibung macht deutlich. Aber schaut euch mal eure alten
Schaltungen an. Wie viele Pins wären tatsächlich betroffen? Ich hab'
gerade gesucht und tatsächlich einen gefunden. Das war ein
nachträgliches Luxus-Feature mit 39k Längswiderstand zum Eingang.
Witzigerweise hat das mit einem STM32L031 dann doch nicht
funktioniert...
Stefan K. schrieb:> Bei schnellen und damit steilen Signalen sind die sehr kurzen maximal> etwa 0,1mA gegenüber den Strömen zum Umladen der Eingangskapazität und> der diversen zusätzlichen Kapazitäten in der Schaltung darumherum wohl> meist zu vernachlässigen.
Eben. Die allermeisten Eingänge gehen entweder auf den ADC oder werden
sowieso von Pegelwandlern, EPROMs usw. getrieben. Oder von einem
externen Schmitt-Trigger, weil man dem internen noch nie getraut hat.
Oder ich spendiere einem Batteriegerät 1xUM-Taster für 0µA Standby.
Alles ist niederohmig...
Also ja, es ist ein spannender Fehler, aber praktisch kostet der nichts
extra.
Matthias S. schrieb:> Ich finde es ja nett, das du probierst, den Bug zu entschuldigen,
Ich versuche nicht den Bug zu entschuldigen, würde ich sonst hier mit
Messungen zeigen wie sich der Fehler auswirkt?
Ganz klar, das Verhalten der GPIOs kann Probleme bereiten und zum nicht
funktionieren von Schaltungen führen die eigentlich funktionieren
müssten.
Vieles wird aber auch einfach funktionieren oder kann zum funktionieren
gebracht werden wenn man die Eigenheiten der GPIOs kennt.
Stefan K. schrieb:> So, wie ich das verstanden habe, konnten sie bisher nicht einmal das von> inzwischen vielen geschilderte Verhalten reproduzieren.
Iss nicht dein Ernst, oder? ;-)
Gut, derartig komplexe Szenarien können auch nur Raketenwissenschaftler
angemessen untersuchen…
1
#!/python
2
# -*- coding: UTF-8 -*-
3
# vim: fileencoding=utf-8: ts=4: sw=4: expandtab:
4
5
#─────[ GPIO ›0‹ and ›1‹ connected with 0Ω and various resistors ]────────────────────
Wie man sieht, hat's auch nichts mit Pull-[up|down] zu tun.
Edit:
Wir schreiben das Jahr 2024. Alles ist gut. Die Erdscheibe dreht sich.
Das Board mag kein UTF-8 wenn es Anhänge zeigt.
Bauform B. schrieb:> Norbert schrieb:>> Tja, dann isser wohl für Ernsthaftes gestorben.>> OK, Übertreibung macht deutlich. Aber schaut euch mal eure alten> Schaltungen an. Wie viele Pins wären tatsächlich betroffen?
Alle, welche zB. mittels PIO belastungsarm auf Signalen herum
schnuppern. Da funktioniert der vorgeschlagene Würgaround mit ↑IE↑ read
↓IE↓ nicht.
Kann man Buffer vorpacken, das ändert die Situation, nun:
Alle, welche zB. dynamisch die Richtung ändern müssen.
Kann man spezielle Transceiver vorpacken, das ändert die Situation, nun:
Zusätzliche Pins für [en|dis]able erforderlich. Evtl. Timing.
Wie kann man auf Flanken mit IRQs reagieren, wenn IE immer abgeschaltet
bleiben muss?
Wie kann DMA read bei jedem Lesevorgang IE bedienen?
Wie verhalten sich all die anderen Subsysteme an den Eingängen?
Wenn ich beim Hersteller arbeiten würde, dann würde ich erst mal
versuchen, eine guten Workaround zu finden, der das Problem abstellt,
bevor ich mich weiter dazu äußere.
Mi N. schrieb:> Das aktuelle Datenblatt vom RP2350 vom 06.09.2024 hat nun eine> erweiterte Fehlerbeschreibung E9.
Ja, besser, aber meiner Meinung nach immer noch irreführend.
Die Wortwahl suggeriert das der Fehler auftritt, wenn der Eingangspegel
… Moment …
1
Increased leakage current when Bank 0 GPIO pads are configured as inputs and the pad is somewhere between V IL and V IH (the undefined logic region).
Doch das sogenannte ›Latch-up‹ hatte ich auch beobachtet, wenn mit
maximaler Flankensteilheit auf High geschaltet und dann der (offene)
Eingang hochohmig/weak gegen Masse gezogen wird. Da bleibt's — im
Gegensatz zum RP2040 — einfach High und erst ein <= 8.2kΩ Widerstand
gegen Masse lässt das Ding zurück schnappen.
Das werde ich aber noch etwas genauer testen.
Es gibt aber auch Positives zu berichten.
Der ADC ist massiv verbessert worden.
60k Samples @ 500ksps per DMA.
Rohdaten im Anhang, wer mal selbst mit gnuplot reinschauen möchte…
Norbert schrieb:> Ja, besser, aber meiner Meinung nach immer noch irreführend.
Ist mir letzlich egal, das Teil werde ich nicht beschaffen und daher
nicht verwenden.
Als Hersteller würde ich auch keine korrigierte Version ankündigen:
(fast) alle würden abwarten und die produzierten Bestände nicht kaufen.
Norbert schrieb:> Rohdaten im Anhang, wer mal selbst mit gnuplot reinschauen möchte…
Die Abstände der Einzelwerte etwas zu groß und auf die Optik würde ich
mich nicht verlassen, obwohl da schon Rauschen zu sehen ist.
Mi N. schrieb:> …
Es ging mir im Wesentlichen um die nicht mehr vorhandenen Sprünge bei
den 512er Schritten.
Und wenn man eine zweite Kurve mit einem 101 breiten Median dazu
plottet, sieht's gar nicht mal soooo schlecht aus.
Christoph M. schrieb:> Hast Du den Source-Code dazu?
Klar. Der ist aber in Micropython geschrieben und das wird hier im Forum
gar nicht gerne gesehen.
Vor allem, weil man damit ja so rein gar nichts Richtiges machen kann.
;-)
Darum spare ich mir alles, was über kurze Snippets hinaus geht.
Norbert schrieb:> Es ging mir im Wesentlichen um die nicht mehr vorhandenen Sprünge bei> den 512er Schritten.
Hast Du Deine Messung auch mal mit einem RP2040 gemacht? Da müßte doch
eine Verschlechterung zu sehen sein.
Vor längerer Zeit hatte ich mit dem RP2040 einen PT1000 ausgewertet,
wobei ich keine Unstetigkeiten gefunden hatte. Da es letztlich nur ein
Spannungsteiler mit einem 1 k Festwiderstand war, hätte man auch im
betreffenden Bereich mit einm IO-Pin einen Offset (100 k) zuschalten
können, um aus dem kritischen Bereich zu kommen. Hatte ich wohl
seinerzeit auch gemacht und wieder weggepackt, da kein Bedarf vorhanden
war.
Mehr gestört hatte mich der Grundoffset von 13. Das Datenblatt macht
hierzu keine Angaben.
Mi N. schrieb:> Hast Du Deine Messung auch mal mit einem RP2040 gemacht? Da müßte doch> eine Verschlechterung zu sehen sein.
Ja, hatte ich. Übelste Sprünge bei 3×512-1, 5×512-1, 7×512-1
Weniger schlimm bei 2/4/6×512-1
Grafik dazu hatte ich auch mal gepostet.
Mit ein wenig adaptiver Magie, ein wenig zusätzlicher Beschaltung und
einer automatisch erzeugten Korrekturkurve ging es dann aber. Allerdings
lag der Output ›nur‹ bei 100ksps, trotz 500ksps Samplerate.
Norbert schrieb:> Der ist aber in Micropython geschrieben und das wird hier im Forum> gar nicht gerne gesehen.
Ich habe schon in ASM, PHP, BASIC, C und Pascal Programme geschrieben
und finde Micropython auf dem Pico einfach super. Meine neue Bodendrohne
läuft damit und der Entwicklungszyklus ist eben extrem kurz. Also ruhig
posten, lass die anderen ruhig meckern.
Norbert (der_norbert)
>Klar. Der ist aber in Micropython geschrieben und das wird hier im Forum>gar nicht gerne gesehen.
Wenn es passt, nutze ich Micropython auch manchmal. Wäre super, wenn Du
den Code posten könntest. Mit maximaler Rate zu sampeln und dann die
Daten auf dem PC auszuwerten scheint mir extrem brauchbar.
> Wenn ich beim Hersteller arbeiten würde, dann würde ich erst mal> versuchen, eine guten Workaround zu finden, der das Problem abstellt,> bevor ich mich weiter dazu äußere.
Als guter Hersteller würde ich vor der Suche nach einem workaround die
praktischen Auswirkungen untersuchen.
Also auf den (Referenz)-Applikationen/Boards die Regression-tests laufen
lassen. Den Kunden könnte man bitten, das gleiche zu tun, vielleicht
schmiert man ihm noch den Honig des "Early Adopters with special
customer support" ums Maul.
Sollte sich dabei was zeigen, wirds nach Schwere der Auswirkung und
Möglichkeit der Mitigation klassifiziert. Aus letzteren kann man dann
verschiedene Empfehlungen intern und in Richtung Kunden ableiten,
beispielwweise:
* Dok anpassen und Reports aus dem Feld beobachten
* Bei regulärer Wartung Firmware-Update aufspielen
* sofort Firmware-Update aufspielen
* Bei Gelegenheit Hardware tauschen
* ...
* Rückruf-Aktion
Normalerweise hat eine (auditierte) Firma eine entsprechende
Prozessbeschreibung (life cycle managment, complaints response).
https://de.wikipedia.org/wiki/Regressionstesthttps://em360tech.com/tech-article/understanding-computer-hardware-risk-mitigation-methods
> Also ja, es ist ein spannender Fehler, aber praktisch kostet der
nichts
extra.
Eben, wobei "Fehler" dramatischer klingt als dessen Auswirkungen in Echt
sind.
Man könnte auch "Vernachlässigbarer Fehler" sagen, oder "Schluckauf an
einer Stelle wo es keinen stört".
Bradward B. schrieb:> Sollte sich dabei was zeigen, wirds nach Schwere der Auswirkung und> Möglichkeit der Mitigation klassifiziert. Aus letzteren kann man dann> verschiedene Empfehlungen intern und in Richtung Kunden ableiten,> beispielwweise:> * Dok anpassen und Reports aus dem Feld beobachten> * Bei regulärer Wartung Firmware-Update aufspielen> * sofort Firmware-Update aufspielen> * Bei Gelegenheit Hardware tauschen> * ...> * Rückruf-Aktion
Langeweile mit ShitGPT vertrieben?
Norbert schrieb:> Langeweile mit ShitGPT vertrieben?
Ich hatte "Geschwurbel" auf den Lippen aber Deine Bezeichnung ist 100 x
besser. Sie trifft den Kern und den Pudel ;-)
"It's just a normal power glitch. Just drop USB_OTP_VDD for 50μs or so across the CRIT0 and CRIT1OTP PSM reads, which on my chips are around 220-250μs from the characteristic current spike that marks the beginning of the OTP PSM sequence."
Bradward B. schrieb:> Das ist bemerkenswert, hat aber nix mit dem GPIO-Glitch zu tun.
Die paar Technikspinner, die sich über den GPIO-Fehler ausgelassen
hatten, konnte der Chip-Hersteller vermutlich noch 'weglächeln'. Nunmehr
wird er wohl deutlich mehr Druck bekommen, um ein Redesign vorzunehmen.
Dabei sollte Hoffnung bestehen, daß auch das GPIO-Verhaltten korrigiert
wird. Insofern gehört mein Hinweis zum Thema.
Soweit ich mich erinnere, gab es auch weitere Probleme mit dem µC,
namentlich den Schaltregler.
> Die paar Technikspinner, die sich über den GPIO-Fehler ausgelassen> hatten, konnte der Chip-Hersteller vermutlich noch 'weglächeln'. Nunmehr> wird er wohl deutlich mehr Druck bekommen, um ein Redesign vorzunehmen.
Nö, das Security Subsystem ist ne Neueinführung für den Pico 2, der
ursprüngliche Pico hat das garnicht. "Ernsthaft" benutzt hat das
security subsystem meines Wissens keiner, außer für den Hacking
Wettbewerb. IMHO kein Grund für ein Redesign, ausser das das Security
subsystem beim nächsten milestone komplett rausfliegt.
RaspberryPi Foundation entwickelt halt für Bastler/Schüler und nicht für
Konsumenten. Siehe auch:
https://static.raspberrypi.org/files/about/RaspberryPiFoundationStrategy2025.pdf> Dabei sollte Hoffnung bestehen, daß auch das GPIO-Verhaltten korrigiert> wird. Insofern gehört mein Hinweis zum Thema.
Wem das beschriebene GPIO-Verhalten stört kann einen externen Pull
benutzen, insofern kein Grund das Silizium ausserhalb der roadmap
anzufassen. Oder man verwendet ohnehin den reiferen Pico (ohne 2 und
Schnickschnack).
> Soweit ich mich erinnere, gab es auch weitere Probleme mit dem µC,> namentlich den Schaltregler.
Quelle/Link?
Bradward B. schrieb:> "Ernsthaft" benutzt hat das> security subsystem meines Wissens keiner,> Quelle/Link?
Dann kann man Dich zu den "schlecht informierten Kreisen" zählen ;-)
Sorry fürs Hochholen, aber hier scheint es am besten reinzupassen.
Der Fehler wurde, zusammen mit einigen anderen Dingen, in der aktuellen
Version behoben:
https://www.raspberrypi.com/news/rp2350-a4-rp2354-and-a-new-hacking-challenge/
Die vorhandenen A2-Controller werden wohl nicht mehr ausgeliefert – da
sich viele Anbieter allerdings größere Mengen ins Lager gepackt haben,
dürfte man derzeit vermutlich noch häufig Pico 2 mit der Version
erhalten, sofern beim Angebot nicht explizit auf einen Controller im
A4-Stepping hingewiesen wird.
Die Anmerkung am Ende des verlinkten Artikels ist auch interessant:
Unter bestimmten Bedingungen darf man die GPIOs des RP2350 nun offiziell
mit 5V beaufschlagen
Jack V. schrieb:> Sorry fürs Hochholen, aber hier scheint es am besten reinzupassen.
Nix Sorry, erstens gehört das genau hier hin und außerdem ist der Thread
nicht einmal 12 Monate alt. Hier werden doch auch 12 Jahre alte
wiederbelebt.
Dankeschön!