Programmierproblem mit dem STM32G491

[Rahul D. (rahul)]

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

[hihi (Gast)]

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 :-(

[Stefan F. (Gast)]

In Cube MX wird die SWJ Schnittstelle standardmäßig (durch den 
generierten Code) deaktiviert.

[STK500-Besitzer (Gast)]

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.

[Paul (Gast)]

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

[Stefan F. (Gast)]

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.

[Rahul D. (rahul)]

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?

[Stefan F. (Gast)]

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.

[Rahul D. (rahul)]

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

[Uwe Bonnes (Gast)]

Die Version des Firmware auf dem Debugger scheint steinalt "V2J28S7". 
Die kennt dir G49 Familie wohl nicht. Mach einen Update!

[Stefan F. (Gast)]

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?

[Rahul D. (rahul)]

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

[Uwe Bonnes (Gast)]

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"?

[Stefan F. (Gast)]

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)

[Rahul D. (rahul)]

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.

[Rahul D. (rahul)]

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?

[Nick H. (Gast)]

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

[Rahul D. (rahul)]

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.