Hallo allerseits,
ich bin gerade dran einen STM32F103 zu programmieren. Nun habe ich
bemerkt, dass die einzelnen Pins teils sehr unterschiedliche
Ausgangsspannungen haben.
Es wurden alle GPIO's als Ausgänge konfiguriert und im Pushpull Mode auf
High gesetzt. An manchen Pins messe ich nun ca. 3,2V an anderen 2,4V,
2,6V teils sogar 1,5V. Versorgungsspannung ist 3,3V.
Wenn ich die GPIO's auf Low ziehen will, dann fällt mir auf dass auch
hier sehr große Unterschiede sind. Die GPIO's die eine hohe Spannung
liefern, kommen auch gut an die 0V heran und jene die 1,5V als High
haben, kommen gerade mal auf 0,5V runter.
Woran kann das liegen? Kann mir hier jemand weiterhelfen?
MfG Dominik
Dominik H. schrieb:> Kann mir hier jemand weiterhelfen?
Haben diese Pins, die du da ansprichst, auch Namen?
> Wenn ich die GPIO's auf Low ziehen will, dann fällt mir auf dass auch> hier sehr große Unterschiede sind. Die GPIO's die eine hohe Spannung> liefern, kommen auch gut an die 0V heran und jene die 1,5V als High> haben, kommen gerade mal auf 0,5V runter.
Wie hast du das gemessen?
> Es wurden alle GPIO's als Ausgänge konfiguriert und im Pushpull Mode auf> High gesetzt.
Und alle Bänke mit einem Takt versorgt?
Lothar M. schrieb:> Haben diese Pins, die du da ansprichst, auch Namen
ja, zum Beispiel gibt GPIO_Pin_0 und GPIO_Pin_1 die 3,2V aus und
GPIO_Pin_2 nur 2,4V.
Lothar M. schrieb:> Wie hast du das gemessen?
gemessen wurde mit einem normalen Multimeter
Lothar M. schrieb:> Und alle Bänke mit einem Takt versorgt?
ja, wurden sie.
LG Dominik
Dominik H. schrieb:> Es wurden alle GPIO's als Ausgänge konfiguriert und im Pushpull Mode auf> High gesetzt. An manchen Pins messe ich nun ca. 3,2V an anderen 2,4V,> 2,6V teils sogar 1,5V. Versorgungsspannung ist 3,3V.
Ohne den STM32 je in der Hand gehabt zu haben: das kann nicht sein!
Entweder hast du da eine zu große Last dran hängen oder du gibst Pulse
aus (Takte, PWM etc.) oder du hast sonst noch einen groben Fehler in der
Schaltung. Selbst die 3.2V (bei 3.30V Versorgung) sind für ein
statisches Signal ohne Last noch zu niedrig.
Auch: wer misst misst Mist.
Dominik H. schrieb:> Lothar M. schrieb:>> Haben diese Pins, die du da ansprichst, auch Namen> ja, zum Beispiel gibt GPIO_Pin_0 und GPIO_Pin_1 die 3,2V aus und> GPIO_Pin_2 nur 2,4V.
Am Port Gummibärchen?
Apollo M. schrieb:> HildeK schrieb:>> oder du gibst Pulse>> aus>> klingt sehr wahrscheinlich und bedeutet gemessen werden die mittelwerte.> oszi ran und klarheit.
Auf dem Oszi ist eine saubere Gleichspannung zu sehen. Also nichts mit
Pulsen oder PWM...
GEKU schrieb:> Was hängt an den Ausgängen?
Die Ausgänge sind unbelastet.
Junge schrieb:> Am Port Gummibärchen?
Nein, der Port Gummibärchen ist anderweitig belegt. Das Problem ist auf
allen Ports, hier speziell Port B.
Dominik H. schrieb:> Mampf F. schrieb:>> Lad doch mal den Source-Code hoch :)> gerne doch. Seltsam ist ja dass manche GPIO's funktionieren und manche> nicht wirklich.
Sieht in Ordnung aus - entspricht den eigentlich viel getesteten
Minimal-Beispielen, die man so im Netz findet.
Welche Hardware-Platform verwendest du?
Kannst du mal den kompletten C-Code hochladen?
Mampf F. schrieb:> Sieht in Ordnung aus
Naja, wenn danach noch zusätzliche Funktionen aktiviert
werden kann das ganze Port-Initialisieren dahin sein ...
Vielleicht sieht er das alles noch gar nicht.
Auch Stichwort "Alterate Functions".
Mampf F. schrieb:> Kannst du mal den kompletten C-Code hochladen?
Das ist eigentlich der komplette Code. Um genau diesem Problem auf den
Grund zu gehen habe ich extra ein neues Projekt erstellt in dem nichts
drin ist außer eben die GPIO's anzuschalten.
Mampf F. schrieb:> Welche Hardware-Platform verwendest du?
Verwendet wird das STM32-P103 Board von Olimex. Darauf läuft der
STM32F103RBT6
Beo Bachta schrieb:> Vielleicht sieht er das alles noch gar nicht.>> Auch Stichwort "Alterate Functions".
Der STM32f103 hat meines Wissens nach nach dem Reset die IO's als Prio,
außer die JTAG, RST und BOOT Pins villeicht...
Dominik H. schrieb:> Verwendet wird das STM32-P103 Board von Olimex. Darauf läuft der> STM32F103RBT6
Na dann kein Wunder, das Board hat jede Menge externe IC's etc. da würde
der Schaltplan helfen, um festzustellen warum die Pegel sich so
verhalten. Also, definitiv kein STM32 Problem, sondern...
Dominik H. schrieb:> Verwendet wird das STM32-P103 Board von Olimex.
Ja und? da hängt doch jede Menge Peripherie dran. Also
warum nicht an den Ausgängen die du benutzen willst?
A. F. schrieb:> kein STM32 Problem, sondern...
.. ein Problem vor der Tastatur und vor dem Bildschirm.
Beo Bachta schrieb:>> Verwendet wird das STM32-P103 Board von Olimex.>> Ja und? da hängt doch jede Menge Peripherie dran. Also> warum nicht an den Ausgängen die du benutzen willst?>> A. F. schrieb:>> kein STM32 Problem, sondern...>> .. ein Problem vor der Tastatur und vor dem Bildschirm.
Ich kann hier keinen Unterschied feststellen wischen funktionierenden
Pins und nichtfunktionierenden....
Dominik H. schrieb:> Das ist eigentlich der komplette Code.
Das kann nicht sein - da fehlen die includes, die main-Funktion, der
Code, der danach kommt usw :)
Poste mal bitte den gesamten Code - meistens ist der Fehler dort, wo man
nicht denkt, dass er sein könnte.
Vlt hast du ein while(1) {} am Ende vergessen und das Ding resettet sich
ständig selbst oder so ähnlich^^
Mampf F. schrieb:> Das kann nicht sein - da fehlen die includes, die main-Funktion, der> Code, der danach kommt usw :)
na gut da hast du natürlich Recht. Aber viel mommt da wirklich nicht
mehr. Noch minimalistischer kann ich es kaum gestalten.
ich würde da unbedingt noch ein GPIO_StructInit() vor dem setzen der
Struktur einbauen. Wenn da in einer neueren Lib Version weitere Member
hinzukommen sind die nicht initialisiert wenn die Variable auf dem Stack
liegt, da bin ich auch schon mal drauf reingefallen.
Wenn die GPIO_InitTypeDef nur die drei Member hat ist das in diesem Fall
ok, aber es ist gefährlich bei Updates.
Dominik H. schrieb:> GPIO_SetBits(GPIOB, GPIO_Pin_0 | GPIO_Pin_1 | GPIO_Pin_2 | GPIO_Pin_5 |> GPIO_Pin_8);
Joa, da ist halt bei deinem Board alles dabei. Angefangen von PB2, der
gleichzeitig Boot1-Pin ist und wo (vermtl. per Jumper wählbar) entweder
ein 100k Pull-Up oder 100k Pull-Down dranhängt, bis zu PB8, der als
CAN-TX am CAN-Transceiver hängt.
Dominik H. schrieb:> ja, zum Beispiel gibt GPIO_Pin_0 und GPIO_Pin_1 die 3,2V aus und> GPIO_Pin_2 nur 2,4V.
PB0 und PB1: 3,2V ist okay.
PB2 (auch BOOT1) hängt laut Deinem Schaltplan an einem Jumperfeld, um
den Boot-Mode einstellen zu können. Vermutlich ist da sogar ein Jumper
(0 Ohm zu GND) gesteckt, um definiertes Potential beim Booten zu haben.
Sicher, dass der Schaltplan korrekt ist und da wirklich 100k als
Widerstand dran hängen? Was ist, wenn Du den Jumper nach dem Booten
abziehst? Ändert sich die Ausgangsspannung?
Kannst Du weitere Pins nennen, die "nicht funktionieren" (inkl.
Spannungsangabe!) oder muss man jetzt eine Salami-Scheibe nach der
nächsten bei Dir erfragen?
Beo Bachta schrieb:> Ich sag's ja ...... Pfusch am Bau ....
Jepp, ein typischer Fallstrick bei solchen schlüsselfertigen Dingern.
Auch oft bei Discovery-Boards gesehen.
Christopher J. schrieb:> vermtl. per Jumper wählbar
Hab mich geirrt. Auf dem Bild von deinem Board ist eine Lötbrücke zu
sehen (rechts vom STM32), die als B1_L konfiguriert ist, also wohl 100k
Pull-Down. Vielleicht haben sie auch einen anderen Widerstand als 100k
verlötet. Normalerweise sollte der STM32 in Push-Pull-Konfiguration
gegen einen 100k Pulldown mehr als 2,4V schaffen (bei 3,2V VCC). Kannst
ja per Multimeter im ausgeschalteten Zustand mal den Widerstand zwischen
PB2 und GND messen.
Christopher J. schrieb:> Auf dem Bild von deinem Board ist eine Lötbrücke zu sehen
Wenn man sich den Schaltplan anschaut, gibt es da jede Menge Lötbrücken.
Die können nicht alle offen sein. Die Aussage, "alle Pins auf allen
Ports" wären unbelastet, stimmt wahrscheinlich so pauschal gesehen
nicht.
Frank M. schrieb:> Wenn man sich den Schaltplan anschaut, gibt es da jede Menge Lötbrücken.> Die können nicht alle offen sein.
Schon klar. Die Lötbrücke die ich meinte ist ja jene, die den Boot1 Pin
betrifft und das ist mutmaßlich die, die mit B1_H/B1_L beschriftet ist.
Die ist als "B1_L" konfiguriert bzw. geschlossen, d.h. laut Schaltplan
100k Pull-Down an PB2.
Frank M. schrieb:> Die Aussage, "alle Pins auf allen Ports" wären unbelastet, stimmt> wahrscheinlich so pauschal gesehen nicht.
Das habe ich auch nie behauptet. Ganz im Gegenteil: Der CAN-Transceiver
wird sogar aktiv gegen PB8 arbeiten.
Christopher J. schrieb:> Das habe ich auch nie behauptet. Ganz im Gegenteil: Der CAN-Transceiver> wird sogar aktiv gegen PB8 arbeiten.
Ich habe auch nicht behauptet, dass Du das gesagt hast. Aber der TO
hat's geschrieben:
Dominik H. schrieb:> Die Ausgänge sind unbelastet.
P.S.
Ich halte auch den Versuch, sämtliche Pins von allen Ports global auf
Ausgang zu schalten, ziemlich unsinnig. Das kann man zwar mit einem
nackten µC machen, aber nicht mit einem µC auf einem Dev-Board.
Natürlich haben da Bauteile des Dev-Boards Kontakt mit einigen Pins.
Sonst wäre das Board ziemlich überflüssig.
Ich hatte das identische Problem auch gerade mit einem STM32F103vet6
minimum Board. Habe das Programm auch komplett nackt gemacht und nur die
GPIOs programmiert.
Der Controller war frisch aus der Verpackung. Hab dann einen anderen
frischen genommen und es ging. Ich nehme an, wenn ich nur 8€ für so ein
Board ausgebe, dass ich dann mit schlecht gefertigten Boards rechnen
muss wo evtl. irgendwelche Kurzschlüsse oder Ähnliches sind.
