STM32 UART transmit gibt kein signal aus

[Marvin K. (m_marvin)]

Ich habe einen STM32 mittels einer UART Schnittstelle mit meinem PC 
verbunden (RS232 mit dem MAX232).

Ich kann problemlos daten senden und auf dem STM32 empfangen.
Sobald ich daten senden will funktioniert es aber nicht mehr (keine 
Signaländerung am TX Pin).
Wenn ich HAL_UART_Transmit() nutze sollte es ja die CPU für entweder die 
Dauer des Timeouts oder die Dauer der Übermittlung der Daten blockieren.
Die Daten sind recht kurz und die CPU wird nicht merklich blockiert, 
also scheint es Daten senden zu können/wollen (Das Timeout läge bei ~5 
Sekunden) aber am TX Pin messe ich keine Signaländerung (Oszilloskop) 
nur beim Senden des PCs am RX Pin.
Ich habe alle 3 Varianten von Transmit ausprobiert, Blocking IT und DMA.

Keine sendet irgendwas über den TX Pin.
Zum empfangen nutze ich DMA.

Die Initialisierung des UART hab ich mit der STMCubeIDE gemacht (UART 
aktiviert, DMA aktiviert, UART global Interrupt aktiviert).
Was könnte das Problem sein, wenn Empfangen problemlos funktioniert?

Ich weis nicht wo ich nach einem Fehler suchen soll, es gibt nur den 
UART Init und den Startaufruf für die Übertragung.
Durch Breakpoints hab ich aus geprüft ob alles korrekt aufgerufen wird.

[Matthias S. (Firma: matzetronics) (mschoeldgen)]

Falschen Pin in AF konfiguriert? Die meisten STM32 erlauben mehrere Pins 
auf den UART zu legen. Aber du schreibst ja nicht, welchen du benutzt.

[stm apprentice (Gast)]

Marvin K. schrieb:
> Ich weis nicht wo ich nach einem Fehler suchen soll

Da muss "man" schon wenigstens mal sein *.ioc File herzeigen.
Eher aber das ganze Projekt.

[Marvin K. (m_marvin)]

Ich nutze den STMH743ZI2 mit UART5 an den Pins PB13 (TX) und PB12 (RX).
Die Pins wurden so automatisch zugewiesen als ich UART5 aktiviert habe.

Der Code vom Projekt ist etwas größer, aber aktuell mache ich nichts 
anderes als direkt nach dem Initialisieren von allem (und die 
Initialisierung wurde auch von der CubeIDE erstellt) HAL_UART_Transmit() 
aufzurufen und den Inhalt einer Variable die ich davor erstelle und mit 
einem String fülle zu senden.
Das Timeout liegt bei 10000 (10 Sekunden) aber es führt es sofort aus 
und fährt mit dem Rest weiter.

Ich versuche den Code zu vereinfachen (so das nur noch der hier 
relevante Teil enthalten ist) und lade es dann hier hoch.

[Marvin K. (m_marvin)]

Hier ist meine main.c
https://pastebin.com/2zPjGvwA

Es ist alles enthalten was aktuell auf dem STM32 Ausgeführt wird, 
auskommentierter Code ist auch auf dem STM32 auskommentiert (wird nicht 
ausgeführt/compilliert).

[stm apprentice (Gast)]

Marvin K. schrieb:
> Hier ist meine main.c

stm apprentice schrieb:
> Da muss "man" schon wenigstens mal sein *.ioc File herzeigen.

[Guest (Gast)]

MX_DMA_Init() muss vor die UART Init in der main() aufgerufen werden.

[Marvin K. (m_marvin)]

Hier ist die ioc Datei, aber ich dachte die enthält nichts was nicht 
auch in der main.c und dem Datenblatt enthalten ist.

[Marvin K. (m_marvin)]

Guest schrieb:
> MX_DMA_Init() muss vor die UART Init in der main() aufgerufen werden.

Wird sie doch:

...
  MX_TIM15_Init();
  MX_DMA_Init();  <--
  MX_UART5_Init();<--
  MX_TIM17_Init();
...

Wurde so von der IDE erzeugt.

[Guest (Gast)]

Sorry, zu spät gesehen, dass es um UART 5 und nicht 3 ging. Ich hatte 
mal, dass die CubeIDE fälschlicherweise den Aufruf der MX_DMA_Init() 
hinter den UART gelegt hat und dieser deshalb nicht mehr funktioniert 
hat.

[Marvin K. (m_marvin)]

Mal davon abgesehen ich nutze für Transmit ja garkein DMA.

[pegel (Gast)]

Wäre es nicht besser für ein großes Projekt separate .h/.c Dateien zu 
nutzen?

[Marvin K. (m_marvin)]

Mache ich auch, ich habe sie hier nur weggelassen und ihren Aufrug 
auskommentiert um nur den für das Problem relevanten Code zu zeigen.

[Marvin K. (m_marvin)]

Also ich habe jetzt nochmal rumprobiert, ich bekomme kein Signal über 
den TX Pin, egal was ich mache.

HAL_UART_Transmit blockiert aber nicht, es verhält sich so als ob es 
erfolgreich senden konnte.

IT und DMA funktionieren auch nicht, aber die entsprechenden Interrupts 
werden aufgerufen.

[Stefan F. (Gast)]

Probiere es doch erst mal ohne die HAL. Dabei lernst du die 
Funktionsweise des Mikrocontrollers besser kennen, und kannst danach die 
Doku der HAL besser verstehen.

[Marvin K. (m_marvin)]

Ich hab jetzt einfach mal einen andern UART genommen, und da 
funktionieren beide Pins.
Ich glaube ich habe einfach das Pech ein Nucleo mit einem defekten STM32 
erwischt zu haben ...
Ich kann mir sonst keine Erklärung vorstellen, warum der TX Pin von 
UART5 nicht funktioniert, aber die von UART3 UART4 und UART7 schon ...
Ich werde einfach mein Projekt auf einen anderen UART legen, dann sollte 
das Problem gelöst sein.
Und ich mache mir einen Aufkleber auf das Nucleo, das UART5 defekt zu 
sein scheint.

[Stefan F. (Gast)]

Marvin K. schrieb:
> Pech ein Nucleo mit einem defekten STM32

Wenn du nicht so sehr mit Informationen geizen würdest, hätte man dir 
viel schneller helfen können.

PB13 ist mit dem Ethernet Chip (PHY) verbunden.

Marvin K. schrieb:
> Und ich mache mir einen Aufkleber auf das Nucleo, das UART5 defekt zu
> sein scheint.

Lies lieber die gezeigte Doku, sonst wirst du noch auf einige andere 
vermeintlich kaputte Pins stoßen.

[stm apprentice (Gast)]

Marvin K. schrieb:
> Ich hab jetzt einfach mal einen andern UART genommen, und da
> funktionieren beide Pins.

Wenn man sich schon nicht auskennt (und das sieht man an deinem
*.ioc File) dann sollte man einfach erst mal die Defaults nehmen
die ein Nucleo H743 Board vorgibt. Ist ja ganz einfach in CubeMX.

Erstens sieht man dann sofort wenn man einen Pin benutzen will
der auf dem Board schon verdrahtet ist, und zweitens bekommt
man eine bereits gut optimierte Clock-Einstellung ohne herum-
experimentieren zu müssn.

Die Einstellungen die du gewählt hast verwenden einen HSI, und
das ist für viele Anwendungen nicht gerade optimal. Viel Jitter
und schlechte Temperaturstabilität.

Merke: Das Board kann mit HSE 8 MHz betrieben werden auch wenn
gar kein 8MHz Quarz bzw. Oszillator bestückt ist. Der Takt kommt
vom angehängten ST-Link.