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.
Falschen Pin in AF konfiguriert? Die meisten STM32 erlauben mehrere Pins auf den UART zu legen. Aber du schreibst ja nicht, welchen du benutzt.
Gast
#7087123
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.
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.
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).
Gast
#7087146
Marvin K. schrieb: > Hier ist meine main.c stm apprentice schrieb: > Da muss "man" schon wenigstens mal sein *.ioc File herzeigen.
Gast
#7087154
MX_DMA_Init() muss vor die UART Init in der main() aufgerufen werden.
Hier ist die ioc Datei, aber ich dachte die enthält nichts was nicht auch in der main.c und dem Datenblatt enthalten ist.
Guest schrieb: > MX_DMA_Init() muss vor die UART Init in der main() aufgerufen werden. Wird sie doch:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
Wurde so von der IDE erzeugt.
Gast
#7087160
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.
Mal davon abgesehen ich nutze für Transmit ja garkein DMA.
Gast
#7087167
Wäre es nicht besser für ein großes Projekt separate .h/.c Dateien zu nutzen?
Mache ich auch, ich habe sie hier nur weggelassen und ihren Aufrug auskommentiert um nur den für das Problem relevanten Code zu zeigen.
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.
Gast
#7087264
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.
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.
Gast
#7087273
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.
Angehängte Dateien:
-
2022-06-04_19-55.png
110 KB
Gast
#7087298
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.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.