µController RAM lesen/schreiben via JTAG

[Tobias Weber (Gast)]

Hallo zusammen,

ich würde gerne über den JTAG Port eines µControllers, im laufenden 
Betrieb, lesend und eventuell schreibend auf dessen RAM zugreifen. Ich 
hab dazu bisher nur diese Bibliothek gefunden:

http://openocd.org/

Das sieht vielversprechend aus, ich wollte aber vorher sicher gehen ob 
ich nicht eventuell etwas übersehen habe. Kennt sich mir der Thematik 
jemand aus und weis ob für solche Zugriffe auf einen µController über 
JTAG standardisierte Verfahren gibt die ich übersehen habe? Oder ist das 
openOCD Projekt hier die beste Lösung?

Vielen Dank und Gruß
Tobi

[Jim M. (turboj)]

Du VT hast vergessen uns den genauen Controller Typ mitzuteilen.

Bei ARM kann man via OpenOCD Peripherie-Register und Speicher im 
laufenden Betrieb auslesen, BTDT. Aber längst nicht alle µC 
Architekturen erlauben das überhaupt.

[Tobias Weber (Gast)]

oops

entschuldige, es handelt sich dabei um einen MPC5774N von Freescale/NXP

https://www.pls-mc.com/power-architecture-mpc57xx-microcontrollers-from-nxp/architecture-a-948.html

Das hier sollte die Serie sein.

[Strubi (Gast)]

Moin,

Tobias Weber schrieb:
> ich nicht eventuell etwas übersehen habe. Kennt sich mir der Thematik
> jemand aus und weis ob für solche Zugriffe auf einen µController über
> JTAG standardisierte Verfahren gibt die ich übersehen habe? Oder ist das
> openOCD Projekt hier die beste Lösung?

Wenn Du es kostenlos/opensource haben willst und viel Zeit fürs Frickeln 
hast, ja. Ansonsten ist da oft, obwohl Standard drübersteht, oft keiner 
drin. Betr. deines Kontrollers kann ich leider keine Aussagen machen, 
musst du jeweils ausprobieren. Beim einen Chip läufts tadellos, beim 
andern kannst du jegliche Robustheit vergessen, dann kommt noch die 
Spaghettiarchitektur von OpenOCD und die Timing-Charakteristiken der 
jeweiligen JTAG-Controller dazu. Würde da ausschliesslich auf 
FTDI-basiertes zurückgreifen.

[Tobias Weber (Gast)]

Danke dir,

es gibt für solche Sachen einen Standard? Ich bin noch nicht so tief 
genug in der Materie drin, allerdings meine ich rausgelesen zu haben 
dass Debugging (RAM lesen/schreiben) keine der zentralen Aufgaben von 
JTAG sind. Deshalb war/ist mir nicht klar ob und wie weit das 
standardisiert ist.

Ich denke am Ende macht ein Debugger ja etwas ähnliches (im größeren 
Stil) wie das was ich vorhabe. Ist dieser Standard dann immer von der 
Architektur der Prozessors abhängig
(sollte ich mich für genauere Informationen an den Hersteller wenden? 
Oder sind solche Infos frei verfügbar (Lauterbach zb hat ja Zugriff 
drauf))
oder wurde da eventuell von IEEE was standardisiert und alle halten sich 
daran?

Ich hatte überlegt ob ich mir die IEEE 1149.1 hole aber ich bin mir 
nicht sicher ob dort auch genau das drin steht was ich benötige.

Es muss nicht zwingend kostenlos sein, Zeit ist auch Geld. Der Aufwand 
sollte sich aber wenn möglich im Rahmen halten.

Gruß,
Tobi

[Strubi (Gast)]

Hi Tobias,

IEEE 1149.* spezifiziert im Groben nur die JTAG-State-Machine, das 
kannst du dir schenken. Ist wie bei SPI. Was dahinter an 
Instruction/Data-Registern implementiert ist, ist herstellerspezifisch, 
bei ARM ist inzwischen etwas interne Standardisierung drin (wie z.B. 
CoreSight).
Debugging ist eigentlich schon die zentrale Aufgabe von JTAG. Kannst 
eigentlich typischerweise die Funktion einteilen in:
- In Circuit Emulation (ICE), Debug
- Boundary Scan Tests (HW-Test in der Produktion, Programmierung)

Lauterbach macht m.W. nach wie vor recht schwerfällig/altmodische 
Trace-Geschichten, die mit CoreSight längst passé sein sollten, aber für 
deine Architektur (ist ja kein ARM, ne) ev. noch relevant sein können. 
Hängt halt von deiner Debug-Strategie ab. Mit ICE kommt man immer 
irgendwie ans Memory ran, muss aber die CPU anhalten.
Typischerweise übernehmen die Hersteller die JTAG-Cores zur Anbindung, 
aber bauen auch mal spezifische Sachen ein, dementsprechend eben der 
Wildwuchs. Und nach meiner Erfahrung geben die Hersteller die Details 
nicht gerne her, die Specs fallen meistens nur irgendwo für unsereiner 
vom Laster, ergo hast du dann teils Glück, die Umsetzung davon in einem 
von vielen OpenOCD forks zu finden.

[Tobias Weber (Gast)]

Hi,

das hilft mir weiter!
Leider ist das kein ARM Controller, ich schaue mal die Sache mit dem ICE 
ein wenig genauer an. Danke dir soweit.

Gruß,
Tobi