Moin, ich habe hier ein (von einem Kollegen entwickeltes) Board mit einem STM32G491. Er ist reiner Hardwerker. Ich kann das Programm auf den Controller flashen und auch verifizieren (sagt zumindest Keil µVision). Der Debugger tut aber nichts. Mit dem ST-Link Utility kann ich gar nicht erst auf den Controller zugreifen: 09:24:10 : V2J28S7 09:24:10 : Connected via SWD. 09:24:10 : SWD Frequency = 4,0 MHz. 09:24:10 : Connection mode : Connect Under Reset. 09:24:10 : Can not connect to the target! If you're trying to connect to an STM32W1xx device, please select Normal or HotPlug mode from Target->Settings menu. 09:24:12 : Unexpected error 09:24:14 : Disconnected from device. Andere Modi habe ich auch schon probiert: Nichts. Wie kriege ich den zum Laufen? Vielen Dank und viele Grüße Rahul
Wenn das Programm anläuft, werden zufällig deine Debug-Pins rekonfiguriert? ;-) Reset per Pinzette Low halten, Connect-under-Reset in der STLink-Utility auswählen und Reset-pin releasen, dann Chip-Erase und es sollte wieder gehen. Wo hast du den Chip momentan her? Will auch welche :-(
In Cube MX wird die SWJ Schnittstelle standardmäßig (durch den generierten Code) deaktiviert.
Stefan ⛄ F. schrieb: > In Cube MX wird die SWJ Schnittstelle standardmäßig (durch den > generierten Code) deaktiviert. Ich gehe davon aus, dass du die SWD-Schnittstelle meintest. In CubeMX war zwar "JTAG (4-wire)" eingestellt, µVision hat aber trotzdem den Controller geflasht (und den Code verifiziert). Im ST-Link-Utility (4.6) war die ganze Zeit SWD eingestellt, und es konnte überhaupt keine Verbindung aufgebaut werden.
Rahul D. schrieb: > 09:24:10 : Connection mode : Connect Under Reset. Hast du mal "SW Sytem Reset" probiert? Under Reset würde ja bedeuten das du den Controller im Reset halten musst bzw dein Debugger muss das tun (NRST muss dann aber auch angeschlossen sein) VG Paul
STK500-Besitzer schrieb: > Ich gehe davon aus, dass du die SWD-Schnittstelle meintest. Die Schnittstelle heißt SWJ, bzw. vollständig ausgeschrieben: SWJ-DP Sie unterstützt zwei Übertragungsprotokolle: SWD und JTAG.
Stefan ⛄ F. schrieb: > Die Schnittstelle heißt SWJ, bzw. vollständig ausgeschrieben: SWJ-DP > Sie unterstützt zwei Übertragungsprotokolle: SWD und JTAG. An dem Chip ist aufgrund seiner Größe (48 Pins) nur die SWD-Schnittstelle verfügbar - die anderen Pins werden anderweitig (Schnittstellen, GPIOs) gebraucht. Das sollte aber kein Problem sein, oder? Eigentlich sollte das STM32-Link-Utility doch auch mit einem komplett nackten Controller per SWD funktionieren, oder?
Rahul D. schrieb: > Das sollte aber kein Problem sein, oder? Ich weiß nicht was du brauchst. Für mich wäre es kein Problem. > Eigentlich sollte das STM32-Link-Utility doch auch mit einem > komplett nackten Controller per SWD funktionieren, oder? Ja, nicht nur "sollte", sondern es ist so.
Stefan ⛄ F. schrieb: > Ich weiß nicht was du brauchst. Für mich wäre es kein Problem. Für mich wohl auch nicht. NUCLEOs haben ja auch kein JTAG; und mit so einem (NUCLEO-L433) habe ich die bisherige Entwicklung gemacht, da es keins mit dem G491 zum Projektbeginn gab. Dafür gab es den L433 nicht in einem für uns lötbaren Gehäuse. Stefan ⛄ F. schrieb: > Ja Danke. Ich bin mit dem "neumodischen Zeug" etwas unsicher. hihi schrieb: > Wo hast du den Chip momentan her? Will auch welche :-( Direkt bei STM gab es noch welche, die wir komplett aufgekauft haben. :D Für sowas haben wir aber Einkäufer. ;)
Die Version des Firmware auf dem Debugger scheint steinalt "V2J28S7". Die kennt dir G49 Familie wohl nicht. Mach einen Update!
Uwe Bonnes schrieb: > Die kennt dir G49 Familie wohl nicht. Müsste er dann nicht wenigstens die ID des Target auslesen und dann meckern, dass sie unbekannt sei?
Uwe Bonnes schrieb: > Die Version des Firmware auf dem Debugger scheint steinalt > "V2J28S7". > Die kennt dir G49 Familie wohl nicht. Mach einen Update! Das hatte ich heute Morgen zwar auch gemacht, aber jetzt noch mal. Ergbnis: 16:07:54 : V2J37S7 16:07:54 : Connected via SWD. 16:07:54 : SWD Frequency = 4,0 MHz. 16:07:54 : Connection mode : Connect Under Reset. 16:07:54 : Can not connect to the target! If you're trying to connect to an STM32W1xx device, please select Normal or HotPlug mode from Target->Settings menu. 16:07:56 : Unexpected error Auch mit den anderen Modi wird der Controller nicht erkannt. Deine Vermutung widerspricht der Tatsache, dass Keil-MDK den Controller flashen und die Code verifizieren kann. (Warum das auch immer "geht"...). Ich tippe auf einen Hardwarefehler auf der Platine (deswegen die Vermutung / Frage bzgl. "nacktem" Controller und SWD). Das Programm initialisiert momentan nur das System und die Hardware (GPIO und Schnittstellen). Die RTC wird nicht genutzt und hat deswegen auch keinen Quarz. Die Initialisierung kommt von STM32CubeMX. Da gibt es keinen gravierenden Unterschied zu der des NUCLEO-Boards (andere Pinbelegung, zusättzlich Verwendung des VCP-UART).
Mit "ST-Link utility" meinst Du https://github.com/stlink-org/stlink? Dass muss natuerlich auch aktuell sein. Was sagen die ST Programmier Utilities zu dem Setup? Was openocd? Oder BMDA aka "blackmagic hosted"?
Uwe Bonnes schrieb: > Mit "ST-Link utility" meinst Du https://github.com/stlink-org/stlink? Wohl eher https://www.st.com/en/development-tools/stsw-link004.html (schätze ich)
Stefan ⛄ F. schrieb: > Uwe Bonnes schrieb: >> Mit "ST-Link utility" meinst Du https://github.com/stlink-org/stlink? > > Wohl eher https://www.st.com/en/development-tools/stsw-link004.html > (schätze ich) ja, genau.
So, mal eine kurze Rückmeldung: Mit dem STM32CubeProgrammer wird der Controller erkannt und kann beschrieben werden. Auch die OptionBytes etc. können gelesen und modifiziert werden. Aus Keil heraus funktioniert das Programmieren auch (mit dem STM-Tool gegengeprüft). Aber laufen tut der Controller immer noch nicht. Ich habe jetzt auch die nBOOT-Flags so gesetzt, dass er aus dem FLASH-Memory laufen soll. 0x08000000 ist auch in der Keil-Konfiguration angegeben. Wenn ich den Keil-Debugger laufen lasse, zeigt das Dissassembly-Fenster eine Start-Adresse ab 0x1FFF4E48 an, aber es läuft nichts. Woran könnte das jetzt noch liegen?
Rahul D. schrieb: > Wenn ich den Keil-Debugger laufen lasse, zeigt das Dissassembly-Fenster > eine Start-Adresse ab 0x1FFF4E48 an, aber es läuft nichts. > Woran könnte das jetzt noch liegen? So ein Verhalten hatte ich, wenn es eine Applikation war, die nicht auf Adresse 0x08000000 gelinkt war, und Stack-Pointer & Program Counter vom Debugger nicht entsprechend gesetzt wurden. Auf welche Adresse ist deine Applikation gelinkt? Hast du ein Debugger-Skript, was SP & PC setzt? Hast du mal einen Breakpoint im Reset-Handler gesetzt und bist dort vorbei gekommen oder landest du direkt an Adresse 0x1FFF4E48? Gruß Nick
Nick H. schrieb: > So ein Verhalten hatte ich, wenn es eine Applikation war, die nicht auf > Adresse 0x08000000 gelinkt war, und Stack-Pointer & Program Counter vom > Debugger nicht entsprechend gesetzt wurden. > > Auf welche Adresse ist deine Applikation gelinkt? Hast du ein > Debugger-Skript, was SP & PC setzt? Hast du mal einen Breakpoint im > Reset-Handler gesetzt und bist dort vorbei gekommen oder landest du > direkt an Adresse 0x1FFF4E48? Moin, ich hätte mich auch schon früher melden können. Es funktioniert. Der PB8/BOOT0-Pin muss auf GND gezogen werden. Irgendwie hat das mit den Config-Bits nicht hingehauen, weswegen die I²C-Schnittstelle noch auf einen anderen Pin umziehen musste. Das gibt halt eine Revision... Vielen Dank für die Hilfe.
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.