Hallo,
ich experimentiere gerade mit der DMA-Einheit auf meinem
STM32F103-Evalboard.
Im Debugger klappt alles, in Echt schreibt die DMA wild im Speicher
herum.
Mir ist aufgefallen, dass bei der DMA im CR1 das DIR-Bit, welches ja
festlegt, ob von Peripherie nach RAM oder umgekehrt kopiert werden soll,
gelöscht ist. D.h., die DMA schreibt tatsächlich im RAM herum.
Selstsam daran ist, dass ich dieses Bit bei der Initialisierung gesetzt
habe:
1
RCC->AHBENR|=RCC_AHBENR_DMA1EN;
2
DMA1_Channel3->CCR=DMA_CCR3_PSIZE_1|DMA_CCR3_DIR;
3
DMA1_Channel3->CNDTR=0;
4
// ...
Wenn ich im Debugger durchsteppe, ist das Bit im Register auch
tatsächlich gesetzt. Wenn ich das Programm aber durchlaufen lasse und
hinter der Initialisierung anhalte, ist das Bit nicht gesetzt.
In einem der HAL-Headerdateien von ST finde ich folgende Notiz:
> A delay between an RCC peripheral clock enable and the effective> peripheral enabling should be taken into account in order to manage> the peripheral read/write from/to registers.> (+) This delay depends on the peripheral mapping.> (++) AHB & APB peripherals, 1 dummy read is necessary
Und tatsächlich funktioniert alles wieder, wenn ich hinter die Zeile mit
dem RCC->AHBENR ein DSB oder ein NOP einfüge...
Die Notiz in der HAL-Headerdatei finde ich weder im Reference Manual,
noch im Erratum (sie steht aber im Erratum einiger Prozessoren aus der
F4-Reihe).
Ist das nun Pech oder hab ich was überlesen?
Danke und Grüße,
N
Hatte mal das gleiche Problem mit einem F1. Mit Debugger funktionierte
DMA, ohne nicht. Lösung war dann bei mir auch, eine for-Schleife am
Anfang der main() einzubauen, die nur ein bisschen Zeit vertrödelte. Als
IDE habe ich Crossworks verwendet.
Hab dann denn Code in EmBitz kopiert (welches andere Startup Files
benutzt) und hier funktionierte es ohne Probleme.
mfg
Curby23523 N. schrieb:> Bei sowas hilft es auch immer mal in das ERRATA zu schauen.
Bei sowas hilft es auch immer mal in den Beitrag des TO zu schauen:
Nase schrieb:> Die Notiz in der HAL-Headerdatei finde ich weder im Reference Manual,> noch im Erratum (sie steht aber im Erratum einiger Prozessoren aus der> F4-Reihe).
Nase schrieb:> Ich hab selten so ein kaputtes Entwicklungsumfeld gesehen, wie rund um> ARM, irgendwie.
Wie viele Architekturen kennst du denn, die noch mehr und bessere
Compiler, IDE's, Debugging-Tools, Vielfalt an Controllern, ... haben?
Klar hat die Doku diverse Lücken, aber das bleibt bei derart komplexen
Systemen nicht aus... Und sowas wie DSB ist für effiziente Architekturen
nunmal nötig.
Nase schrieb:> Ich hab selten so ein kaputtes Entwicklungsumfeld gesehen, wie rund um> ARM, irgendwie.ARM definiert kein DMA, das hat ST verbrochen. Ehre, wem Ehre gebührt.
Markus F. schrieb:> ARM definiert kein DMA, das hat ST verbrochen. Ehre, wem Ehre gebührt.
Das hat mit DMA nix zu tun, das liegt an der Bus-Struktur und der
Tatsache, dass der Prozessor schneller als der Bus ist. Wäre das nicht
so, wäre entweder der ganze Controller schnell (und damit teuer) oder
der Prozessor langsamer.
Dr. Sommer schrieb:> Wie viele Architekturen kennst du denn, die noch mehr und bessere> Compiler, IDE's, Debugging-Tools, Vielfalt an Controllern, ... haben?
Einige, aber ob das Umfeld da besser ist... will ich ja garnicht
behauptet haben.
Es ist angesichts dessen, dass ARM quasi überall Dauerbrenner ist,
einfach irgendwie frustrierend.
Und es ist erschreckend, wie wackelig das alles ist. Selbst in
einschlägigen Support-Foren (ST!) kriegt man viel zu häufig Antworten,
bei denen auch nur solange herumprobiert wurde, bis es irgendwie lief.
Ich mein, man sieht ja schon an den Registern, wie z.B. bei den STM32
die Peripherie zusammenkopiert wurde: In fünf verschiedenen
Peripherie-Teilen gibts fünf verschiedene Wege, ein Interruptflag zu
löschen. Aber bei der Dokumentation hatte man wohl endgültig die Lust
verloren. Oder es war kurz vor Feierabend.
Nase schrieb:> Und es ist erschreckend, wie wackelig das alles ist.
Wackelig würde ich jetzt nicht sagen. Eher unübersichtlich.
Nase schrieb:> Selbst in> einschlägigen Support-Foren (ST!) kriegt man viel zu häufig Antworten,> bei denen auch nur solange herumprobiert wurde, bis es irgendwie lief.
Das sind ja auch meistens nur User. Für professionellen Support muss man
professionell bezahlen...
Nase schrieb:> Ich mein, man sieht ja schon an den Registern, wie z.B. bei den STM32> die Peripherie zusammenkopiert wurde:
Die Komponenten sind halt zugekauft. Das machen viele so; auch nicht
jede Schraube in einem VW stammt aus einem VW-Werk. Durch solche
Wiederverwendung wird's billiger.
Nase schrieb:> Aber bei der Dokumentation hatte man wohl endgültig die Lust> verloren. Oder es war kurz vor Feierabend.
Die Doku von ST gehört noch zu den Besseren. Bei anderen Anbietern kann
man froh sein wenn man überhaupt Doku bekommt und die nicht auf
Chinesisch ist.
Wenn alles perfekt einfach wäre könnt's ja jeder...
Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.
Wichtige Regeln - erst lesen, dann posten!
Groß- und Kleinschreibung verwenden
Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang
Announcement: there is an English version of this forum on 
Thread beobachten
Seitenaufteilung abschalten