JTAG - lohnt das "opfern" der 4 Pins?

[Ulrich (Gast)]

Hallo Forum,

benutzt wird ein AT90CANXX. Momentan wird er erstmalig per SPI 
(Parallelport-Programmer) programmiert (Bootloader), danach dann per 
RS232. Aber das geht ja alles über die selben Anschlusspins. Am SPI 
hängen auch andere ICs dran. SCK zu diesen ICs geht über 100R. Gibt 
soweit auch keine Probleme. Aber es wird ja auch entweder Programmiert 
oder es läuft das Programm.

Nun würde ich eigentlich gerne mein Programm debuggen können -> JTAG.
Dafür müsste ich aber 4 Portpins "opfern". Lohnt das überhaupt? Portpins 
sind immer knapp. Da beim Debuggen ja quasi das Programm und der 
Debugger gleichzeitig laufen, scheidet eine Doppelbelegung wie beim SPI 
vermutlich aus, oder? Mir erscheint der Vorteil des Debuggers teuer 
erkauft.
Gibt es da irgendwelche Tricks für eine Art Doppelbelegung?

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

Du kannst darauf auchten, das auf den JTAG-Pins irgendwelche 
Nebenfunktionen liegen, die (1) den JTAG-Debugger nicht stören und (2) 
beim Debuggen nicht wichtig sind. Dann geht beides.

Entweder du kommst ohne Debugger aus, oder du brauchst die Pins. Das 
musst du selber wissen. Es gibt 2 Gruppen von Entwicklern. Die einen 
schwören auf Debugger, die anderen kommen fast immer ohne aus.

[Läubi .. (laeubi)]

Und andere haben keinen :(

[Ulrich (Gast)]

"(1) den JTAG-Debugger nicht stören"

Gibt es dazu nähere Infos?

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

Bischen nachdenken sollte helfen ;-).

Wenn da beispielsweise low current LEDs dranhängen, dann werden die zwar 
bei aktivem JTAG nicht funktionieren und während dem Debuggen fröhlich 
blinken, sonst aber nicht stören.

Such dir also in der Schaltung ein paar weniger wichtige Output-Pins, 
deren unkontrolliertes Herumgewackel niemanden wirklich stört, und lege 
die auf die JTAG Pins. Oder wenn das Gewackel stört (z.B. Relais), dann 
häng Jumper dazwischen.

[Peter D. (peda)]

A. K. wrote:
> Es gibt 2 Gruppen von Entwicklern. Die einen
> schwören auf Debugger, die anderen kommen fast immer ohne aus.

Was aber nicht heißt, daß diese nicht debuggen. Debuggen muß jeder und 
macht auch jeder.

Um ohne JTAG zu debuggen, fügt man entsprechende Debugausgaben in das 
Programm mit ein und sendet diese über einen beliebigen Kanal (CAN, 
RS-232, Ethernet, Funk, ...) an ein Terminal.

Das hat verschiedene Vorteile. Man kann remote debuggen, die CPU wird 
beim Debuggen nicht angehalten, es wird nicht bei jeder Debugsitzung das 
Programm neu geflasht.
Auch ist diese Debugmethode nicht an eine bestimmte CPU (AVR) gebunden 
und ein bestimmtes Interface (JTAG), sie ist quasi universell und immer 
anwendbar.
Daher wird sie gerne genommen, anstatt sich bei jeder CPU in ein 
bestimmtes Debugtool neu einarbeiten zu müssen.


Peter

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

Wenn man das richtig anstellt, dann baut man in den Code an 
entscheidenden Stellen des Programms von vorneherein solche Traces ein 
und lässt sie da auch später noch drin.

Entweder macht man die per Preprocessor abhängig von 
Debug/Produktions-Build abschaltbar, besser aber zur Laufzeit global 
und/oder selektiv ein/ausschaltbar. Wenn letzteres, dann kann man bei 
später auftretenden Problemen live ohne Neuprogrammierung oder 
Beeinträchtigung des Betriebs zusehen. Und braucht spezielle 
Debugausgaben nur bei Detailproblemen.