der UART-Bootloader funktioniert beim STM32G0 nur einmal?

[Bauform B. (bauformb)]

Mahlzeit!

flasht hier jemand einen STM32 mit dem eingebauten UART-Bootloader? Und 
möchte jetzt mal einen G0 verwenden? Ich verstehe das RM0444 so, dass 
der eingebaute Bootloader nur mit fabrikneuen Chips funktioniert. Sobald 
0x08000000 einmal programmiert ist, kommt man nur noch per SWD-Debugger 
und connect under reset weiter.

Oder anders ausgedrückt: bei den G0 (evt. auch G4?) funktioniert der 
BOOT0-Pin nicht mehr. Das ist meine Theorie; gibt es damit schon 
praktische Erfahrungen?

[Kevin M. (arduinolover)]

Das kann ich mir fast nicht vorstellen, welchen Sinn sollte das haben?
Den G4 hab ich im Einsatz und benutze den USB Bootloader regelmäßig. 
Welcher der 1400 Seiten entnimmst du denn diese Information?

[Bauform B. (bauformb)]

Beim G4 ist es hoffentlich nicht so, weiß ich noch nicht.
Laut AN2606, STM32G07xxx/08xxx device bootloader, gilt Pattern 11, s.o.
und das RM0444 sagt zum G0x1:

3.3.2 FLASH empty check
  During the OBL phase, after loading all options, the Flash memory
  interface checks whether the first location of the Main memory is
  programmed. The result of this check in conjunction with the boot0
  and boot1 information is used to determine where the system has
  to boot from.

3.4.1 FLASH option byte description
Reset value: 0xFFFF FEAA (ST production value)

Bit 26 nBOOT0: nBOOT0 option bit
  0: nBOOT0 = 0
  1: nBOOT0 = 1
Bit 25 nBOOT1: Boot configuration
  Together with the BOOT0 pin or option bit nBOOT0 (depending on
  nBOOT_SEL option bit configuration), this bit selects boot mode
  from the Main Flash memory, SRAM or the System memory.
  Refer to Section 2.5: Boot configuration.
Bit 24 nBOOT_SEL: BOOT0 signal source selection
  This option bit defines the source of the BOOT0 signal.
  0: BOOT0 pin (legacy mode)
  1: nBOOT0 option bit

Der Ausdruck "legacy mode" tröstet mich überhaupt nicht :(

[Kevin M. (arduinolover)]

Das sagt doch nur das du in den Standard Einstellungen von ST über den 
Boot Pin entscheiden kannst, ob er vom System Memory oder dem Main Flash 
Memory booten soll. Ob da was geflashed wurde oder nicht tut nichts zur 
Sache, nur wenn du die Option Bytes abänderst kannst du den Boot Pin 
außer betrieb setzen. Das lässt sich aber jeder Zeit nochmal rückgägig 
machen.

[Oliver (Gast)]

Beim STM32G0 ist der Boot0 Pin inaktiv. Der Boot0 Pin kann also nicht 
benutzt werden, um das Anspringen des Bootloaders zu erzwingen. Damit 
kann auch nicht mehr via UART geflashed werden.

Da der Bootloader bei einem leeren Flashrom angesprungen wird, kann man 
genau einmal (bei einem leeren ROM) via UART flashen.

Glücklicherweise kann man den Boot0 Pin wieder aktivieren, wenn man das 
oben genannte nBOOT_SEL auf 0 setzt.

Also: Als allererste Aktion bei einem fabrikneuem STM32G0 sollte man via 
UART ein Programm flashen, dass dieses Bit dauerhaft auf 0 setzt. Zum 
Beispiel dieses hier: 
https://github.com/olikraus/stm32g031/tree/main/enable_boot0

Alternativ kann man das Bit auch via SWD auf 0 setzen.

Oliver

[A. B. (Gast)]

Man kann sich auch seinen eigenen BOOT-Pin definieren: Beim Startup (.s) 
zuallererst irgendeinen (naja, es sollte keiner sein, den der 
Bootloader verwendet) Pin auf Eingang konfigurieren, und dann in 
Abhängigkeit vom Zustand in den Bootloader springen oder mit dem 
"normalen" Startup weiter machen ...
Da spielt dann auch eine event. vergurkte Firmwareversion keine Rolle 
und man hat sein persönliches BOOT-pattern.

[Bauform B. (bauformb)]

A. B. schrieb:
> Man kann sich auch seinen eigenen BOOT-Pin definieren: Beim Startup (.s)
> zuallererst irgendeinen (naja, es sollte keiner sein, den der
> Bootloader verwendet)

Der PA14 würde sich anbieten, den ignoriert der Bootloader ja nun. 
Außerdem sollte der zwecks SWD auch von draußen zugänglich sein. Und, 
dank SWCLK, wird beim Reset der interne Pull-Up eingeschaltet. Also, 
kein Nachteil ohne Vorteil.

Natürlich funktioniert es auch so wie Oliver schreibt. Allerdings ist 
das nichts für Feiglinge, mit den Option-Bits kann man den Chip 
tatsächlich dauerhaft unbenutzbar machen:

Caution:
If BOOT_LOCK is set in association with RDP Level 1,
the debug capabilities of the device are stopped and
the reset value of the DBG_SWEN bit of the FLASH_ACR
register becomes zero. If DBG_SWEN bit is not set by
the application code after reset, there is no way to
recover from this situation.

Sowas kann einem mit RDP Level 2 bei allen STM32 passieren, aber beim G0 
reicht schon Level 1. Und alle diese Bits sitzen im gleichen Wort.

[Moot S. (mootseeker)]

Oliver schrieb:
> Beim STM32G0 ist der Boot0 Pin inaktiv. Der Boot0 Pin kann also nicht
> benutzt werden, um das Anspringen des Bootloaders zu erzwingen. Damit
> kann auch nicht mehr via UART geflashed werden.

Mann kann doch den Bootloader auch aus dem Code erzwingen, indem man an 
seine Flash Adresse springt. Bei den G0 ist das doch die Adresse:

 #define STM32G031_SYSTEM_MEM_ADDR ( 0x1FFF0000 )

Oder liege ich mit dieser Annahme falsch?

Bei anderen STM32 Schaltungen sind die Boot0 Pins immer mit einem Pull 
down Widerstand auf LOW gezogen, aber können aus dem Code trotzdem in 
den Bootloader springen.

[Bauform B. (bauformb)]

Moot S. schrieb:
> Bei anderen STM32 Schaltungen sind die Boot0 Pins immer mit einem Pull
> down Widerstand auf LOW gezogen, aber können aus dem Code trotzdem in
> den Bootloader springen.

Die Logik funktioniert umgekehrt, ODER statt UND. Der BOOT-Pin kann 
nicht verhindern, dass du den Bootloader aus deinem Code heraus 
startest. Das geht auch, wenn der Pin wirkungslos ist oder auf Low.

Es geht allerdings nicht, wenn mein Code nicht funktioniert. Und das 
passiert bei "Verbesserungen" am Programm ständig. Genau dafür wäre der 
BOOT-Pin die Rettung, damit könnte man immer neu flashen, egal, wie 
vermurkst der alte Flash-Inhalt ist.

> Mann kann doch den Bootloader auch aus dem Code erzwingen, indem man an
> seine Flash Adresse springt. Bei den G0 ist das doch die Adresse:
> #define STM32G031_SYSTEM_MEM_ADDR ( 0x1FFF0000 )
>
> Oder liege ich mit dieser Annahme falsch?

Die Adresse ist richtig ;) Der "Sprung" selbst ist allerdings nicht 
trivial. Im Forum gibt es ein paar Threads dazu, mit wenig überzeugenden 
Lösungen. Wenn man es einmal zum Laufen gebracht hat, ist das gut für 
Firmware-Updates beim Kunden, aber nicht bei der Entwicklung (s.o.).

Das Option-Bit ist (für mich) keine Lösung, schon garnicht per SWD. Das 
Risiko, versehentlich eins der anderen Bits zu ändern, ist mir zu groß. 
Und wenn's ein TQFP-64 ist, ist praktisch die ganze Platine Schrott.