Debug Möglichkeiten Cortex M3/M4

Mike schrieb:

> SW-DP Serial Wire Debug Port und
> JTAG-DO Serial Wire JTAG Debug PORT

> kann mir von Euch jemand sagen was der Unterschied zwischen den beiden
> oben genannten Debug Ports ist?

Die Anzahl der benötigten Pins. Bei JTAG sind es mindestens 4 - TCK, 
TMS, TDI, TDO, manchmal auch noch TRST. Bei SW hast Du nur noch die 
Taktleitung und eine bidirektionale Datenleitung, über die Du dann die 
JTAG-Befehle tunnelst. Ziel ist einfach, mit weniger Pins auszukommen.

Das wird nicht nur bei den ARM Cortex Controllern gemacht, sondern in 
ähnlicher (aber nicht kompatibler) Form auch beim MSP430 (dort heißt das 
dann Spy-Bi-Wire).

Microchip hat auf den PIC32 ein Gateway eingebaut, mit dem man den JTAG 
des MIPS4k-Kerns über die Microchip ICSP Schnittstelle ansteuern kann. 
Braucht dann auch nur zwei Pins plus Reset (/MCLR im Microchip-Jargon), 
und die eigentlichen JTAG-Pins können als IO-Ports verwendet werden.

fchk

Mike schrieb:
> Aber ich muss doch irgendlche Vorteile davon haben, dass ich mehr Pins
> Opfer oder?

Es gibt z.Zt. mehr JTAG Adapter, als SWD Adapter. Auf einem richtigen 
SoC, das zwecks boundary scan ohnehin JTAG unterstützen muss, spare 
ich mit SWD nichts wesentliches.

Gruß
Marcus

Mike schrieb:
> Aber ich muss doch irgendlche Vorteile davon haben, dass ich mehr Pins
> Opfer oder?

Eventuell etwas mehr Geschwindigkeit. Außerdem war JTAG weit vorher da 
und ist auf elektrischer Ebene (IEEE1149) standardisiert. Die 
Zweidraht-Verfahren sind sehr neu und allesamt proprietär.

fchk

Ich nehm zum debuggen immer 1 bis 2 LED, wenn's edel sein soll kommt der 
UART mit Hyperterminal dazu. Kein Witz! :-)

X- Rocka schrieb:
> Ich nehm zum debuggen immer 1 bis 2 LED, wenn's edel sein soll kommt der
> UART mit Hyperterminal dazu. Kein Witz! :-)

Diese Methode hat den Vorteil, man lernt den MC sehr schnell sehr gut 
kennen, da man sich Gedanken machen muß, wo man Debugausgaben überhaupt 
einfügt und was sie dann aussagen.

Und man klopft erstmal den Code daraufhin ab, ob man irgendwo 
Schweinereien gemacht hat, z.B. Volatile oder Atomic vergessen. Dabei 
sieht man durchaus schon Fehler, die sich noch garnicht auswirken, aber 
Fallgruben darstellen.

Aber leider wird es heutzutage als zu schwer empfunden, sich Gedanken zu 
machen, wo der Fehler liegen könnte.
Man macht lieber Trial&Error mit dem Debugger.
Dabei findet man natürlich nur Fehler, die sich sofort auswirken und die 
Software wird deutlich unzuverlässiger (Bananensoftware, reift erst beim 
Anwender).


Peter