Announcement: there is an English version of this forum on |
Datum:
|
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:
RCC->AHBENR |= RCC_AHBENR_DMA1EN; DMA1_Channel3->CCR = DMA_CCR3_PSIZE_1 | DMA_CCR3_DIR; DMA1_Channel3->CNDTR = 0; // ... |
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
|
Datum:
|
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
|
Datum:
|
Bei sowas hilft es auch immer mal in das ERRATA zu schauen.
|
Autor:
Frank M.
(ukw)
(Moderator)
Datum:
|
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).
|
Datum:
|
Na Klasse :-/ Also wieder einmal Raterei. Ich hab selten so ein kaputtes Entwicklungsumfeld gesehen, wie rund um ARM, irgendwie.
|
Datum:
|
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.
|
Datum:
|
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.
|
Datum:
|
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.
|
Datum:
|
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.
|
Datum:
|
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...
Thread beobachten
Seitenaufteilung abschalten