Programmierproblem mit dem STM32G491

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

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?

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.