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?
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?
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:
1
3.3.2 FLASH empty check
2
During the OBL phase, after loading all options, the Flash memory
3
interface checks whether the first location of the Main memory is
4
programmed. The result of this check in conjunction with the boot0
5
and boot1 information is used to determine where the system has
6
to boot from.
7
8
3.4.1 FLASH option byte description
9
Reset value: 0xFFFF FEAA (ST production value)
10
11
Bit 26 nBOOT0: nBOOT0 option bit
12
0: nBOOT0 = 0
13
1: nBOOT0 = 1
14
Bit 25 nBOOT1: Boot configuration
15
Together with the BOOT0 pin or option bit nBOOT0 (depending on
16
nBOOT_SEL option bit configuration), this bit selects boot mode
17
from the Main Flash memory, SRAM or the System memory.
18
Refer to Section 2.5: Boot configuration.
19
Bit 24 nBOOT_SEL: BOOT0 signal source selection
20
This option bit defines the source of the BOOT0 signal.
21
0: BOOT0 pin (legacy mode)
22
1: nBOOT0 option bit
Der Ausdruck "legacy mode" tröstet mich überhaupt nicht :(
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.
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
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.
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:
1
Caution:
2
If BOOT_LOCK is set in association with RDP Level 1,
3
the debug capabilities of the device are stopped and
4
the reset value of the DBG_SWEN bit of the FLASH_ACR
5
register becomes zero. If DBG_SWEN bit is not set by
6
the application code after reset, there is no way to
7
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.
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:
1
#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.
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.
Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.
Wichtige Regeln - erst lesen, dann posten!
Groß- und Kleinschreibung verwenden
Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang