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?
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.
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.
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.
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 ;)
