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 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
19 | |
20 | |
21 | |
22 | |
Der Ausdruck "legacy mode" tröstet mich überhaupt nicht :(
Angehängte Dateien:
-
pattern11.png
(10 KB)
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.
Gast
#7270659
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
Gast
#7270871
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 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
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 | |
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.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.