Forum: Mikrocontroller und Digitale Elektronik JTAG vs. SWD


von brechbunkt (Gast)


Angehängte Dateien:

Lesenswert?

Ich bin verwirrt. Ich dachte bisher, JTAG benötigt zwar viele Leitungen, 
ist dafür aber recht flott. SWD benötigt nur max. 3 Leitungen, ist dafür 
aber langsamer.

Nun lese ich mir aber gerade diesen Artikel zum STM32 durch:
http://www.mikrocontroller.net/articles/STM32

Dort steht jedoch geschrieben (siehe screenshot), dass SWD schneller 
sein soll. Ist das ein Fehler im Artikel oder habe ich mich geirrt? Das 
würde dann schließlich bedeuten, dass JTAG gar keine Vorteile mehr 
bringen würde.

von brechbunkt (Gast)


Lesenswert?

Hat denn keiner eine Idee?

von Alexander R. (Gast)


Lesenswert?

Hi,

in deinem Bild steht doch einer der Unterschiede. "Device Chaining ist 
mit dieser Schnittstelle nicht möglich".

MfG Alex

von (prx) A. K. (prx)


Lesenswert?

brechbunkt schrieb:
> Ich bin verwirrt. Ich dachte bisher, JTAG benötigt zwar viele Leitungen,
> ist dafür aber recht flott. SWD benötigt nur max. 3 Leitungen, ist dafür
> aber langsamer.

Für die Datenübertragung sind immer nur 2 Leitungen relevant, Takt und 
Daten. Dass JTAG die Datenrichtung unterscheidet bietet allenfalls beim 
Kabel Vorteile, aber nicht beim Tempo. Die zusätzlichen Leitungen von 
JTAG bringen fürs Tempo nichts.

von Peter (Gast)


Lesenswert?

Es ist so wie geschrieben:
VORTEIL: Über ein JTAG Ringbus können viele verschiedene Bausteine 
angesteuert werden.
NACHTEIL: JTAG ist nicht für SW-Debugging angedacht, sondern für 
HW-Testing  (Lötfehler) in digitalen Schaltungen. Die meisten 
uC-Hersteller haben dann proprietäre erweiterungen in das JTAG-Interface 
gebastelt, um darüber auch programmieren und zu debuggen zu können, dann 
ist aber in der regel nix mehr mit Daisy-Chaining.

SWD ist ausschliesslich zum debuggen ausgelegt, und ist daher 
effizienter und schneller...

von (prx) A. K. (prx)


Lesenswert?

Ich vermute, dass der Unterschied im Tempo am Protokoll liegt. Also dass 
SWD für die gleiche Aufgabe weniger Bits übertragen muss.

von Hoe? (Gast)


Lesenswert?

A. K. schrieb:
> Für die Datenübertragung sind immer nur 2 Leitungen relevant, Takt und
> Daten. Dass JTAG die Datenrichtung unterscheidet bietet allenfalls beim
> Kabel Vorteile, aber nicht beim Tempo. Die zusätzlichen Leitungen von
> JTAG bringen fürs Tempo nichts.

JTAG ist bidirektional und SWD ist unidirektional. JTAG kann also beim 
Senden der Daten gleichzeitig Daten empfangen. Bei der SWD-Schnittstelle 
ist immer nur eine Richtung möglich und die Umschaltung zwischen Senden 
und Empfangen der Daten auch noch zeitaufwendiger und dadurch langsamer. 
Ob das SWD-Interface mit einer höheren CLK angesprochen werden kann weiß 
ich nicht.

von Hoe? (Gast)


Lesenswert?

SWD hat wohl doch einige Vorteile wenn man die richtige Debug-Hardware 
besitzt:
1
    Only 2 pins required - vital for very low connectivity devices or packages 
2
    Provides debug and test communication to JTAG TAP controllers
3
    Enables the debugger to become another AMBA bus master for access to system memory and peripheral or debug registers
4
    High performance data rates - 4 Mbytes/sec @ 50 MHz
5
    Low power - no extra power or ground pins required
6
    Small silicon area - 2.5k additional gates
7
    Low tools costs, $100 build costs - may be built in to evaluation boards
8
    Reliable - built in error detection
9
    Safe - protection from glitches on pins when tools not connected
10
    Single Debug Port for Multi-chip Products (ARM)

von (prx) A. K. (prx)


Lesenswert?

Hoe? schrieb:
> JTAG ist bidirektional und SWD ist unidirektional. JTAG kann also beim
> Senden der Daten gleichzeitig Daten empfangen.

Klar. Aber ein ebenfalls mit dem verwandten SPI duplex angebundendes 
Flash-ROM wird dadurch auch nicht schneller. Wäre also die Frage, ob man 
davon etwas hat. Beim Flashen jedenfalls nicht.

TI erwähnt zum CM3 bei 20MHz JTAG/SWD-Takt eine Transferrate von 640KB/s 
für JTAG gegenüber 1500KB/s für SWD.

von Strubi (Gast)


Lesenswert?

Salut,

> NACHTEIL: JTAG ist nicht für SW-Debugging angedacht, sondern für
> HW-Testing  (Lötfehler) in digitalen Schaltungen. Die meisten
> uC-Hersteller haben dann proprietäre erweiterungen in das JTAG-Interface
> gebastelt, um darüber auch programmieren und zu debuggen zu können, dann
> ist aber in der regel nix mehr mit Daisy-Chaining.

Ich darf doch berichtigen: JTAG ist immens flexibel, und genauso fürs 
SW-Debuggen angedacht. Das Daisy-Chaining funktioniert dabei immer noch 
genauso, sofern der JTAG-Standard richtig implementiert wird (BYPASS). 
Das haben allerdings einige Hersteller wie z.B. TI bei etwas älteren 
MSP430 verbockt.
Geht bei mir allerdings eher unter "bug" als "proprietäre Erweiterung".

Was die Geschwindigkeit angeht, ist es meist eine Frage der 
Implementierung, wieviele Bits pro Aktion runtergeschickt werden müssen.
Theoretisch dürfte man mit JTAG mehr Speed hinkriegen.

Grüsse,

- Strubi

von (prx) A. K. (prx)


Lesenswert?

Strubi schrieb:
> Was die Geschwindigkeit angeht, ist es meist eine Frage der
> Implementierung, wieviele Bits pro Aktion runtergeschickt werden müssen.
> Theoretisch dürfte man mit JTAG mehr Speed hinkriegen.

Kennst du die JTAG- und SWD-Protokolle genau genug, um abschätzen zu 
können, wieviele Bits beispielsweise für das Schreiben eines Wortes in 
den Speicher übertragen werden müssen? JTAG und SWD scheinen sich im 
Protokoll zu unterscheiden und das kann den Ausschlag geben.

von Frank K. (fchk)


Lesenswert?

Warum spekuliert Ihr hier eigentlich rum und holt euch nicht die 
passenden Dokumente von ARM?

ARM® Debug Interface v5
Architecture Specification
ARM IHI 0031A

ARM® Debug Interface v5 Architecture Specification
ADIv5.1 Supplement
DSA09-PRDC-008772

fchk

von (prx) A. K. (prx)


Lesenswert?

Frank K. schrieb:
> Warum spekuliert Ihr hier eigentlich rum und holt euch nicht die
> passenden Dokumente von ARM?

Weil du bestimmt grad dabei bist, dich da systematisch durchzuwühlen, 
und uns anschliessend informierst.

von Frank K. (fchk)


Lesenswert?

A. K. schrieb:
> Frank K. schrieb:
>> Warum spekuliert Ihr hier eigentlich rum und holt euch nicht die
>> passenden Dokumente von ARM?
>
> Weil du bestimmt grad dabei bist, dich da systematisch durchzuwühlen,
> und uns anschliessend informierst.

Nö. Selber lesen macht schlau.

fchk

von holger (Gast)


Lesenswert?

Einen Vorteil hat SWD auf jeden Fall:
Wenn man irgendwas vergurkt hat und per JTAG nicht
mehr an den Controller ran kommt, per SWD geht es noch.

von (prx) A. K. (prx)


Lesenswert?

Frank K. schrieb:
> Nö. Selber lesen macht schlau.

Eine vage Vorstellung davon habe ich auch so schon. Also weshalb sollte 
ich versuchen, aus dem nicht ganz so trivialen JTAG-Wust herauszulesen, 
wie man damit den Speicher vollschreibt? Der Einzige mit einem konkreten 
Motiv wäre der TO, aber ich denke, genauer als das was TI schreibt 
braucht er es auch nicht.

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
Noch kein Account? Hier anmelden.