Mir sind ein paar Boards aus dem Schrott mit STM32F103 in die Hände gefallen und ich wollte ein wenig damit herumprobieren, quasi meine ersten STM32-Versuche... und habe natürlich auch gleich von den Dingern vor die Fresse bekommen.
Die Boards/ICs wollen sich partout nicht flashen lassen, egal was ich versuche, ich bekomme keine Verbindung zum Target. Ich habe es mit mehreren (wahrscheinlich China-) STM32 V2 Debugger-Sticks probiert, mit und ohne angeschlossenen NRST-Pin... mehrere Firmware-Versionen in diesen Sticks.
Jetzt kenne ich mich zu wenig mit STM32Fs aus, haben die Dinger eine Möglichkeit (wie eine Fuse z.B.) das Programmierinterface zu deaktivieren und wenn ja, kann man das irgendwie zurücksetzen, irgend einen harten chip erase machen, der den IC in den Werkszustand zurückversetzt? Bei den AVRs wüsste ich bescheid, aber leider nicht beim STM32F103 (Cortex-M3).
Mir ist auch aufgefallen, daß wenn man "connect under reset" und "hardware reset" wählt, wird von diesen STM32 V2 Debuggern gar kein Reset ausgelöst (nur wenn man diesen NRST-Pin auf Masse legt, dann hört eine LED auf dem Board mit Blinken auf). Kann es sein, daß ein an diesem Pin angeschlossener Kondensator zu groß ist und "weg muss"?
Falls das auf dem Board nichts wird, wie sieht die Minimalbeschaltung eines STM32F103 aus, damit man den an den Programmieradapter hängen und zumindest mal flashen kann? Müssen dafür alle Vdd/GND-Pins beschaltet werden oder reicht ein Päärchen aus? Welche Pins sind das Programmierinterface, stimmt NRST, PA13/PA14?
Für ein paar Tips von jemandem, der von den Dingern Ahnung hat, wäre ich sehr dankbar.
Jetzt kenne ich mich zu wenig mit STM32Fs aus, haben die Dinger eine
Möglichkeit (wie eine Fuse z.B.) das Programmierinterface zu
deaktivieren
Nicht direkt. Die Firmware kann das Interface deaktivieren, dazu muss sie aber natürlich erst einmal laufen. Wenn man den Reset betätigt (nRST-Pin low), wird das Programmierinterface (SWD+JTAG) reaktiviert. Indem man also die SWD/JTAG-Verbindung aufbaut während der Reset betätigt ist, kann die Software das nicht verhindern.
Über die Option Bytes kann man lediglich das Lesen/Schreiben des Flash verhindern, aber nicht das Verbinden per JTAG/SWD.
daß wenn man "connect under reset" und
"hardware reset" wählt, wird von diesen STM32 V2 Debuggern gar kein
Reset ausgelöst
Ja, die alten STLinks können das nicht (richtig). Ich glaube die neueren (STLink V3) sowie auch der Segger J-Link können das korrekt und dann funktioniert es meiner Erfahrung nach immer.
Falls das auf dem Board nichts wird, wie sieht die Minimalbeschaltung
eines STM32F103 aus, damit man den an den Programmieradapter hängen und
zumindest mal flashen kann?
Es gibt jede Menge extrem billiger STM32-Boards ("Blue Pill" und andere). Zum Basteln lohnt es sich kaum ein eigenes zu bauen (finanziell sowieso nicht). Alle Pins korrekt zu beschalten, mit Kondensatoren zu versehen, Quarz anschließen ist fummelig genug dass man lieber fertig kaufen kann.
Nur wenig teurer aber dafür direkt von ST, narrensicher und mit Funktionsgarantie sind die Nucleo-Boards:
Damit kann man problemlos ohne Fummelei loslegen. Mein persönlicher Favorit ist das NUCLEO-G031K8, extrem kompakt, super auf Lochraster lötbar, inklusive Debugger der nebenbei auch einen USB-Serialport implementiert, für ~10€. Da lohnt sich die Zeit kaum, irgendwelche alten STM32-Boards zu recyceln oder fragwürde Billigst-Boards zu kaufen.
Stammen die aus einem Gerät, bei dem zuvor
was auf den Controller geflasht wurde?
Ja.
Es gibt jede Menge extrem billiger STM32-Boards ("Blue Pill" und
andere). Zum Basteln lohnt es sich kaum ein eigenes zu bauen
(finanziell sowieso nicht). Alle Pins korrekt zu beschalten,
mit Kondensatoren zu versehen, Quarz anschließen ist fummelig
genug dass man lieber fertig kaufen kann.
Haben die Dinger keine interne Taktquelle (wie die AVRs), mit denen das Flashen nach chip erase möglich ist? Oder ist der chip erase nicht mehr möglich, wenn der interne Takt z.B. über diese option bytes deaktiviert wurde?
Klar kann man mit ein wenig Geld alles "erschlagen", aber diese Boards sind bereits da und mich reizt es schon, damit herumzuspielen - bzw. wenns nicht geht, einen der STMs davon runterzupopeln (Heißluft usw. ist alles da), die nötige Minimalbeschaltung dranzufrickeln und den Käfer "nackig" auf dem Tisch zu betreiben - erstmal sehen ob da überhaupt irgendwas funktioniert.
Ich denke mal du meinst den STLink V2?
Korrekt.
Ich habs auch versucht, den NRST dauerhaft auf GND zu halten, aber auch dann bekomme ich auf diesen Boards keine Verbindung via SWD oder so.
den NRST dauerhaft auf GND zu halten, aber auch
dann bekomme ich auf diesen Boards keine Verbindung via SWD oder so.
Oft funktioniert es, per Button den Reset für einen kurzen Moment vor dem Verbinden zu betätigen. Das Timing muss man im Gespür haben... Oder eben einen Debugger nutzen der das automatisch macht.
Yep. Bei den AVRs geht das und ja klar, ist keine Dauerlösung.
Reiner Versuchsaufbau.
Was für ein Aufwand für einen Pfennig-Artikel...
Bei Reichelt immerhin knapp drei Euro glaube ich. Und es sind mehrere da, zumindest die STM32 würde ich gerne recyclen. Macht aus finanzieller Sicht vielleicht keinen Sinn, aber wenn ich heute welche bestellen würde, sind auch erst Mittwoch da und schade um die bestückten ist es außerdem. Muss man ja nicht wegschmeißen wenn die noch gehen.
Was für ein Aufwand für einen Pfennig-Artikel, bei dem nichtmal
sicher ist, dass er nicht kaputt ist...
Zumindest blinkt auf dem Board eine LED, er reagiert auf den Reset... ganz kaputt sein kann das nicht.
Ich bin gespannt wie das mit den diversen Kondensatoren dran aussieht!
Versuch es mal mit dem UART-Bootloader, vielleicht sind da die Erfolgschangen höher als mit dubiosen STLink-Fakes.
Btw: Sicher dass an den SWD-Pins nicht noch irgendwas anderes dran hängt was die Signale blockiert? Mal mit dem Oszilloskop geprüft ob was an den IC-Pins ankommt? Gern auch das Timing mit dem nRST-Pin gegengeprüft?
wird von diesen STM32 V2 Debuggern gar kein Reset ausgelöst
Ja, die alten STLinks können das nicht (richtig)
Bei den ST-Link v2 Sticks ist der Reset-Ausgang auf der Pin-Reihe für STM8. Er hat bei STM32 keine Funktion. Die Fotos unter http://stefanfrings.de/stm32/stm32f1.html#stlink zeigen, wo man eine funktionierende Reset-Leitung abzweigen kann.
Für erste Versuche finde ich ebenfalls die Nucleo64 Boards besser. Da hat man erprobte Hardware, die deppensicher funktioniert. Den mitgelieferten Programmieradapter kann man später für andere Projekte mit verwenden oder gar abbrechen und einzeln verwenden.
Irgendwo las ich mal, daß bei den ST-Link-Clones der herausgeführte
Reset der für STM8 statt für STM32 ist.
So ist es. Deswegen ist der Anschluss auch auf der oberen Stiftreihe für STM8 ist. Für STM32 ist die untere Stiftreihe.
Hier wird behauptet, man könne das NRST-Problem der ST-Link-Clones
korrigieren
Ah, gut zu wissen.
immer wenn ich das brauchte, war ich dann doch zu faul und
habe einen Taster an NRST angeschlossen.
Dito. Entwicklungs-Boards sollten sowieso einen Reset Taster haben.
Bei meiner eigenen Software habe ich mir zudem angewöhnt, ganz am Programmanfang erst mal 1 Sekunde zu warten, bevor ich SWJ deaktiviere oder in einen Sleep Modus gehe. Dadurch wird das Zeitfenster größer, in dem man eine Verbindung aufbauen kann.
Wenn du in München bist, tausche STM32F103-Board gegen
ein Paulaner 🍻 Und Nutzung meines J-Link gegen Nutzung
eines Labor-Netzteils!
Unglücklicherweise hätte ich nur eine Berliner Weiße anbieten können, kein Münchener Paulaner.
Die Freiverdrahtung auf dem Tisch war leider nicht so gut. Hätte fast geklappt, aber es ist wirklich verdammt schwer, so viele dünne Kabel an den STM dran zu bekommen. Bliebe nur Einsetzen in einen Testsockel oder Auflöten auf eine Adapterplatine... und keine Ahnung, wie oft die so eine Prozedur mitmacht.
Taster an NRST löst zwar zuverlässig einen Reset aus, aber ich habe es nicht geschafft, Zugriff auf den Controller zu bekommen. Das STM-Flashtool wartet auch nicht besonders lange, sondern den Fehler bekommt man ziemlich sofort, also macht der wohl nur einen oder sehr wenige Versuche und wartet nicht, bis es klappt. Mit der CubeIDE genau so wenig Erfolg, absolut gleiches Verhalten.
V3miniE
Sollte man wahrscheinlich wirklich einplanen.
Was mich nun noch interessieren würde, kann ich den STM32 durch diesen Boot0-Pin oder wie der heißt zuverlässig im Bootloader festnageln, so daß die geflashte Software nicht gestartet wird? Vielleicht ist dann immerhin ein chip erase möglich und der sollte das Problem mit evtl. abgeschaltetem Programmierinterface beheben können.
Was mich nun noch interessieren würde, kann ich den STM32 durch diesen
Boot0-Pin oder wie der heißt zuverlässig im Bootloader festnageln, so
daß die geflashte Software nicht gestartet wird?
Ja, und das wurde dir hier bereits 2x geschrieben.
Hast du sicher gestellt, dass die Beschaltung des Mikrocontrollers durch das Board nicht stört? Stromversorgung weglassen (nur den µC versorgen) reicht nur selten.
