STM32F1 HAL UART Senden nicht

... schrieb:
> Um dem UART Zeichen zu entlocken, muss man ca. 5 bis 6 Register setzen.

Er hat eine MX_USART3_UART_Init().
Macht die was falsch?

Martin K. schrieb:
> Was übersehe ich? Fehlt was? Warum wird nichts gesendet?

Bist du sicher, daß dein Programm überhaupt geladen wird und läuft?

Kannst du reinsteppen?

Ich geh schon davon aus dass das Programm korrekt übertragen wird - 
hatte das Oszi vor dem Programmieren schon immer an dem entsprechenden 
Pin, da war er Low. Nach dem aufspielen ist der dann auf High gegangen.
Durch das Programm kann ich steppen. HAL_UART_Transmit kommt zurück mit 
HAL_OK. Die Fehler (HAL_BUSY oder HAL_TIMEOUT) werden nicht ausgelöst.

Du musst die Clock der UART irgendwo anschalten, passiert das?

bspw (weiß nicht ob das auf dem F1 auch so ist, bei dem H7 den ich 
aktuell am Wickel habe sieht das so aus):

1

__HAL_RCC_USART3_CLK_ENABLE();

Das passiert in der void HAL_UART_MspInit(), aufgerufen durch 
HAL_UART_Init(). Bin auch schonmal die Initialisierung durchgegangen wie 
sie in der HAL Doku angegeben ist. Das sieht soweit alles gut aus.
Andere Funktionen wie z.b. Timer im Output Compare, mit DMA oder Timer 
PWM mit DMA funktionieren auch tadellos. Nur der UART hat so gar keine 
Lust.

Da würde ich vielleicht mal schnell ein anderes Programm generieren 
lassen (geht ja fix mit CubeMX) und damit nur den GPIO blinken lassen. 
Dann sieht man schon mal, ob es HW-mäßig geht.
Ich kenne dein Board nicht, mit den nucleos und anderen Dev-Boards hatte 
ich da bisher keine Probleme.

@Klaus:
Das Board schein i.O., ein anderes Programm für WS2812 LEDs gibt sauber 
Signale raus, auch das stepper-Programm (wofür ich die UART 
Schnittstelle brauche) gibt die Stepper-Pulse aus.

Im Anhang der gewünschte Report.

Ich sehe da irgendwie keinen Fehler.

Du bist sicher, daß du am richtigen Pin misst?
(PC10, nicht PC11?)

Außerdem gibst du nur einmalig am Anfang aus, das ist vielleicht etwas 
schwer zu erwischen.
In der Schleife hättest du viel Zeit, etwas zu sehen.

Ja, messe an PC10. PC11 ist low. Ich hab das Scope auf Single-Shot 
gestellt und auf steigende Flanke die beim Reset entsprechend ausgelöst 
wird. Der TX Pin geht im Reset auf Low. In den 2sek danach ist nichts 
auf dem Bild zu sehen. Werde das aber mal in die Schleife packen und mit 
einem 200ms delay immer neu senden.

Wenn du auf dem Scope 2 Sekunden siehst, sind die 5 Byte aber ziemlich 
kurz im Vergleich dazu bei 115200 baud.
Das ist schon ein sehr dünner Strich...

Großer Speicher und scrollen machts möglich :)

Aber es geht jetzt... auch mit dem einzelnen gesendeten string. Mit dem 
Originalcode von oben. Ich glaube irgendwas stimmt in meiner Toolchain 
nicht. Entweder das Programm wird nicht sauber übertragen, oder der 
Flash nicht sauber gelöscht, oder sonst was läuft schief. Keine Ahnung.

Nachdem jetzt die anderen Programme nochmal drauf waren ist das Signal 
jetzt so wie es soll. Welch ein Spaß...


Ich danke euch! Jetzt hab ich die Bestätigung dass der Code korrekt ist 
und der Fehler irgendwo anders liegen muss.

Edit: Nochmal wegen dem Scope: Ich habe auf 500ms/div aufgezeichnet und 
dann auf 500µs rein gezoomt. 24M Speicher helfen da so ein einzelnes, 
wenn auch kurzes, Signal zu finden.

Der String:

1

char data[5] = "test\n";

belegt 6 Zeichen im Speicher und nicht 5!
Am Ende hängt noch eine 0 als Terminierung.
Der Rest sieht korrekt aus.

Harry L. schrieb:
> Der String:char data[5] = "test\n";
>
> belegt 6 Zeichen im Speicher und nicht 5!
> Am Ende hängt noch eine 0 als Terminierung.

Das Nullbyte wird nur angehängt, wenn noch Platz dafür ist.
Die Ausgabe rennt also weiter, bis irgendwann eine 0 gefunden wird.
Es kann aber auch sein, daß eine Exception erfolgt und der Code 
terminiert.
D.h. es wird nichts gesendet.