Bootloader debugger mit JTAG

[Olli Z. (z80freak)]

Ich frage mich wie ich mittels JtAG den Bootvorgang eines uC 
schrittweise durchlaufen kann? Gibt es eine Möglichkeit einen Breakpoint 
gleich auf Adresse 0x0000 einzustellen und wie soll der "halten" wenn 
der Chip resettet wird?

[Bernd (Gast)]

Olli Z. schrieb:
> eines uC
Welcher genau?

[Olli Z. (z80freak)]

Ups, ich dachte ich frag eher mal so allgemein, z.B. für ARM7 CPUs :-)

[Bernd (Gast)]

Olli Z. schrieb:
> ARM7
Ok. Da sollte man über JTAG die CPU resetten, starten und stoppen 
können.
Die Hardwarebreakpoints gibt es i.d.R. zusätzlich noch.

Olli Z. schrieb:
> 0x0000
Bei ARM7 steht da eher 0x00000000

[Dr. Sommer (Gast)]

ARM Prozessoren unterscheiden nicht zwischen Bootloader und Kernel. 
Lediglich Exceptions und Userspace Programme werden in eigenen Modi 
ausgeführt. Software in allen Modi kann aber über JTAG/SWD debuggt 
werden. Der Code startet aber nicht unbedingt bei 0. Nur der "sichere" 
Code bei TrustZone Prozessoren kann vermutlich nicht debuggt werden.

[Olli Z. (z80freak)]

Gut, die MCU/SoC die ich im Blick habe, haben "auch" eine ARM CPU mit 
"D" im Namen (z.b. TDMI) lassen sich also grundsätzlich debuggen.

Aber darüber hinaus auch noch mehr und ich denke neben zahlreichen 
Peripheriebausteinen, Flash und SRAM auch sicher sowas wie ein 
Boot-ROM?! Beispielsweise ein MAC7116 oder ein OMAP5912, usw.

Dennoch bleibt meine Fragen offen wie man einen Chip so ansteuert, das 
er nach dem Reset an einer bestimmten Stelle stoppt?
Was ich mir ja noch vorstellen kann ist, die Ausführung nach einem Reset 
per HALT der CPU zu stoppen, dann den PC auf 0x0000 0000 zu stellen und 
weiterlaufen zu lassen. Quasi ein Soft-Reset. Aber das ist ja nicht 
dasselbe.

[Dr. Sommer (Gast)]

Olli Z. schrieb:
> Aber darüber hinaus auch noch mehr und ich denke neben zahlreichen
> Peripheriebausteinen, Flash und SRAM auch sicher sowas wie ein
> Boot-ROM?!

Fehlt da ein "haben die" ? Je nach Prozessor gibt es ein Boot-ROM, ja. 
Auch das kann man debuggen, ist letztendlich nur normale Software. Die 
ist aber typischerweise ziemlich groß (TI Sitara AM335x: 170KiB) und 
daher in binärer Form kaum zu durchblicken.

Olli Z. schrieb:
> Dennoch bleibt meine Fragen offen wie man einen Chip so ansteuert, das
> er nach dem Reset an einer bestimmten Stelle stoppt?

z.B. per BOOT-Pins auf "JTAG" Boot stellen, sodass der Prozessor gar 
nicht erst startet. Dann per JTAG einen Breakpoint setzen und starten.

Olli Z. schrieb:
> Quasi ein Soft-Reset. Aber das ist ja nicht
> dasselbe.

Man kann per JTAG auch einen richtigen Reset auslösen, nachdem man einen 
Breakpoint gesetzt hat, oder einfach den Reset-Button betätigen. Der 
sollte das Debuggen nicht beeinträchtigen.

Darf man fragen warum es um so uralte Prozessoren wie ARM7 geht? Die 
Debug-Fähigkeiten aktueller Cortex-M/A Prozessoren sind gewiss 
angenehmer...

[Olli Z. (z80freak)]

Dr. Sommer schrieb:
> z.B. per BOOT-Pins auf "JTAG" Boot stellen, sodass der Prozessor gar
> nicht erst startet. Dann per JTAG einen Breakpoint setzen und starten.
Das klingt einleuchtend, jedoch habe ich bei den von mir genannten 
solche "Pin" nicht identifizieren können. Kann mir auch gut vorstellen 
das sowas per Fuses ausgeblendet wird um das IP zu schützen.

> Man kann per JTAG auch einen richtigen Reset auslösen, nachdem man einen
> Breakpoint gesetzt hat, oder einfach den Reset-Button betätigen. Der
> sollte das Debuggen nicht beeinträchtigen.
Und das könnte ich mir nur vorstellen wenn der JTAG-TAP (ICE) und der 
Rest getrennt voneinander wirken. Also man legt Betriebsspannung an, 
programmiert den ICE zum stop auf Adresse "irgendwas" und mach auf dem 
CPU/MCU Part einen Reset, welcher aber nicht den ICE resettet. So in 
etwa?

> Darf man fragen warum es um so uralte Prozessoren wie ARM7 geht? Die
> Debug-Fähigkeiten aktueller Cortex-M/A Prozessoren sind gewiss
> angenehmer...
Naja, meine Überlegungen dabei sind immer die gleichen: "Was habe ich 
zur Verfügung?", "Ältere Chips sind einfacher zu kapieren als jüngere", 
"Kann ich das erlernte direkt auch anwenden?"
Daher.

[Dr. Sommer (Gast)]

Olli Z. schrieb:
> Das klingt einleuchtend, jedoch habe ich bei den von mir genannten
> solche "Pin" nicht identifizieren können.

Der MAC7116 scheint sowas wirklich nicht zu haben. Zum OMAP5912 hab ich 
auf die schnelle keine vernünftige Doku gefunden, da zu alt. Die 
Nachfolger des OMAP, die Sitara Prozessoren, haben 16 Boot-Config-Pins, 
welche mit den LCD-Pins gemultiplext sind. Die STM32 haben zwei 
BOOT-Pins.

Olli Z. schrieb:
> Kann mir auch gut vorstellen
> das sowas per Fuses ausgeblendet wird um das IP zu schützen.
Je nach Prozessor, möglich.

Olli Z. schrieb:
> Also man legt Betriebsspannung an,
> programmiert den ICE zum stop auf Adresse "irgendwas" und mach auf dem
> CPU/MCU Part einen Reset, welcher aber nicht den ICE resettet. So in
> etwa?

Genau.

Olli Z. schrieb:
> Naja, meine Überlegungen dabei sind immer die gleichen: "Was habe ich
> zur Verfügung?
Zu aktuellen Prozessoren wie STM32 oder Sitara findet man sehr viele 
Informationen und Tutorials. Zu so alten nichtmal mehr die offizielle 
Produkt-Seite.

Olli Z. schrieb:
> "Ältere Chips sind einfacher zu kapieren als jüngere",
Was heißt "kapieren"? Willst du die Schaltung verstehen? An die kommst 
du eh nicht dran. Willst du die nur normal programmieren? Das geht bei 
den aktuellen besser, weil bessere Prozessor-Architektur und Debugging.

Olli Z. schrieb:
> "Kann ich das erlernte direkt auch anwenden?"
Bei aktuellen ist das tendenziell einfacher... z.B. bei den Cortex-M3/4 
ist das Interrupt-Handling einfacher zu nutzen als bei ARM7.