Hallo, ich habe mir ein kleines Board mit einem STM32L021D4 im TSSOP14 Package erstellt. Ohne viel Schnick Schnack, kein externer Clock. GND sowie SWCLK (PA14) und SWDIO (PA13) habe ich nach außen geführt um programmieren und debuggen zu können. Programmiert werden soll mit einem ST-Link China Klon (dieser Funktioniert mit zwei anderen Customboard und einem STM32F1 und F4). Jetzt habe ich aber das Problem, dass ich einfach keine Verbindung zum Controller bekomme mit dem ST-Link Utility. Eingestellt ist Software System Reset. Der NRST Pin ist mit einem 10k Widerstand auf 3,3V gesetzt. Mit einem F1 und F4 auf einem anderen Board klappts ohne Probleme. Wo könnte mein Fehler sein? Danke
Mike schrieb: > Programmiert werden soll mit einem ST-Link China Klon So ein ST-Link "mini" USB-Dongle? Mike schrieb: > STM32L021D4 im TSSOP14 Package hat der Boot-Pins rausgeführt?
Christopher J. schrieb: > So ein ST-Link "mini" USB-Dongle? Ja genau. Christopher J. schrieb: > hat der Boot-Pins rausgeführt? Hmm, da hast mich auf was gebracht. Aus dem Datasheet: "The BOOT0 pin is shared with PB9 GPIO pin. This pin is an input-only pin. If nBOOT_SEL option bit is reset, sampling this pin on NRST rising edge gives the internal BOOT0 state. This pin then works as PB9 pin. The input voltage characteristics of this pin are specific for BOOT0 pin type (see Table 49: I/O static characteristics)." So ganz verstehe ich des grad nicht?
Hmm, habe jetzt den PB9 mittels 10k auf GND gezogen, aber ändert leider nichts. Kann immer noch nicht verbinden.
Dann probier "Connect under Reset". Damit geht es immer. (So lange die HW korrekt ist.)
Angehängte Dateien:
-
schaltplan.png
13 KB
pegel schrieb: > Dann probier "Connect under Reset". > Damit geht es immer. (So lange die HW korrekt ist.) Geht leider auch nicht. Anbei ist mal der betroffende Ausschnitt vom Schaltplan.
Hast Du es richtig ausgeführt? In ST-Link Utility "Connect under Reset" einstellen, dann NRST auf Masse legen, dann in ST-Link Utility auf Verbinden, dann NRST von Masse trennen. Beachte, dass der China Stlink das Reset nur für den STM8 benutzt, nicht für STM32.
Harry L. schrieb: > Mach mal an Pin1 (PB9) 10k gegen Masse! Den hab ich provisorisch drauf gelötet, hatte ich ursprünglich nicht vorgesehen. pegel schrieb: > In ST-Link Utility "Connect under Reset" einstellen, dann NRST auf Masse > legen, dann in ST-Link Utility auf Verbinden, dann NRST von Masse > trennen. > > Beachte, dass der China Stlink das Reset nur für den STM8 benutzt, nicht > für STM32. Genau so habe ich es gemacht, da ich das bereits gelesen hatte das der China STLink den HW Reset beim STM32 nicht kann.
Dann zeig mal ein schönes Bild vom Aufbau. Vielleicht sehen wir das Problem dann.
Okay, Fehler gefunden bzgl dem Hardwarereset. Die Masseverbindung mit Lackdraht war nicht richtig, daher hat er auch keinen HW Reset gemacht. Jetzt kann ich mittels Hardwarereset verbinden, funktioniert einwandfrei. Aber warum geht der Softwarereset nicht?
Mike schrieb: > Der NRST Pin ist mit einem 10k Widerstand auf 3,3V gesetzt. Das ist nicht sinnvoll. Es steht ausdrücklich im Datenblatt (6.3.14, Fig. 25), dass ein Pull-up intern vorhanden ist. Seufz, wozu schreibt der Hersteller so etwas wohl rein, wenn es doch niemand liest ...
A. B. schrieb: > Das ist nicht sinnvoll. Es steht ausdrücklich im Datenblatt (6.3.14, > Fig. 25), dass ein Pull-up intern vorhanden ist. Danke für den Hinweis, muss ich überlesen haben...
A. B. schrieb: >> Der NRST Pin ist mit einem 10k Widerstand auf 3,3V gesetzt. > > Das ist nicht sinnvoll. Es steht ausdrücklich im Datenblatt (6.3.14, > Fig. 25), dass ein Pull-up intern vorhanden ist. Normal steht da aber auch irgendwo, dass empfohlen wird ein 100nF gegen GND an das NRST zu hängen um den µC robuster gegen EM-Störungen zu machen. Der fehlt beim TO.
Mike schrieb: > Genau so habe ich es gemacht, da ich das bereits gelesen hatte das der > China STLink den HW Reset beim STM32 nicht kann. So ist es. Darauf wollte ich auch mit meiner Frage oben hinaus. Mike schrieb: > Jetzt kann ich mittels Hardwarereset verbinden, funktioniert > einwandfrei. > Aber warum geht der Softwarereset nicht? Möglicherweise hast du in deiner Software die SWD-Pins umkonfiguriert. Dann hast du per SWD keinen Zugriff mehr auf den Controller im laufenden Betrieb.
Christopher J. schrieb: > Möglicherweise hast du in deiner Software die SWD-Pins umkonfiguriert. > Dann hast du per SWD keinen Zugriff mehr auf den Controller im laufenden > Betrieb. Ne, ich habe noch gar keine Software drauf. Der Controller ist komplett leer. Ich wollte zunächst schauen ob ich überhaupt eine Verbindung herstellen kann und habe dafür das STLink Tool verwendet.
Wer billig kauft, kauft zweimal Nutze einen originalen ST-Link. 18€ netto bei Mouser - erspart dir hier viel Frust. Und mach dann mal diesen R3 da weg. Und PB9 gegen GND (Pulldown).
Bimbo. schrieb: > Wer billig kauft, kauft zweimal Nutze einen originalen ST-Link. 18€ > netto bei Mouser - erspart dir hier viel Frust. Kauf ein Nucleo für 10€ da ist einer drauf ;)
Guest schrieb: > Kauf ein Nucleo für 10€ da ist einer drauf ;) Das stimmt. Ich stehe dann aber doch auf die pompöse Luxusvariante mit geschlossenem und durchdesignten Gehäuse ;).
Ach was. Das China Teil reicht voll aus. Habe ich auch schon für nRF51 benutzt. Noch nie Probleme gehabt. Aus Interesse werde ich mir als nächstes ein Nucleo/Discovery mit ST-Link V3 besorgen, sobald eins bei RS verfügbar ist.
Bimbo. schrieb: > Wer billig kauft, kauft zweimal Nutze einen originalen ST-Link. 18€ > netto bei Mouser - erspart dir hier viel Frust. Danke für diesen qualifizierten und richtig wertvollen Beitrag zu meinem Problem. Hilft mir ungemein weiter.
pegel schrieb: > Aus Interesse werde ich mir als nächstes ein Nucleo/Discovery mit > ST-Link V3 besorgen, sobald eins bei RS verfügbar ist. Ich meine, dass die ST-Link V3 auf den Nucleos keine Pfostenleiste und Jumper mehr haben, so dass man (ohne größere Modifikationen) keinen externen Controller mehr damit bespielen kann. Mike schrieb: > Christopher J. schrieb: >> Möglicherweise hast du in deiner Software die SWD-Pins umkonfiguriert. >> Dann hast du per SWD keinen Zugriff mehr auf den Controller im laufenden >> Betrieb. > > Ne, ich habe noch gar keine Software drauf. Der Controller ist komplett > leer. Ich wollte zunächst schauen ob ich überhaupt eine Verbindung > herstellen kann und habe dafür das STLink Tool verwendet Das ist irgendwie seltsam. Hast du mal die Firmware vom ST-Link upgedatet? Ansonsten würde ich es mal mit st-flash (texane/st-link) oder mit OpenOCD probieren.
Mike schrieb: > Danke für diesen qualifizierten und richtig wertvollen Beitrag zu meinem > Problem. Hilft mir ungemein weiter. Das war der in der Tat. Denn der originale macht einen Reset über die NRST Leitung, was dieser Chinakracher - soweit ich weiß - nicht macht. Und wiegesagt R3 weg. Ich glaube dass der Pulldown bei dem Boot0 Pin nicht unbedingt wichtig ist. Der ist glaube ich werksseitig auf Optionbytes konfiguriert.
Christopher J. schrieb: > Ich meine, dass die ST-Link V3 auf den Nucleos keine Pfostenleiste und > Jumper mehr haben Wenn ich das richtig sehe, liegen an CN5 die SWD/(JTAG?) Leitungen an. Ist nur leider ein sehr zartes Steckerlein. Die Frage ist, ob die Signale in beide Richtungen nutzbar sind. https://www.st.com/content/ccc/resource/technical/layouts_and_diagrams/schematic_pack/group1/da/0e/e2/b8/a5/b8/4d/ea/MB1363-H745ZIQ-C01_Schematic/files/MB1363-H745ZIQ-C01_Schematic.PDF/jcr:content/translations/en.MB1363-H745ZIQ-C01_Schematic.PDF Seite 9 Der Liefertermin ist in 3 Monaten bei RS. Da habe ich noch Zeit das heraus zu finden.
pegel schrieb: > Christopher J. schrieb: >> Ich meine, dass die ST-Link V3 auf den Nucleos keine Pfostenleiste und >> Jumper mehr haben > > Wenn ich das richtig sehe, liegen an CN5 die SWD/(JTAG?) Leitungen an. > Ist nur leider ein sehr zartes Steckerlein. > > Die Frage ist, ob die Signale in beide Richtungen nutzbar sind. Ja, stimmt. Es gibt einen STDC14-Connector. Das müsste eine "aufgebohrte" Version des "standard" ARM-10-Pin Connectors sein, wie er z.B. auf dem J-Link Edu Mini drauf ist. Was ich jedoch nicht sehe, ist eine Möglichkeit den ST-Link vom Target auf dem Nucleo zu trennen. Dadurch kann man zwar einen externen Debugger an das Target anschließen (der on-Board ST-Link bleibt dann einfach "still") aber man kann nicht ein externes Target mit dem on-Board ST-Link debuggen, weil sich sonst die MCU auf dem Nucleo und die externe MCU "dazwischen reden". Mouser hat das Nucleo G474RE auf Lager und das hat auch einen ST-Link V3E. Ich bin auch am überlegen mir mal einen V3 zu holen, also einen V3-SET. Muss aber mal gucken ob der von OpenOCD schon unterstützt wird. Die Tools von ST sind mir irgendwie ein bisschen arg aufgebläht aber das ist natürlich Geschmackssache.
Christopher J. schrieb: > aber man kann nicht > ein externes Target mit dem on-Board ST-Link debuggen, weil sich sonst > die MCU auf dem Nucleo und die externe MCU "dazwischen reden". Vielleicht genügt es die Onboard MCU dauerhaft im Reset zu halten?
pegel schrieb: > Vielleicht genügt es die Onboard MCU dauerhaft im Reset zu halten? Genau den Gedanken hatte ich auch. Es gibt sogar einen Jumper dafür. Könnte also gehen.
pegel schrieb: > Christopher J. schrieb: >> aber man kann nicht >> ein externes Target mit dem on-Board ST-Link debuggen, weil sich sonst >> die MCU auf dem Nucleo und die externe MCU "dazwischen reden". > > Vielleicht genügt es die Onboard MCU dauerhaft im Reset zu halten? Das hilft nicht, denn JTAG/SWD sind auch bei aktivem Reset (NRST) aktiv. Nicht umsonst gibt's ja gerade das "Connect under reset". Eine Möglichkeit wäre u.U. NJTRST (Achtung, nicht NRST!) aktiv zu halten, denn währenddessen sollte die Umschaltsequenz von JTAG nach SWD nicht möglich sein und das JTAG-Interface selbst auch stumm bleiben. Ob das allerdings funktioniert, habe ich nicht ausprobiert. Die andere wäre, RDP Level 2 im Target zu aktivieren, denn dann ist JTAG/SWD deaktiviert. Ob das allerdings zielführend ist ... Das STLink-V3 (die "große" Version und die auf manchen Nucleos) funktionieren problemlos mit openocd.
A. B. schrieb: >> Vielleicht genügt es die Onboard MCU dauerhaft im Reset zu halten? > > Das hilft nicht, denn JTAG/SWD sind auch bei aktivem Reset (NRST) aktiv. > Nicht umsonst gibt's ja gerade das "Connect under reset". Ich kenne mich mit den Innereien von SWD zugegebenermaßen nicht so gut aus aber für mich klang "connect under reset" immer ein bisschen nach "connect after hardware reset", frei übersetzt aus dem Französischen/Italienischen. Jedenfalls ist es bei mir immer so gewesen, dass OpenOCD in einen Timeout lief, wenn ich den Hardware-Reset Button nicht rechtzeitig losgelassen habe. A. B. schrieb: > Eine Möglichkeit wäre u.U. NJTRST (Achtung, nicht NRST!) aktiv zu > halten, denn währenddessen sollte die Umschaltsequenz von JTAG nach SWD > nicht möglich sein und das JTAG-Interface selbst auch stumm bleiben. Ob > das allerdings funktioniert, habe ich nicht ausprobiert. Ist NJRST und NRST nicht der selbe Pin? A. B. schrieb: > Die andere wäre, RDP Level 2 im Target zu aktivieren, denn dann ist > JTAG/SWD deaktiviert. Ob das allerdings zielführend ist ... Das bringt mich auf die Idee, dass man ja einfach die SWD-Pins im Controller auf dem Nucleo umkonfigurieren könnte. Das hätte dann den gleichen Effekt. Was dann allerdings beim externen Controller nicht geht ist der "connect under reset" (wenn der Reset denn vom ST-Link ausgehen soll), weil dann ja wieder beide Controller die SWD-Pins aktiv haben und womit man dann faktisch einen ST-Link V3 "mini" hätte, also mit der gleichen Einschränkung wie bei den China-USB-Dongles ;) A. B. schrieb: > Das STLink-V3 (die "große" Version und die auf manchen Nucleos) > funktionieren problemlos mit openocd. Vielen Dank für den Hinweis.
A. B. schrieb: > Das hilft nicht, denn JTAG/SWD sind auch bei aktivem Reset (NRST) aktiv. > Nicht umsonst gibt's ja gerade das "Connect under reset". Ich denke/dachte mir, dass der µC "under Reset" zwar empfängt, aber erst nach dem Reset Zyklus sendet. Müsste man genauer analysieren.
Bimbo. schrieb: > Nutze einen originalen ST-Link. 18€ > netto bei Mouser - erspart dir hier viel Frust. Da trifft auch auf den STLINK-V3MINI (9,13€) zu. Das relativiert die ganze Bastelei natürlich sehr. Bin aber kein Kunde bei Mouser und weiss nicht was alles zu den 9,13€ dazu kommt.
Ich verstehe einfach nicht, warum man sich das Leben so schwer macht. Führe NRST ohne Pullup heraus und nutze einen originalen ST-Link f+r 5 Leitungen (SWDIO, SWCLK, NRST, VDD, VSS), der auch einen richtigen Reset macht. Dann sollte das - deinem obigen Schaltplan zufolgende (wenn das denn alles ist) - funktionieren. Dieses Rumgebastel hier ist durch furchtbar.
Christopher J. schrieb: > Ich kenne mich mit den Innereien von SWD zugegebenermaßen nicht so gut > aus aber für mich klang "connect under reset" immer ein bisschen nach > "connect after hardware reset", frei übersetzt aus dem Nein, aus dem RM0440, 46.4.4: "When debugging, the host performs the following actions: • Under system reset, all SWJ pins are assigned (JTAG-DP + SW-DP). • Under system reset, the debugger host sends the JTAG sequence to switch from the JTAG-DP to the SW-DP. • Still under system reset, the debugger sets a breakpoint on vector reset. • The system reset is released and the Core halts. • All the debug communications from this point are done using the SW-DP. The other JTAG pins can then be reassigned as GPIOs by the user software." D. h., das Debug-Interface ist aktiv, **während** Reset (NRST) aktiv ist. NJTRST und NRST sind zwei verschiedene Pins/Signale, ersteres ist nur für das JTAG-Interface, letzteres nur für die CPU samt Peripherie. > Französischen/Italienischen. Jedenfalls ist es bei mir immer so gewesen, > dass OpenOCD in einen Timeout lief, wenn ich den Hardware-Reset Button > nicht rechtzeitig losgelassen habe. Das Loslassen dauert aus Debugger-Sicht ja Ewigkeiten. Da wird wohl darauf gewartet, dass die CPU sich im Halt-Zustand befindet, während sie noch im Reset ist.
STLINKV2 vs StlinkV3: StlinkV3 ist schneller, kann aber nur mit ST Teilen sprechen.
A. B. schrieb: > Nein, aus dem RM0440, 46.4.4: > [...] > D. h., das Debug-Interface ist aktiv, **während** Reset (NRST) aktiv > ist. > NJTRST und NRST sind zwei verschiedene Pins/Signale, ersteres ist nur > für das JTAG-Interface, letzteres nur für die CPU samt Peripherie. Vielen Dank für den Hinweis, das hatte ich so nicht auf dem Schirm. A. B. schrieb: > Das Loslassen dauert aus Debugger-Sicht ja Ewigkeiten. Da wird wohl > darauf gewartet, dass die CPU sich im Halt-Zustand befindet, während sie > noch im Reset ist. Das ist gut möglich. Uwe B. schrieb: > STLINKV2 vs StlinkV3: StlinkV3 ist schneller, kann aber nur mit ST > Teilen sprechen. Ja, der V3 bietet 24MHz SWD, während der V2 (wimre) nur 4MHz bringt. Der V3 verfügt auch über High-Speed-USB, während der V2 nur Full-Speed macht. Das ST den V3 firmwareseitig auf ST-Produkte beschränkt ist zwar aus deren Sicht irgendwo verständlich aber ich persönlich finde solches Vendor-Lockin, naja, sagen wir mal vorsichtig formuliert "fragwürdig". Ein Grund mehr, die Black-Magic Firmware auf den V3 zu portieren ;)
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.