Forum: Mikrocontroller und Digitale Elektronik SWD über USB-C


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Schorschi (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

An meinem embedded system(ES) wird eine USB-C Buchse vorhanden sein, 
welche als USB 2.0 agiert.
Dafür sind folgende Verbindungen gemacht (am ES):
- CC1 mit 5k1 zu GND,
- CC2 mit 5k1 zu GND,
- Beide D+ zum MCU-D+
- Beide D- zum MCU-D-

Nun wäre es schön, wenn ich über einen Adapter direkt auch den JLink 
über USB-C anschliessen kann (über einen Adapter), um den MCU mittels 
SWD zu programmieren.

Ich habe dazu rausgefunden, dass dafür der debug accessory mode (DAM) 
genutzt werden kann.. Frage mich nun aber, wie ich diese Konfiguration 
hinbekomme, bzw. wie ich SWDIO, SWDCLK und VTref verbinden muss, damit 
nichts kaputt geht falls das Gerät an einen normalen PC angeschlossen 
wird.

Gruss,
Schorschi

von Moot S. (mootseeker)


Bewertung
0 lesenswert
nicht lesenswert
Ich würde die beiden Anschlüsse von einander Trennen. Zum einen wird 
dies praktisch nicht funktionieren, zum ansderen Brauchst du die SWD nur 
ein paar mal bis das ganze programmiert ist und dann eigentlich nie 
wieder (im besten fall).

Mach das ganze getrennt. Ich würde dir so was kleines wie diesen Stecker 
empfehlen: Molex 53047-0610 
https://www.molex.com/molex/products/part-detail/pcb_headers/0530470610

von Moot S. (mootseeker)


Bewertung
0 lesenswert
nicht lesenswert
Schorschi schrieb:
> Nun wäre es schön, wenn ich über einen Adapter direkt auch den JLink
> über USB-C anschliessen kann (über einen Adapter), um den MCU mittels
> SWD zu programmieren.

Was du natürlich machen kannst ist, ein teures USB 3.1 Kabel 
aufschneiden und die RX / TX Fäden als SWD missbrauchen, so hättest du 
alles auf einem Kabel.

von Ntldr -. (ntldr)


Bewertung
0 lesenswert
nicht lesenswert
Schorschi schrieb:
> Ich habe dazu rausgefunden, dass dafür der debug accessory mode (DAM)
> genutzt werden kann.. Frage mich nun aber, wie ich diese Konfiguration
> hinbekomme, bzw. wie ich SWDIO, SWDCLK und VTref verbinden muss, damit
> nichts kaputt geht falls das Gerät an einen normalen PC angeschlossen
> wird.

So einfach ist das leider nicht. Deine Anwendung müsste erkennen (durch 
die CC-Widerstände), dass es sich bei der Gegenseite eben gerade nicht 
um einen regulären USB Host sondern um deinen JLink-Adapter handelt. 
Daraufhin könnten die USB Pins für die Debugschnittstelle rekonfiguriert 
werden. Einfach mal SWD auf die freien USB Pins zu legen geht leider 
nicht.

Hintergrund ist folgender: Ein (konformes) USB C Kabel schließt eine der 
beiden CC-Leitungen mit GND kurz. Im DAM (Debug Acessory Mode) schließt 
du stattdessen beide CC-Leitungen mit GND kurz (auf der 
Debuggerseite). Da "CC1 = CC2 = GND" in der Außenwelt nicht vorkommen 
dürfte (das wäre ja nicht USB-Konform) kann man so den Debugadapter 
erkennen.

Ich würde da auch eher einen eigenen Debug Header vorziehen oder 
notfalls etwas eigenes zusammenfrickeln.

: Bearbeitet durch User
von Schorschi (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Wäre es möglich auf dem device:
- Prüfen ob die Spannung an CC1 und CC2 (mit Rd 5.1k) 0V haben während 
VBUS=5V
- Wenn ja, über einen Level-Shifter SWDIO, SWDCLK, VDD und nRST auf TS1, 
TS2, TS3 und TS4 zu legen (siehe 
https://en.wikipedia.org/wiki/USB-C#Debug_Accessory_Mode)

Auf dem Adapter:
- VBUS vom JLink nehmen (5V supply)
- CC1 und CC2 auf GND legen
- SWDIO, SWDCLK, VTref und nRST auf TS1, TS2, TS3 und TS4
?

Meiner Meinung nach sollte somit sicher überprüft werden können, wenn 
der Debug Accessory Mode verwendet werden soll (zu mindest mit dem 
Adapter).

Gruss Schorschi

von Mein name ist Hase (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ich hab die idea auch mal gehabt und mal etwas rungestöbert damals.

es gibt glaube ich entsprechende ICs für USB - C die C1 und C2 auswerten 
und dann entsprechend agieren. So wie ich das verstanden habe wird über 
C1/C2 auch wirklich kommunizert. ggf muss die freigabe dafür sogar vom 
dahinterliegenden IC kommen. Die kümmern sich ggf auch um die 
orientierns erkennung, ...

Für irgend einen dieser ICs gab es einen Thread wo einer das machen 
wollte, ... nur das dumme war der Hersteller hat swd auf dem alternate 
glaube ich auf seinen Internen Core gelegt gehaubt. extern wurde das 
leider nicht weitergeleitet. Damit war dem hern dann leider nicht 
geholfen.

Heist sowas geht. nur sollte man genau hinschauen.

von Stefan ⛄ F. (stefanus)


Bewertung
1 lesenswert
nicht lesenswert
Schorschi schrieb:
> Nun wäre es schön, wenn ich über einen Adapter direkt auch den JLink
> über USB-C anschliessen kann (über einen Adapter), um den MCU mittels
> SWD zu programmieren.

über über über ... ich verstehe nicht, was du meinst.

von Mein name ist Hase (Gast)


Bewertung
0 lesenswert
nicht lesenswert
JTAG <- Kabel -> adapter platine <- Standard usb c kabel -> Target

von Frank K. (fchk)


Bewertung
0 lesenswert
nicht lesenswert
Ist Dein USB-C Host oder Device?

Wenn Device, dann könntest Du ganz einfach einen kleinen Hub und einen 
FT232H oder FT2232 einbauen und über den und OpenOCD Deinen Code 
aufspielen und debuggen, und das ginge dann auch im Feld oder beim 
Kunden.

fchk

von Schorschi (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Mein name ist Hase schrieb:
> es gibt glaube ich entsprechende ICs für USB - C die C1 und C2 auswerten
> und dann entsprechend agieren.

Ja, da gibt es so einige.. die brauchen aber alle eine Konfiguration 
über den MCU des devices (z.B. I2C) um in den DAM zu gelangen. Ich 
denke, es sollte auch einfacher gehen, da der DAM im Unterschied zu den 
anderen Modus CC1 und CC2 auf GND hat (zumindest am Anfang).

Frank K. schrieb:
> Ist Dein USB-C Host oder Device?
>
> Wenn Device, dann könntest Du ganz einfach einen kleinen Hub und einen
> FT232H oder FT2232 einbauen und über den und OpenOCD Deinen Code
> aufspielen und debuggen, und das ginge dann auch im Feld oder beim
> Kunden.

Mein Target ist ein Device.

Coole Idee mit dem FTDI, den merk ich mir für andere Projekte.
Hier werde ich ihn nicht nutzen können, da ich den USB-Port selbst auch 
am MCU selbst brauche. Zusätzlich soll der Kunde nicht so einfach 
Zugriff zum Debug-Port haben (d.h. beim Anschluss am PC mit normalem 
USB-Kabel, sollte der Debug-Port nicht sofort ersichtlich sein.

von Frank K. (fchk)


Bewertung
0 lesenswert
nicht lesenswert
Schorschi schrieb:

> Coole Idee mit dem FTDI, den merk ich mir für andere Projekte.
> Hier werde ich ihn nicht nutzen können, da ich den USB-Port selbst auch
> am MCU selbst brauche.

Deswegen der Hub-Chip. So einer z.B.

https://www.maxlinear.com/product/interface/bridges/usb-hubs/xr22404

Damit kannst Du gleichzeitig auf deinen Prozessor und auf den FTDI 
zugreifen.

> Zusätzlich soll der Kunde nicht so einfach
> Zugriff zum Debug-Port haben (d.h. beim Anschluss am PC mit normalem
> USB-Kabel, sollte der Debug-Port nicht sofort ersichtlich sein.

Das lässt sich ja regeln, indem Du dem FTDI-Chip einfach eine andere VID 
und PID gibst. Dann weiß niemand mehr, was dahinter steht. OpenOCD lässt 
sich in dieser Hinsicht sehr flexibel konfigurieren. Plus: Du könntest 
den zweiten Kanal des FT2232 noch für einen Debug-UART nutzen. Der 
FT2232 (entweder ...D als Full-Speed oder ...H als High-Speed-Variante) 
braucht noch ein kleines EEPROM für seine Settings:

https://de.farnell.com/microchip/93aa46bt-i-ot/eeprom-seriell-1kbit-2mhz-sot/dp/1331410RL

Auch kein Problem.

fchk

von Mein name ist Hase (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Du meinst, das die leute die das device debuggen wollen das gerät nicht 
vorher aufschrauben und sich für jeden IC das datenblat vorher holen und 
anschauen? Die werden sehr schnell feststelen das das ein FTDI drauf 
ist. Wie und wo der angeschlossen ist und was der macht lässt sich ggf 
auch ganz schnell raus bekommen solang man mit dem Multimeter an die 
pins rankommt.

Pid / VID des FTDI treibers anpassen hat FTDI ja selber auf der Homepage 
dokumentiert.

von Schorschi (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Super, besten Dank für eure Antworten!

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.