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
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
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.
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
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
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.
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.
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
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.
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
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.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.