Forum: Mikrocontroller und Digitale Elektronik STM32 - GPIO's haben unterschiedliche Ausgangsspannung


von Dominik H. (Gast)


Lesenswert?

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

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

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?

von Tonja S. (Firma: SVK) (tonja_st)


Lesenswert?

Hast Du alle VCC und GND beschaltet? Oder vielleicht einen vergessen?

: Bearbeitet durch User
von Dominik H. (Gast)


Lesenswert?

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

von Stefan F. (Gast)


Lesenswert?

Bei mir kist das nicht so, da kommt bei moderater Belastung aus allen 
GPIO Pins annähernd 3,3V raus. Und der Low Pegel ist stets annähernd 0 
Volt.

von HildeK (Gast)


Lesenswert?

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.

von GEKU (Gast)


Lesenswert?

Dominik H. schrieb:
> alle GPIO's als Ausgänge konfiguriert und im Pushpull Mode auf
> High gesetzt.

Was hängt an den Ausgängen?

von Apollo M. (Firma: @home) (majortom)


Lesenswert?

HildeK schrieb:
> oder du gibst Pulse
> aus

klingt sehr wahrscheinlich und bedeutet gemessen werden die mittelwerte.
oszi ran und klarheit.

mt

von Junge (Gast)


Lesenswert?

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?

von Dominik H. (Gast)


Lesenswert?

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.

von Mampf F. (mampf) Benutzerseite


Lesenswert?

Vermutlich nicht auf Ausgänge geschaltet ...

Lad doch mal den Source-Code hoch :)

: Bearbeitet durch User
von Dominik H. (Gast)


Lesenswert?

Mampf F. schrieb:
> Lad doch mal den Source-Code hoch :)
gerne doch. Seltsam ist ja dass manche GPIO's funktionieren und manche 
nicht wirklich.
1
  //Anlegen der GPIO-Struct zur Initialisierung
2
  GPIO_InitTypeDef GPIO_InitStructure;
3
4
  //Systeminitialisierung (Systemtakte)
5
  SystemInit();
6
7
  //Takt für IO-Port B  aktivieren
8
  RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOB, ENABLE);
9
10
  //Initialisieren der GPIO_B
11
  GPIO_InitStructure.GPIO_Mode = GPIO_Mode_Out_PP;
12
  GPIO_InitStructure.GPIO_Pin = GPIO_Pin_0 | GPIO_Pin_1 | GPIO_Pin_2 | GPIO_Pin_5 | GPIO_Pin_8;
13
  GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz;
14
  GPIO_Init(GPIOB, &GPIO_InitStructure);
15
16
  //Bit setzen
17
  GPIO_SetBits(GPIOB, GPIO_Pin_0 | GPIO_Pin_1 | GPIO_Pin_2 | GPIO_Pin_5 | GPIO_Pin_8);

von Mampf F. (mampf) Benutzerseite


Lesenswert?

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?

von Beo Bachta (Gast)


Lesenswert?

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".

von NichtWichtig (Gast)


Lesenswert?

>   GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz;

Da würde ich mal 3 Nummer langsamer testen.

von Dominik H. (Gast)


Angehängte Dateien:

Lesenswert?

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

von A. F. (artur-f) Benutzerseite


Lesenswert?

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...

von A. F. (artur-f) Benutzerseite


Lesenswert?

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...

von Beo Bachta (Gast)


Lesenswert?

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.

von Dominik H. (Gast)


Angehängte Dateien:

Lesenswert?

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....

von Mampf F. (mampf) Benutzerseite


Lesenswert?

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^^

: Bearbeitet durch User
Beitrag #5926964 wurde vom Autor gelöscht.
von Dominik H. (Gast)


Lesenswert?

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.
1
#include "stm32f10x_conf.h"
2
#include <stdio.h> // used for printf
3
4
5
int main(void)
6
{
7
  //Anlegen der GPIO-Struct zur Initialisierung
8
  GPIO_InitTypeDef GPIO_InitStructure;
9
10
  //Systeminitialisierung (Systemtakte)
11
  SystemInit();
12
13
  //Takt für IO-Port B  aktivieren
14
  RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOB, ENABLE);
15
16
  //Initialisieren der GPIO_B
17
  GPIO_InitStructure.GPIO_Mode = GPIO_Mode_Out_PP;
18
  GPIO_InitStructure.GPIO_Pin = GPIO_Pin_0 | GPIO_Pin_1 | GPIO_Pin_2 | GPIO_Pin_5 | GPIO_Pin_8;
19
  GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz;
20
  GPIO_Init(GPIOB, &GPIO_InitStructure);
21
22
  //Bit setzen
23
  GPIO_SetBits(GPIOB, GPIO_Pin_0 | GPIO_Pin_1 | GPIO_Pin_2 | GPIO_Pin_5 | GPIO_Pin_8);
24
  
25
  
26
  
27
  while(1)
28
    {
29
    }
30
31
}

von Johannes S. (Gast)


Lesenswert?

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.

von Christopher J. (christopher_j23)


Lesenswert?

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.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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?

: Bearbeitet durch Moderator
von Beo Bachta (Gast)


Lesenswert?

Christopher J. schrieb:
> Joa, da ist halt bei deinem Board alles dabei.

Ich sag's ja ...... Pfusch am Bau ....

von Christopher J. (christopher_j23)


Lesenswert?

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.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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.

von Christopher J. (christopher_j23)


Lesenswert?

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.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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.

: Bearbeitet durch Moderator
von Christopher J. (christopher_j23)


Lesenswert?

Frank M. schrieb:
> Ich habe auch nicht behauptet, dass Du das gesagt hast. Aber der TO
> hat's geschrieben:

Ah, sorry. Hatte ich missverstanden.

von Heiko (Gast)


Lesenswert?

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.

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.