STM32F1: Wartezyklus nach Clock-Enable im RCC

[Nase (Gast)]

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

[Felix F. (wiesel8)]

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. (Gast)]

Bei sowas hilft es auch immer mal in das ERRATA zu schauen.

[Frank M. (ukw) (Moderator)]

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 (Gast)]

Na Klasse :-/ Also wieder einmal Raterei.

Ich hab selten so ein kaputtes Entwicklungsumfeld gesehen, wie rund um 
ARM, irgendwie.

[Dr. Sommer (Gast)]

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.

[Markus F. (mfro)]

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.

[Dr. Sommer (Gast)]

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.

[Nase (Gast)]

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.

[Dr. Sommer (Gast)]

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...