Hallo zusammen, bin gerade dabei mir eine Schaltung mit dem STM32F405RGT6 aufzubauen. Es scheitert nun an der Programmierung via JTAG-Schnittstelle, hier gewählt die eigentlich simple 5-Pin-Variante (s. Schaltplan im Anhang). Für den Verbindungstest verwende ich den STM32CubeProgrammer in Verbindung mit dem ST-Link/V2 als Adapter, den ich für den JTAG-Stecker passend modifiziert habe, also nur entsprechende Leitungen verwende. Problem: Ich bekomme beim Verbindungstest stets die Fehlermeldung "No STM target found".... habe bereits einen anderen ebenso modifizierten Adapter und eine funktionierendes Board mit dem exakt gleichen Mikrocontroller verwendet - da klappt der Verbindungsaufbau problemlos. Habe dementsprechend auch mit dem Oszi die Signale am JTAG-Stecker verglichen - bekomme beim Drücken auf "Connect" einen HIGH-Pegel am Clock-Pin, dann gehts aber hingegen zur funktionierenden Variante nicht weiter, als würde der Mikrocontroller auf weitere Eingaben Warten. Gibt es noch andere, wesentliche Dinge, die bei der Verbindung via JTAG beachtet werden müssen? Vielleicht ein Clock-Problem? Hat jemand eventuell ein Dokument parat, indem ich den zeitlichen Ablauf der JTAG-Sequenz nachverfolgen kann? Vielen Dank für eure Hilfe.
Sorry, für XML bin ich zu alt. Ich kann nur Schaltpläne in Bildform lesen.
Walter T. schrieb: > Sorry, für XML bin ich zu alt. Ich kann nur Schaltpläne in > Bildform > lesen. Sorry für die Umstände! :(
da gab es vor kurzem auch so einen Fall, in dem Thread ist alles möglich genannt was man prüfen und machen kann: Beitrag "STM32L051K8T6 wird vom ST-Link nicht erkannt" Letztendlich war wohl der Controller defekt, evtl. beim Einlöten passiert. Den SWD Traffic kann man mit einem LA wie von Saleae im Detail anschauen, der kann das auch dekodieren.
Johannes S. schrieb: > da gab es vor kurzem auch so einen Fall, in dem Thread ist alles > möglich > genannt was man prüfen und machen kann: > Beitrag "STM32L051K8T6 wird vom ST-Link nicht erkannt" > Letztendlich war wohl der Controller defekt, evtl. beim Einlöten > passiert. > Den SWD Traffic kann man mit einem LA wie von Saleae im Detail > anschauen, der kann das auch dekodieren. Danke für die Antwort. Einen defekten MCU kann ich tatsächlich ebenfalls ausschließen - habe insgesamt drei Platinen bestückt und getestet - alle drei schließen auf den gleichen Fehler. Kann es mir wirklich nicht erklären, aber vielleicht hilft ja der weiterführende Link..... Weitere Tips gern gesehen :(
donkey schrieb: > via JTAG-Schnittstelle, Nur Interessehalber - wer verwendet denn für die STM32 überhaupt JTAG? Das ist doch eine reine Resourcenverschwendung (an Pins zB). Wieso nicht SWD?
donkey schrieb: > Gibt es noch andere, wesentliche Dinge, die bei der Verbindung via JTAG > beachtet werden müssen? An STM32F446 und STM32F407 mußte ich schon Limitations (siehe Errata Sheet), wenn PB4 anderweitig verwendet werden, schmerzlich kennenlernen. Geht denn SWD?
Walter T. schrieb: > donkey schrieb: >> Gibt es noch andere, wesentliche Dinge, die bei der Verbindung via JTAG >> beachtet werden müssen? > > An STM32F446 und STM32F407 mußte ich schon Limitations (siehe Errata > Sheet), wenn PB4 anderweitig verwendet werden, schmerzlich kennenlernen. > > Geht denn SWD? Habe mich ehrlich gesagt noch nicht mit SWD auseinandergesetzt. Kann ich meinen Adapter einfach entsprechend umbauen, heißt also ohne zusätzliche Pullups/-downs an DIO und CLK? Kann jedenfalls bei dem Schaltplan des vorgeschlagenen Threads (Beitrag "STM32L051K8T6 wird vom ST-Link nicht erkannt" ) nichts deratiges finden
Mampf F. schrieb: > donkey schrieb: >> via JTAG-Schnittstelle, > > Nur Interessehalber - wer verwendet denn für die STM32 überhaupt JTAG? > > Das ist doch eine reine Resourcenverschwendung (an Pins zB). > > Wieso nicht SWD? Gehen ja jetzt nicht Unmengen an Pins verloren und es klappt bei den anderen Platinen wie gesagt problemlos... dachte eben frei nach dem Motto altbewährt klappt immer.....
Ich würde sicherheitshalber 100k Pullups an TDI,TCK,TMS anbringen. In machen Empfehlungen steht auch, dass TCK einen Pulldown und keinen Pullup braucht. Probiere es damit mal aus. fchk
fchk schrieb: > Ich würde sicherheitshalber 100k Pullups an TDI,TCK,TMS anbringen. > In > machen Empfehlungen steht auch, dass TCK einen Pulldown und keinen > Pullup braucht. Probiere es damit mal aus. > > fchk Ist aber (leider) so dass es mit den 47R-Widerständen auf der funktionierenden Platine problemlos klappt... Fühle mich echt hilflos
mit SWCLK und SWDIO kommt man schon recht weit, darüber kann man flashen und debuggen. JTAG hatte wohl mal Vorteile weil man mehrere devices verketten kann, aber selbst das kann neueres SWD mittlerweile auch. Die Reset Leitung ist praktisch wenn die MCU schläft, dann kann der Debugger die auch wecken. Und SWO ist für Traces und Liveausgaben, braucht man vielleicht auch nicht unbedingt. Also mit 4 Strippen kommt man gut aus, evtl. noch Rx/Tx von einem Uart für Debugmeldungen oder um z.B. Parameter einzustellen.
Also beim Olimex H405 https://www.olimex.com/Products/ARM/ST/STM32-H405/ mit demselben Controller ist ein PDF-Schaltplan zum Download dabei, und anders als Du haben die auch die normale Reset-Leitung an den Jtag-Connector geführt. Insbesondere, wenn der Controller eine SW geladen hat, die mit WFI in den Schlafzustand geht, kann das nützlich sein. Außerdem haben sie 10k-Pullups auf den Leitungen.
donkey schrieb: > Habe mich ehrlich gesagt noch nicht mit SWD auseinandergesetzt. Mit dem ST-Link V2 geht SWD mit dem gleichen Adapterkabel wie JTAG. Es muß nur das ST-Link Utility oder das Flash-Tool Deiner Wahl auf SWD anstelle JTAG eingestellt werden. Generall ist das ST-Links Utility sehr nett, wenn es nur darum geht, Firmware zu flashen ohne zu Debuggen.
:
Bearbeitet durch User
Walter T. schrieb: > donkey schrieb: >> Habe mich ehrlich gesagt noch nicht mit SWD auseinandergesetzt. > > Mit dem ST-Link V2 geht SWD mit dem gleichen Adapterkabel wie JTAG. Es > muß nur das ST-Link Utility oder das Flash-Tool Deiner Wahl auf SWD > anstelle JTAG eingestellt werden. Generall ist das ST-Links Utility sehr > nett, wenn es nur darum geht, Firmware zu flashen ohne zu Debuggen. Habe ich dann auch gerafft, sorry, mein Fehler. Auch die Verbindung über SWD klappt nicht - habe durchaus auch verschiedene Frequenzen und sonstige Einstellungen ausprobiert. Ist zum verzweifeln. Ich werde wohl nicht drum herum kommen, den MCU doch noch ein- oder mehrmals auszutauschen. Kann es mir inzwischen einfach nicht mehr anders erklären.
donkey schrieb: > Weitere Tips gern gesehen Ich hatte mal das "Problem" dass bestimmte TQFP-Bausteine zwei Markierungen hatten die beide bei flüchtiger Betrachtung als "Pin 1" zu interpretieren waren. Damit konnte man also versehentlich den Baustein um 180 Grad versetzt auflöten und alles war für die Katz.
donkey schrieb: > fchk schrieb: >> Ich würde sicherheitshalber 100k Pullups an TDI,TCK,TMS anbringen. >> In >> machen Empfehlungen steht auch, dass TCK einen Pulldown und keinen >> Pullup braucht. Probiere es damit mal aus. >> >> fchk > > Ist aber (leider) so dass es mit den 47R-Widerständen auf der > funktionierenden Platine problemlos klappt... Fühle mich echt hilflos Das kann so sein, wie bei dem harten Ei von Loriot, das eben nur zufällig 3 Minuten lang gekocht wurde, und nicht definiert 3 Minuten lang. Es kann eben definiert funktionieren, oder nur zufällig funktionieren. fchk
donkey schrieb: > Ist aber (leider) so dass es mit den 47R-Widerständen auf der > funktionierenden Platine problemlos klappt... Fühle mich echt hilflos Ich habe oft 15 R in der Leitung. Funktioniert immer. Würde mich wundern, wenn die 47 R da wirklich arg störten. Welchen Pegel von NRST beim Programmierversuch? Hast Du "Connect under Reset" aktiv? Nicht, dass Dir Dein externer Watchdog einfach einen Strich durch die Rechnung macht. Notfalls kannst Du ja die Reset-Leitung unterbrechen - Du hast ja praktischerweise einen Widerstand drin.
:
Bearbeitet durch User
Walter T. schrieb: > Welchen Pegel von NRST beim Programmierversuch? Hast Du "Connect under > Reset" aktiv? Nicht, dass Dir Dein externer Watchdog einfach einen > Strich durch die Rechnung macht. Der WDG löst alle zwei Sekunden ein Reset aus, ein entsprechendes Signal erhalte ich am MCU-NRST. Trotz aller Unwahrscheinlichkeit, dass ich in dem geringen Zeitfenster des LOW-Pegels auf "Connect" drücke, habe ich auch connect under reset ausprobiert - leider ebenfalls erfolglos. Kann gerne Mal versuchen den NRST mit dem JTAG-Stecker direkt zu verbinden, wie es mein Vorposter vorschlug, glaube aber nicht, dass das etwas ändert. :/
Don K. schrieb: > Der WDG löst alle zwei Sekunden ein Reset aus, .. und killt Dir damit die Debug und Programmer Verbindung. R10 muss zum Programmieren raus. Übrigens will ST-Link den NRST und nicht den JTAG-TRST an der JTAG/SWD Schnittstelle haben. Denn der NRST muss für "Connect under Reset" gezogen werden. Da ist IMHO ein Redesign fällig....
Jim M. schrieb: > .. und killt Dir damit die Debug und Programmer Verbindung. R10 muss zum > Programmieren raus. > Aber doch nur für den Bruchteil einer Sekunde? > Übrigens will ST-Link den NRST und nicht den JTAG-TRST an der JTAG/SWD > Schnittstelle haben. Denn der NRST muss für "Connect under Reset" > gezogen werden. > Falls das so ist, finde ich das u.a. ein wenig irreführend. Welche Funktion erfüllt dann der JTRST-Pin am MCU? Werde ich mal so ausprobieren.
Mampf F. schrieb: > donkey schrieb: >> via JTAG-Schnittstelle, > > Nur Interessehalber - wer verwendet denn für die STM32 überhaupt JTAG? Jeder der die Vorteile von JTAG gegenüber SWD nutzen kann und die notwendigen Nadelkontakte unterbekommt. > Das ist doch eine reine Resourcenverschwendung (an Pins zB). > Wieso nicht SWD? In einer Industrie, die jedes Quentchen Marge rausquetschen will, hält sich dieser "Resourcenfresser". Könnte es sein, dass durch diese zusätzlichen Pins tatsächlich Kosten gespart werden? Um nur zwei Punkte zu nennen: Getrennte JTDI/JTDO (Geschwindigkeit), Gänseblümchenkette (Kosten im Prüfaufbau). Die Vorteile werden umso markanter, je komplexer die Anwendung ist. Ein leistungsfähiger JTAG-Adapter macht auch nochmal einiges aus. Kunden die schon länger mit ST-Link arbeiten mussten und dann hier während einer Schulung einen J-LINK an einem M4 erleben dürfen, haben üblicherweise innerhalb kurzer Zeit ebenfalls was kleines Schwarzes auf dem Tisch. (Nein, Segger gibt mir keine Prozente. Vielleicht bekomme ich aber mal einen Kaffee und einen Keks beim nächsten Messebesuch, wann auch immer der stattfinden wird.) ;)
Marcus H. schrieb: > (Nein, Segger gibt mir keine Prozente. Vielleicht bekomme ich aber mal > einen Kaffee und einen Keks beim nächsten Messebesuch, wann auch immer > der stattfinden wird.) ;) Das sollte machbar sein ;-).
Til S. schrieb: > Marcus H. schrieb: >> (Nein, Segger gibt mir keine Prozente. Vielleicht bekomme ich aber mal >> einen Kaffee und einen Keks beim nächsten Messebesuch, wann auch immer >> der stattfinden wird.) ;) > > Das sollte machbar sein ;-). lol Hab drauf gepokert, dass Du auftauchst. Hoffentlich macht es irgendwann wieder Spaß, auf Messen zu gehen. - - - @TO: - Ich glaube nicht, dass Du auf Protokollebene runter musst. - Vergleiche Deine Schaltung mit der eines Eval-Boards. Es ist nicht schädlich, JTCK mit Pulldown und die restlichen Leitungen mit Pullup zu versehen. Wenn das passt, dann - probiere Verbindungsaufbau mit dem kleineren SWD-Interface. Weniger Möglichkeiten auf Leitungsfehler - was sagt der Brenner zur Target-Spannung? - Bonus: die volle JTAG Schnittstelle hat Zugriff auf zwei Resets: JTAG-Engine-Reset und den normalen Reset. Das ist insbesondere praktisch, falls die (User-)Firmware die JTAG-Schnittstelle weghängt... - BonusBonus: RM0090->Debug Support
Marcus H. schrieb: > - BonusBonus: RM0090->Debug Support RM0399, RM0436 und RM0438 habe mir auch recht viel weitergeholfen.
Angehängte Dateien:
-
IMG2.png
19 KB
Marcus H. schrieb: > > @TO: > - Vergleiche Deine Schaltung mit der eines Eval-Boards. Es ist nicht > schädlich, JTCK mit Pulldown und die restlichen Leitungen mit Pullup zu > versehen. Hast du einen Vorschlag für ein passendes Dokument? Finde kein Eval-Board mit genau meinem MCU, kann ich da einen beliebigen MCU der F4-Serie nehmen? > - probiere Verbindungsaufbau mit dem kleineren SWD-Interface. Weniger > Möglichkeiten auf Leitungsfehler Klappt leider nicht > - was sagt der Brenner zur Target-Spannung? 3,26V - leider korrekt ---------------- Habe nun weiterhin folgende Dinge ausprobiert: - NRST des MCU zusätzlich mit J_NRST verbunden - Zusätzliche 10k-PullUps an J_NRST, J_MS, J_DI und PullDown an J_CLK - R10 ausgelötet und NRST des MCU direkt an 3,3V Alles nacheinander oder in Kombination. Will leider immer noch nicht klappen mit der Connection. Hänge nun noch den Schaltplan an, aus dem ich rauskopiert hab sowie mein PCB-Layout, vielleicht fällt ja jemandem irgendwas auf. :(
Warum Deine Bemühungen nicht funktionieren konnten, steht hier: Marcus H. schrieb: > - BonusBonus: RM0090->Debug Support Hier noch ein Link zu Segger, damit sich deren Server nicht langweilt: https://www.segger.com/products/debug-probes/j-link/technology/interface-description/ Kurz zusammengefasst: Verbinde alle Pins am JTAG-Debugger mit den passenden Pins am STM32. Es handelt sich um die Pins: VTref, NRST, JTMS, JTCK, JTDO, JTDI, JNTRST. JTCK mit Pulldown 10k und die restlichen Leitungen mit Pullup 10k versehen. Das ist ein bombensicheres, ziemlich komplettes Debuginterface. Im Falle von SWD kann man noch ein paar Strippen weglassen. Die Widerstände haben auch eher EMV-Bedeutung. - - - Mich fasziniert immer wieder, dass die einfachen Schnittstellen (RS232, I2C, SPI, JTAG) soviel Stress mit gedrehten Strippen bereiten. 100 Leitungen PCI schließt jeder instinktiv richtig an. Meine Wenigkeit eingeschlossen. ;)
Ihr Lieben, ich möchte mich bezüglich meines Problems noch einmal für eure Hilfe bedanken! Wie so oft sitzt das Problem natürlich vor dem PC bzw. der Platine. Habe mich weiter eingelesen und diesbezüglich die Pegel an VCAP1 und VCAP2 gemessen, wo ich nur wenige mV erreichte. Das Problem: Die Spule L1 war nicht korrekt verlötet - wohlgemerkt drei mal hintereinander nicht korrekt verlötet - sodass ich an V_REF keinen 3,3V Pegel erhielt (wobei ich natürlich davon ausging, diesen Pegel schon 100x kontrolliert zu haben.... wow, einfach wow.). Nachdem nun alle Pegel korrekt waren - VCAP1 und VCAP2 ca. 1.26V - funktioniert das Connecten problemlos. Applaus. Wie mein Projektleiter schon sagte: Erstmal 30-60 Minuten die Platine anschauen, ggf. mit Mikroskop und erst DANN geht's weiter.... Also, vielen Dank an euch alle, ich hoffe, dieser Thread nutzt (ähnlich schusseligen) Usern ebenfalls zukünftig.
:
Bearbeitet durch User
Hi Don, es freut mich, dass Du, auf Deutsch gesagt, "den Arsch in der Hose hast", um hier nochmal Rückmeldung abzugeben. Das motiviert, bei der nächsten Frage wieder zu antworten. Zum Thema IBS: - Sichtprüfung - Prüfung der internen Spannungen, unter Beachtung der Stromaufnahmen. Davon schriftliches Protokoll. Hilft bei der nächsten IBS und zeigt dem Kunden, dass IBS mehr ist, als vorsichtig einschalten und hoffen, dass es nicht raucht. Für die Erstprüfung von Spannungen nehme ich üblicherweise nicht das 7,5stellige Multimeter sondern das Oszilloskop. Da sieht man gleich Spikes und Ripple. Dank differentiellen Eingängen kann ich auch direkt über Spannungen zwischen einzelnen Knoten messen. Idealerweise habe ich natürlich mindestens drei Erstmuster im Labor. Wenn eines sich seltsam anlässt, wird es beiseite gelegt und das nächste geprüft. Spätestens wenn alle drei den selben seltsamen Fehler haben, stellt sich die Frage wer einen Fehler eingebaut hat - der HW-Entwickler, der Einkäufer, der Bestücker, der SW-Entwickler... Dreimal derselbe Lötfehler, naja, das ist gemein. Der Fehler ist halt immer da, wo man als letztes sucht... Weiterhin viel Erfolg im Projekt, marcus
:
Bearbeitet durch User
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.