Gerade eben habe ich versucht ein BluePill Board mit einem ST-Link zu
programmieren.
Ich konnte das Blink-Beispiel genau einmal flashen. Dann habe ich es zum
zweiten Mal probiert, und es ging nicht mehr.
Ich dachte, das Board hat einen Schuß abbekommen. Deshalb noch ein
Versuch mit einem zweiten Board: Wieder dasselbe. Einmal flashen, danach
falsche ID.
Ist das ein OTP?
Der Sketch verwendet 33100 Bytes (25%) des Programmspeicherplatzes. Das
Maximum sind 131072 Bytes.
Globale Variablen verwenden 8468 Bytes (41%) des dynamischen Speichers,
12012 Bytes für lokale Variablen verbleiben. Das Maximum sind 20480
Bytes.
/home/christoph/tools/arduino-1.8.5/hardware/STM32GENERIC/tools/linux/st
link_upload ttyACM1 {upload.altID} {upload.usbID}
/tmp/arduino_build_570159/graphProgArduino.ino.bin
2020-02-16T10:19:23 INFO src/common.c: Loading device parameters....
2020-02-16T10:19:23 WARN src/common.c: unknown chip id! 0
Markus schrieb: > Ist das ein OTP? Nein, du hast mit deinem Programm-Beispiel wahrscheinlich die SWD-Schnittstelle disabled.
>Nein, du hast mit deinem Programm-Beispiel wahrscheinlich die >SWD-Schnittstelle disabled. Oha, Du meinst die SWDIO-Pins sind disabled und damit kann der ST-Link nicht mehr zugreifen? Wie bekomme ich die Boards wieder zum laufen?
Markus schrieb: > Die Boot-Jumper sind wie im Bild gesetzt. Setze sie beide nach rechts und drücke den Reset Knopf, dann kann du den Chip erneut flashen. Danach stckest du sie wieder nach links um, um das Programm auszuführen. Hintergrund: SWD wird beim Reset aktiviert (so wie auch ISP bei AVR Mikrocontrollern), aber von deinem Programm deaktiviert. Daher kann der Programmieradapter diese Schnittstelle nicht mehr ansprechen. SWD fällt aus, wenn man die Pins als "normale" I/O Pins einstellt oder indem man einen Sleep-Modus aktiviert. Durch Umstecken der Jumper aktivierst du den eingebauten seriellen Bootloader. Dein Programm startet nicht mehr. Der Bootloader lässt die SWD Schnittstelle aktiv. Alternative Vorgehensweise: Reset-Knopf gedrückt halten und bei Beginn der Übertragung loslassen. Das ist ein bisschen Tricky weil man den richtigen Zeitpunkt finden muss, wo man loslassen muss. Dafür leiert man aber nicht die Jumper aus, die Mühe lohnt sich also, wenn man es oft macht. Es gibt bei Youtube Videos, die das vorführen.
Markus schrieb: > Wie bekomme ich die Boards wieder zum laufen? "Connect under Reset" Leider ist die Reset-Leitung nicht herausgeführt, daher muss man das von Hand machen. Also kurz im richtigen Augenblick vor Programmieren den Reset-Knopf drücken. Klappt manchmal aber nicht immer. Versuch macht kluch. Zuvor solltest du rausbekommen welcher Teil deiner Software den SWD disabled. Sinnvoll ist es auch erst mal mit dem ST-Link Utility ein Erase zu machen um zu sehen ob es funktioniert.
Markus schrieb: > Die Boot-Jumper sind wie im Bild gesetzt. Sieht nach dem defekten BluePill aus China aus mit dem Fake STM32. Der macht, was er will, also vor allem nicht das was man von einem heilen erwarten kann. Schmeiss es weg, Lehrgeld, es ist sinnlos herausfinden zu wollen was auf ihm nicht geht und wie man die Defekte umgeht. Schreibe noch schnell eine negative Kritik an den Händler.
Beo Bachta schrieb: > Markus schrieb: >> Wie bekomme ich die Boards wieder zum laufen? > > "Connect under Reset" > > Leider ist die Reset-Leitung nicht herausgeführt, daher muss > man das von Hand machen. Also kurz im richtigen Augenblick > vor Programmieren den Reset-Knopf drücken. Klappt manchmal > aber nicht immer. Versuch macht kluch. Am ST-Link ist die Resetleitung rausgeführt und an dem Board ist der Pin mit R beschriftet. Wenn man diese Pins verbindet müsste es gehen.
MaWin: >Sieht nach dem defekten BluePill aus China aus mit dem Fake STM32. Die BluePill sind schon älter, die habe ich hier schon mindestens 3 Jahre rum liegen. Deshalb sind es wohl eher keine Fakes. Stefan: >Setze sie beide nach rechts und drücke den Reset Knopf, dann kann du den >Chip erneut flashen. Danach stckest du sie wieder nach links um, um das >Programm auszuführen. Danke für den Hinweis. Es geht aber anscheinen nicht. Ich habe den seriellen Bootloader probiert: Boot0->rechts Boot1->links Reset drücken Damit kann ich dann seriell flashen. So wie hier: https://medium.com/@paramaggarwal/programming-an-stm32f103-board-using-usb-port-blue-pill-953cec0dbc86 ( Jumper Position falsch eingezeichnet ) Aber eigentlich will ich den SWD zurück ....
Markus schrieb: > Es geht aber anscheinen nicht. Doch es geht. Stefanus hat es dir genau(er) erklärt: Stefan ⛄ F. schrieb: > Reset-Knopf gedrückt halten und bei Beginn der Übertragung loslassen. "Beginn der Übertragung" bedeuted der ST-Link hat gerade sein serielles Protokoll gestartet (nach deinem Flash-Knopf drücken).
Angehängte Dateien:
-
st-link.jpg
130 KB
TR.OLL schrieb: > Am ST-Link ist die Resetleitung rausgeführt Nicht bei den chinesischen Sticks. Deren Reset Ausgang funktioniert nur für STM8. Ich vermute, dass der TO so einen Stick verwendet, da diese oft zusammen mit dem genannten Blue-Pill Board genannt und angeboten werden.
Markus schrieb: > Ich habe den seriellen Bootloader probiert: > Boot0->rechts > Boot1->links > Reset drücken > Damit kann ich dann seriell flashen. Da der serielle Bottloader funktioniert, müsste die SWD Schnittstelle ebenfalls funktionieren. > Es geht aber anscheinen nicht. Seltsam.
Angehängte Dateien:
-
BluePill_SWD_setup.png
660 KB
>Ich vermute, dass der TO so einen Stick verwendet, da diese oft zusammen >mit dem genannten Blue-Pill Board genannt und angeboten werden. Mein ST-Link sieht genau so aus: https://www.mikrocontroller.net/attachment/330146/ST-LinkV2_pinout_01.jpg Ich habe gerade mal Pin 1 ( RST ) des ST-Link mit dem R-Pin des BluePill verbunden und das Oszi parallel dazu. Ergebnis: Der Reset-Pin wird vom ST-Link nicht beeinflusst. Oben sind meine Einstellungen, vielleicht fällt euch ja was auf.
Markus schrieb: > Mein ST-Link sieht genau so aus: Witzig, das Foto zweigt zwei unterschiedliche Produkte. Ok, die Platine innerhalb der Gehäuse ist vielleicht identisch. > Ergebnis: Der Reset-Pin wird vom ST-Link nicht beeinflusst. Sage ich doch! > Oben sind meine Einstellungen, vielleicht fällt euch ja was auf. Nein, das sieht alles gut aus.
>Witzig, das Foto zweigt zwei unterschiedliche Produkte.
Tschuldigung, der linke auf dem Bild ist es.
Markus schrieb: > Oben sind meine Einstellungen, vielleicht fällt euch ja was auf. Mit der Arduino IDE hast du keinen sehr direkten Zugriff auf dein Board. Du weisst nicht was da im Hintergrund alles gemacht wird. Daher mein Rat: Beo Bachta schrieb: > Sinnvoll ist es auch erst mal mit dem ST-Link Utility ein > Erase zu machen um zu sehen ob es funktioniert. Jetzt frage nicht was ein "ST-Link Utility" ist.
>Tschuldigung, der linke auf dem Bild ist es.
Nein, doch der rechte. Jetzt muss ich mal Mittag machen, sonst gibt's
noch mehr Fehler.
Markus schrieb: > vielleicht fällt euch ja was auf. Auf dem BluePill ist normalerweise ein F103C8T6 drauf. -------------------------------------------^^---------
Wenn das Problem wirklich das abgeschaltete swd ist, dann steck einfach die jumper so, dass der bootloader lädt. Nach einem reset startet der und lässt die swd an. Dann hast du alle Zeit der Welt dich mit stlink zu verbinden und die Firmware auszutauschen. Danach zurück stecken und deine fw läuft wieder.
Beo Bachta schrieb: > Mit der Arduino IDE hast du keinen sehr direkten Zugriff > auf dein Board. Du weisst nicht was da im Hintergrund alles > gemacht wird. Das ist hier aber ganz sicher nicht die Problemursache. Ich habe das mehrmals erfolgreich so benutzt - obwohl ich kein Arduino Fan bin.
Also ... Stefan's Tipp war der richtige. Beide Boot-Pins nach rechts, dann lässt sich die Sache wieder flashen. Mein Fehler: Ich habe das ganze nach den ersten Versuchen neu gesteckt und dann ein graues mit einem weisen Kabel verwechselt .... Noch ein wenig Historie zu der ganzen Sache: Eigentlich wollte ich das ganze mit dem STM32Duino-Core Framework ausprobieren. Aber: Die Installation ist auf einem anderen Rechner und das Core-Framework will den ST-Link-Adapter updaten. Das geht leider nicht so einfach. Nachdem ich schon eine riesen Installationsorgie für den neuen ST-Link unter Ubuntu hatte ( man kann das ST-Tool nicht mehr so einfach herunter laden, sondern muss sich anmelden und soll das Java Framework auch noch anpassen ), hätte man für das Update des ST-Link wieder einen neuen Treiber und wieder mit Anmeldung gebraucht. Das war mir dann irgendwann zu doof und ich habe beschlossen, dass es das alte GENERIC-Framework auch tut.
Markus schrieb: > Beide Boot-Pins nach rechts, dann lässt > sich die Sache wieder flashen. Glaube ich nicht. Ich weiß dass ich das geschrieben habe, aber ich denke, du solltest doch nur den Boot0 Jumper umstecken, weil die CPU sonst irgendeinen zufälligen Code aus dem RAM ausführt. Markus schrieb: > ich habe beschlossen, dass es das alte > GENERIC-Framework auch tut. Gute Entscheidung.
>Glaube ich nicht. Ich weiß dass ich das geschrieben habe, aber ich >denke, du solltest doch nur den Boot0 Jumper umstecken, weil die CPU >sonst irgendeinen zufälligen Code aus dem RAM ausführt. Kann sein, dass ich den SWD durch das flashen über die serielle Schnittstelle wieder zum leben erweckt habe. Mal was anderes, nicht zum Thread passendes: Ich suche eine PWM zur Audio-Ausgabe für das GENERIC-Framework. Im Code gibt's eine sonst nicht anderweitig dokumentierte PWM-Funktion: https://github.com/danieleff/STM32GENERIC/blob/master/STM32/cores/arduino/stm32/stm32_PWM.c Was haltet ihr davon? Soll ich einen neuen Thread aufmachen?
Ich würde Audioausgabe per PWM lieber selbst programmieren, alleine schon deswegen, weil das Arduino Framework dazu vermutlich zu langsam ist.
Markus schrieb: > Kann sein, dass ich den SWD durch das flashen über die serielle > Schnittstelle wieder zum leben erweckt habe. Da gibt es garnichts "wieder zum Leben erwecken". Der ist ab Reset aktiv - alles Andere macht deine Firmware. Stattdessen solltest du für dein Projekt dir klarmachen, welche Funktionen du den Pins deines Chips zuordnen willst und das dann auch genau so durchziehen. Und wenn du die SWD-Pins anderweitig zu verwenden gedenkst, dann sollte es dir auch klar sein, daß du damit SWD eben ausschaltest. Zumindest ein wenig Planung sollte man auch bei einem nur 48 pinnigen IC betreiben. Zumindest wird soviel Verständnis eigentlich erwartet. W.S.
Markus schrieb: > Mal was anderes, nicht zum Thread passendes: > Ich suche eine PWM zur Audio-Ausgabe für das GENERIC-Framework. Aber doch nicht für einen STM32F103C8T6 - da wird der Flash recht schnell zu klein. Und das Ganze braucht Interrupts in Samplefrequenz, da sollte dann am ehesten Assembler angesagt sein. Guck dir einfach mal die angehängte Datei an, gong.inc ist SOL komprimierter Sound. W.S.
W.S. schrieb: > Markus schrieb: >> Mal was anderes, nicht zum Thread passendes: >> Ich suche eine PWM zur Audio-Ausgabe für das GENERIC-Framework. > > Aber doch nicht für einen STM32F103C8T6 - da wird der Flash recht > schnell zu klein. Und das Ganze braucht Interrupts in Samplefrequenz, da > sollte dann am ehesten Assembler angesagt sein. Man kann natürlich auch DMA verwenden, dann geht das auch in C++. 8 PWM-Kanäle mit 16bit Auflösung und Waveform-Generierung für jeden Kanal per DDS. Nur mal so zum Ausloten der Möglichkeiten zusammengebaut.
Wahrscheinlich ist Assembler der richtige Weg, so wie es W.S. gezeigt hat. C ist für Audioanwendungen viel zu langsam. Besonders auf so einen schwachen Prozessor.
Carl D. schrieb: > Man kann natürlich auch DMA verwenden, dann geht das auch in C++. 8 > PWM-Kanäle mit 16bit Auflösung und Waveform-Generierung für jeden Kanal > per DDS. Was soll dein Beitrag bedeuten? Nicht nachgedacht, gelle? Also, DMA kann hier garnichts verbessern, denn DMA kann nur blind von A nach B schaufen. Hier ist aber gefragt, im Takte der Samplefrequenz einen Samplewert aus einem komprimierten Sound zu extrahieren, zu expandieren, mit Offset zu versehen und in da PWM-Register eines Counter/Timer-Blocks zu schreiben. Für sowas braucht es die CPU, da ist Maschinencode erforderlich. Im gezeigten Beispiel hatte ich den FIQ des ARM7TDMI benutzt, weil der nämlich über einige Schattenregister verfügt, so daß ich das Retten und Restaurieren von einigen CPU-Registern mir ersparen konnte - aus Zeitgründen. Was man nämlich an Samplefrequenz handhaben kann, hängt direkt davon ab, wie schnell oder lahm der Interrupthandler ist. Und mit dem gezeigten Code kann man Sound ausgeben, also nen Gong oder ne Begrüßung als gesprochener Text oder Musik oder sonstwas. Was also soll da der Hinweis auf 8 PWM-Kanäle mit 16 Bit Auflösung und obendrein auch noch DDS ? Hier war doch Audio Ausgabe nachgefragt - und nicht nur nen Sinus ausgeben. Abgesehen davon solltest du vor dem Posten mal das Gehirn einschalten: 16 Bit PWM Auflösung würde bedeuten, daß der PWM mit 65K fachem Takt der Samplefrequenz laufen müßte - und das auf dem BluePill mit einem Takt von maximal 72 MHz. Das ergibt etwas mehr als 1 kHz Samplefrequenz. Was bittesehr soll das? W.S.
W.S. schrieb: > Carl D. schrieb: >> Man kann natürlich auch DMA verwenden, dann geht das auch in C++. 8 >> PWM-Kanäle mit 16bit Auflösung und Waveform-Generierung für jeden Kanal >> per DDS. > > Was soll dein Beitrag bedeuten? Nicht nachgedacht, gelle? > > Also, DMA kann hier garnichts verbessern, denn DMA kann nur blind von A > nach B schaufen. Schreibt einer, der behauptet man müßte für jedes Sample einen Interrupt ausführen. > Und das Ganze braucht Interrupts in Samplefrequenz, da sollte dann am > ehesten Assembler angesagt sein Ein echter Schlauberger halt.
Carl D. schrieb: > Ein echter Schlauberger halt. Du weist doch W.S. hat von nichts ne Ahnung aber will immer mitreden. Er weis ja nichtmal wie man einen DMA nutzt. Also dass man vorher einen Buffer füllt und dann überträgt man das schön Jitterfrei per DMA mit Timeranstoß rüber.
Angehängte Dateien:
-
stlink-bluepill.png
150 KB
Leute, ehrlich gesagt verstehe ich hier einige Beiträge nicht bis garnicht. Eben habe ich den Kram ausgegraben und ausprobiert: - Ein ST-Link/V2 China Dongle mit "neuem" Board+Layout+Pinout siehe [https://stm32-base.org/guides/connecting-your-debugger] - Eine Blue Pill (typischer China clone, mit versautem R10 und schwachem XC6204 150mA LDO) ST-Link Dongle meldet sich
1 | $ dmesg | tail -n 6 |
2 | [ 2782.674592] usb 2-3: new full-speed USB device number 13 using xhci_hcd |
3 | [ 2782.823836] usb 2-3: New USB device found, idVendor=0483, idProduct=3748, bcdDevice= 1.00 |
4 | [ 2782.823839] usb 2-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3 |
5 | [ 2782.823840] usb 2-3: Product: STM32 STLink |
6 | [ 2782.823842] usb 2-3: Manufacturer: STMicroelectronics |
7 | [ 2782.823843] usb 2-3: SerialNumber: P |
8 | |
9 | $ lsusb | grep STM |
10 | Bus 002 Device 013: ID 0483:3748 STMicroelectronics ST-LINK/V2 |
Die beiden wie folgt verbunden:
1 | IDC SWD |
2 | 2 SWDIO 3 |
3 | 4 GND 1 |
4 | 6 SWCLOCK 2 |
5 | 8 3V3 4 |
In der Arduino IDE das Blink Example geladen. Der CPU Speed muss allerdings runter auf 48MHz. Upload... fertig. Nix Boot-Jumper, nix Reset oder Quatsch. Die PlatformIO SWD teste ich auch gleich mal. Wenn ich es in Erinnerung habe muss zum CDC_ENABLE noch die VID+PID in die build_flags rein. Hat ja damals auch schon geruled. Oder was ist nun richtig/falsch? Auuutsch! Da habe ich eben eine 1Jahre alte Leiche ausgegraben. Bitte vielmals um Entschuldigung!
:
Bearbeitet durch User
Mister A. schrieb: > Leute, ehrlich gesagt verstehe ich hier einige Beiträge nicht bis > garnicht. Merkt man. Dein Beitrag hat mit dem Problem des des TO (Markus) nichts zu tun. Die Lösung hat er längst bekommen.
Ja, Stefan. War ein versehen. Aber bekommen hat er was mit dem Boot-Jumper und Reset-Button. Hier ist etwas ohne beides :) btw: möchtest du auf deiner Seite [http://stefanfrings.de/stm32/stm32f1.html] den Abschnitt ST-Link Adapter etwas überarbeiten? >ST-Link Adapter >Die passenden Programmieradapter von ST heißen "ST-Link". Billige Nachbauten aus China sehen so aus: >Mir wurde berichtet, daß Sticks mit falscher Pinbelegung im Aufdruck verkauft wurden. Meine waren alle richtig beschriftet. Die neuen clones seit mind. 1 Jahr haben ein anderes Board+Pinout. Und wie Markus schrieb: > Mein ST-Link sieht genau so aus: > https://www.mikrocontroller.net/attachment/330146/ST-LinkV2_pinout_01.jpg
Du hast deinen ST-Link ohne Reset Leitung angeschlossen. Das war genau
die Konstellation, die beim TO nicht funktioniert hat, weil sein
Anwendungsprogramm die SWD Schnittstelle deaktiviert hatte.
Die Lösung war, den Bootloader zu aktivieren, damit SWD aktiv bleibt.
> Die neuen clones seit mind. 1 Jahr haben ein anderes Board+Pinout.
Beide Formen sind seit mindestens 5 Jahren parallel im Handel.
Ist für Arduino ohnehin wie eine gestutze Ente, den besten Zugriff hat man über eine IDE für Cortex. Da braucht es weder Bootloader noch anderes, swd nutzen und fertig.
1 | /* Busclocks setzen */
|
2 | RCC_HCLKConfig(RCC_SYSCLK_Div2); // AHB Clock auf Maximum 72 Mhz |
3 | RCC_PCLK1Config(RCC_HCLK_Div2); // APB1 Clock auf 36Mhz (36 Mhz ist Maximum) |
4 | RCC_PCLK2Config(RCC_HCLK_Div2); // APB2 Clock auf 36Mhz |
5 | |
6 | /* JTAG Interface abschalten, SWD einschalten (PB3, PB4 freimachen) */
|
7 | RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOB | RCC_APB2Periph_AFIO, ENABLE); |
8 | GPIO_PinRemapConfig(GPIO_Remap_SWJ_JTAGDisable, ENABLE); |
Thread beobachten
Seitenaufteilung abschalten
Bitte 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.