JTAG bremst Cortex M3 aus?

[Arne (Gast)]

N'abend zusammen,

wir arbeiten mit IAR EWARM 5.50, den gelben J-Links von IAR und 
STM32F103VC. Kollege hat wohl heute folgende Erfahrung gemacht - hat er 
mir so berichtet: er hat einen Watchbreakpoint im IAR Debugger gesetzt, 
der anhält sowie eine Variable einen bestimmten Wert beinhaltet. Mit 
diesem gesetzten Breakpoint soll sich der µC zu (Pi mal Daumen) 50% 
ausgebremst haben, d.h. der Systick soll nur noch alle ~2ms (statt 1ms) 
gekommen sein, da Vorgänge auf einmal doppelt so lange wie ohne 
Breakpoint dauerten. (Wir nutzen z.B. die Softwaretimer aus embOS und 
das RTOS hängt bei uns im Systicktimer mit 1kHz).

Kann sowas sein? Ich bin bisher davon ausgegangen, dass JTAG transparent 
arbeitet und die ALU des µC nicht ausbremst. Bin ich da einer irrigen 
Meinung aufgesessen?

Gruß, Arne

[Strubi (Gast)]

Moin,

wenn du Breakpoints setzt, ist das ganze ja nicht wirklich 
"non-intrusive".
Bin jetzt kein Cortex-Experte, aber im Prinzip hältst du ja die CPU mit 
einem Break kurz an, liest irgendwas aus, und lässt die Kiste 
weiterlaufen. Ohne Bremse ginge das nur mit einer speziellen 
Watchpoint-Unit (in der CPU-Hardware).

Gruss,

- Strubi

[Olaf (Gast)]

> Ohne Bremse ginge das nur mit einer speziellen
> Watchpoint-Unit (in der CPU-Hardware).

Sowas kann man bei einer aktuellen CPU wohl vorraussetzen. Aber er will 
ja sogar einen Variableninhalt ueberwachen. Da muss man wohl damit leben 
das eine CPU damit deutlich langsamer wird wenn keinen speziellen 
CPU-Emulator hat.

Olaf

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

Strubi schrieb:

> Ohne Bremse ginge das nur mit einer speziellen
> Watchpoint-Unit (in der CPU-Hardware).

Und genau die gibt es.

[TTL (Gast)]

SW benutzen statt JTAG, dann kann man auch den Trace nutzen, zumindest 
mit Keil uLink

[Noname (Gast)]

Melde dich doch mal direkt bei Segger, wenn du Kunde von denen bist.
Bis jetzt habe die mir immer freundlich und kompetent bei jeder Frage 
weiter geholfen. Notfalls einfach direkt bei denen im Forum.

Der J-Link hält definitiv nicht die CPU an! Wenn das so wäre könnte man 
ja nur noch Singe steppen und müsste nach jedem Befehl die Variable 
vergleichen.

Der J-Link benutzt die interne Watchpoint Einheit des Cortex M3 und 
daher gibt es erstmal keinen Grund, wieso die Appliaktion dann langsamer 
laufen sollte.

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

Vorstellbar wäre, dass der Debugger bei Exceptions aktiv wird und mal 
kostenpflichtig nach dem Rechten sieht. Oder sowas in der Art.

Der CM3 Core scheint mir eigentlich nicht so komplex, dass man bei 
Watchpoints in einen langsameren Modus wechseln müsse um nichts zu 
verpassen. Aber wer weiss was der Debugger macht. Möglichkeiten gibts 
genug.

[Sascha (Gast)]

Also, ich teste den Cortex M3 gerade auch aus und meine Erfahrung hat 
gezeigt SWD ist um einiges schneller. Nur steht bei jeder IDE bzw. 
Debugger ein Script dahinter, was über JTAG oder SWD bei welcher 
Operation ablaufen soll, kann gut sein das der Core angehalten wird und 
ein ganzer RAM-Block ausgelesen wird. So viel ich gelesen habe wird beim 
Cortex M3 bei aktiver Debug Unit (DBU) sämmtliche Timer und RTC/Systick 
angehalten. Die Einheit ist ziemlich stark im CM3 verwurzelt. Dann ist 
IAR EWARM 5.50 nicht gerade die neuste Version, da sind ja eh noch die 
Erratas vom STM32F drin bzw. noch nicht behoben.

Dann mit welchem Speed leuft der J-Link ???
Es kann Fix 8000KHz bei JTAG und 4000KHz bei SWD eingestellt werden.
Im Menue JLINK Connection unter IAR.

Einfach über DOS die Datei JLINK.EXE aufrufen (zu finden im Verzeichniss 
BIN)
dann müsste über JTAG die CPU gefunden sein und folgendes eintippen
speed 8000
thg

speed 12000
thg

si 1 (umschalten auf SWD)
speed 4000
thg

so dann schau dir mal die Zeiten an, alles klar !?!

ansonsten bei Segger das neuste Update von der Homepage laden.

grüß Sascha