STM32L1: USART Tx (und Rx) mit DMA funktioniert nur sporadisch

[Chris (Gast)]

Ich habe versucht diese (Beitrag "STM32F4 - USART3 Rx und DMA will nicht") 
USART + DMA Implementierung vom STM32F4 auf meinem STM32L151 zu 
übertragen, allerdings eher schlecht als Recht... Primär geht es mir 
dabei um das Versenden, den Empfangsteil habe ich noch gar nicht weiter 
getestet

Im Anhang der Beispielcode an welchem ich das Prinzip verstehen will, es 
meiner Meinung nach auch bereits verstanden habe aber mir nicht erklären 
kann warum es trotzdem nicht funktioniert. Der Code (z.B. das delay) ist 
nicht schön aber ist ja nur zum Test.

Ich verstehe das so: Ins CNDTR Register (Anzahl der Bytes die noch 
gesendet werden müssen) schreibe ich eine Zahl, z.B. 17 da mein Array 
maximal so viele Zeichen enthalten kann. Der DMA beginnt danach von der 
eingestellten Anfangsadresse (&sendingUSART) die Daten über USART 
rauszuschreiben und erhöht die Speicheradresse 17 mal und reduziert 
CNDTR dabei, bis das Ende des Arrays erreicht ist. CNDTR steht damit auf 
0, was ich danach über DMA_GetCurrDataCounter(DMA1_Channel7) auslesen 
könnte. Setze ich nun CNDTR wieder beginnt das Spiel von vorne, oder?

In der Main-Schleife beschreibe ich ein char Array mit 17 Zeichen mit 
unterschiedlichen Werten. Diese werden dann an ein anderes Gerät 
geschickt, dass die Zeichen - je nach Parameter LV oder AL - auf einem 
Display anzeigt. Das ganze ist ohne DMA schon ausgiebig getestet, das 
Problem muss also bei meiner USART/DMA Implementierung liegen...

Anfangs wurden zwar Nachrichten verschickt, aber scheinbar willkürlich 
nur eine der beiden. Es wurde also für 5 Sekunden nur der LV Wert neu 
gesendet, das Senden des AL Wertes zwar aufgerufen aber eben nicht 
verschickt. Danach ging es mal wieder ein paar Sekunden andersrum 
weiter. Aktuell kommt auf meinem Display leider gar nichts mehr an und 
so langsam bin ich auch blind für den Code -.-

[Chris (Gast)]

keiner ne Ahnung oder zumindestent schon mal damit zu tun gehabt?

[Uwe B. (Firma: TU Darmstadt) (uwebonnes)]

Haengt dich mit dem Debugger in dein Programm. Dur wirst iregendein bit 
falsch oder nicht setzten. Das ist aus der Ferne nicht zu debuggen...

[Epoxyd H. (fr4)]

Hallo Chris,

laufe gerade in das selbe Problem.
Hattest du eine Lösung gefunden?

[Dirk K. (dekoepi)]

Haben die kleineren STM32F1xx möglicherweise ein UART-Problem?
Hatte das auf einen irgendwo miesen Aufbau meines China-Minimalboards 
geschoben, aber ein STM32F100 (dürfte dasselbe sein, was als L oder VL 
verkauft wird) zickt beim UART arg rum. Stabiles Auslesen und 
Beschreiben via Bootloader klappt nur <= 19200kbps. Alle anderen STM32 
hier machen da 57600kbps locker mit.

Nur so als Idee. Tempo runterregeln und gucken, ob auf einmal was geht.

Hintergrundgedanken: Da die Bausteine nur bis 24MHz spezifiziert sind, 
scheinen das Kerne zu sein, die in den Standardtests für STM32F103 
beispielsweise durchfallen und die 72MHz nicht sauber schaffen. Da ist 
es doch naheliegend, weitere Defekte in dem Baustein zu haben.

[Epoxyd H. (fr4)]

> Haben die kleineren STM32F1xx möglicherweise ein UART-Problem?

Scheinbar nicht. Bin bei dem Problem einen Schritt weiter gekommen. Will 
heißen jetzt geht´s.

Was war das Problem? Ich habe bislang immer mit Coocox (1.7.5) 
gearbeitet .(Bitte jetzt nicht über IDEs im allgmenien diskutieren) Dort 
mit den STMF1xx bis STM32F4xx. Nahezu ohne Probleme und ich bin mit 
Coocox zufrieden. In der Coocox 1.7.5 wurden aber bislang die Controller 
STM32L1xx nicht unterstützt, deshalb habe ich Coocox auf die neuesete 
Version 1.7.7 geupdatet. Coocox 1.7.7 läuft aber bei mir nicht stabil. 
(getestet auf 2 verschiedenen OS Win7Prof und Win8.1 jeweils in der 
64Bit-Verson)
Nachdem ich einen Tag den Fehler gesucht habe habe ich Coocox auf die 
Version 1.7.6 zurückgeschraubt. Seitdem funktioniert der Code.
Woran das liegt kann ich nicht sagen. Ich habe auch zu wenig Zeit tief 
in die Materie einzusteigen. Ich vermute aber einen geänderten 
StartUp-Code???

[Florian (Gast)]

Hallo,

ich hatte so ein Phänomen mal mit Keil µVision4. Dort war aber auch der 
Startupcode gleich. Warscheinlich ein Compilerfehler. Habs nie 
rausbekommen.
Bei solchen Fehler könnt ich k****n!

Gruß
Florian

[Falk B. (falk)]

@ Florian (Gast)

>Startupcode gleich. Warscheinlich ein Compilerfehler. Habs nie
>rausbekommen.
>Bei solchen Fehler könnt ich k****n!

Das ist das normale Schicksal aller Betatester. Take it or leave it.