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.
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.
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.
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:>> @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.
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
