STM32: DMA vs. RAM check (beim Debug)

[Lasse S. (cowz)]

Hallo,

ich benutze einen STM32(F103RB), mit dem ich per ADC einen Kanel sample 
(continous) und die Sample per DMA ins RAM lade.

Nun ist es so, dass ich dadurch beim Debuggen (Eclipse, JLink EDU per 
GDB) Probleme bekomme. Das Log vom GDB-Server ist im Anhang. Folgende 
Zeile sind vermutlich wichtig:

ERROR: Failed to prepare for programming.
Readback during RAM check failed at offset 0x65C: Expected 62, Found  FE.

0x65C ist laut Mapfile der Buffer, in den ich per DMA kopiere.

Ich vermute also:
Der ADC läuft samt DMA munter weiter und verändert so den RAM-Inhalt und 
lässt somit den RAM check fehlschlagen (irgendwie ja logisch, wenn sich 
da was verändert).

Wie kann ich diesen Fehler beheben? Gibt es irgendwelche Debuggerbefehle 
(GDB, Jlink), mit denen ich alles stoppen kann?

Ich habe bereits "monitor halt" versucht, aber das hilft nicht.

Gruß
Lasse
PS: Alle fehlenden Informationen bitte erfragen, ich reiche gerne nach, 
sollte ich was vergessen haben :)

[(prx) A. K. (prx)]

Wenn der ADC nicht autark läuft, sondern über einen Timer getriggert 
wird, dann geht das. Denn die Timer lassen sich so einstellen, dass sie 
beim Debugging zusammen mit dem Core stehen bleiben (siehe DBGMCU_CR).

[Lasse S. (cowz)]

Mhh, also hier meine komplette Situation:

Ich starte den ADC, lasse dann im DMA-TransferComplete IRQ den ADC 
anhalten und setze ein "Fertig"-Flag.

In der Hauptschleife warte ich auf das Flag, stelle den ADC-Kanal um und 
starte ihn wieder*.

So geht das ganze Spiel immer munter im Kreise.


Da ich also davon ausgehe, dass ich nur darauf warten muss, bis der eine 
ADC-Durchlauf fertig ist, würde mir ja hier schon ein "wait" helfen, das 
scheint es bei GDB aber nicht zu geben, oder?

Aber prinzipiell ist das ja doch schon etwas doof, oder sehe ich das 
falsch? Ich hab bisher gehofft, dass alles aus ist, sobald ich debugge.

Gruß
Lasse

* Ich lese einen Touchscreen aus, der Scheduler kommt also nicht in 
Frage.

[Lasse S. (cowz)]

Gibt es denn tatsächlich keine Lösung dafür?

Es kann doch nicht sein, dass das Debuggen so erschwert wird, sobald man 
mit DMA arbeitet?

Lässt sich bspw. der RAM-Check ausschalten?

Gruß
Lasse

[Robert T. (robertteufel)]

Lasse,
die DMA ist dazu da unabhaengig in Echtzeit zu laufen. Debuggen sollte 
ebenfalls zum groessten Teil in Echtzeit ablaufen, also Breakpoint 
setzen und dann los geht's
Single Step ist das Gegenteil von Echtzeit und muss sich damit 
zwangslaeufig mit DMA ins Gegehege kommen.
Beschreib doch mal etwas genauer was Du mit debugging meinst?

Zu Deinem Thema "wait". Das laesst sich natuerlich einfach in software 
regelen. Warte bis das Flag gesetzt ist, dann einen Dummy-Befehl und auf 
den Dummy-Befehl setzt Du den Breakpoint.
hth, Robert

[Lasse S. (cowz)]

Hallo,

es geht mir weniger um's debuggen, das funktioniert. (Autsch, ich hab 
wirklich debuggen geschrieben, Mist verdammter...).

Das Problem ist beim Downloaden des Programmes.

Tut mir leid, das hab ich total verpeilt. Ich hab mir in Eclipse nur 
einen Butten "Load and Debug" eingerichtet, vermutlich hatte ich daher 
"Debug" im Kopf.


Also, das Problem tritt beim Programmieren auf.


Entschuldigende Grüße
Lasse