Guten Abend, ich hoffe von Euch kann mir hier jemand weiterhelfen. Ich bin gerade dabei mich über die Debug Möglichkeiten eines Cortex M3/M4 zu Informieren. Jetzt bin ich auf die beiden Möglichkeiten gestoßen: SW-DP Serial Wire Debug Port und JTAG-DO Serial Wire JTAG Debug PORT Das es das ETM auch noch gibt ist mir bewusst aber das ist eigentlich verständlich. kann mir von Euch jemand sagen was der Unterschied zwischen den beiden oben genannten Debug Ports ist? Viele Dank und schöne Grüße von Balkonien ;) Mike
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
Aber ich muss doch irgendlche Vorteile davon haben, dass ich mehr Pins Opfer oder?
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
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.