STM32H7 Bootloader funktioniert nur sporadisch

[Dustin L. (weeky)]

Hallo,
ich habe folgendes Problem mit meinem Board auf STM32H743VI - Basis.

Eckdaten:
- STM32H743VI
- SWD an ARM 10-Pin Konnektor für den Anschluss eines J-Links
- Raspberry Pi Compute Module 4
- UART5 des Compute Modules mit PA2/PA3 des STM32H743 verbunden
- BOOT0 des Mikrocontrollers mit 10k gegen Ground und an einem GPIO des 
Compute Modues angeschlossen
- NRST des Mikrocontrollers per Open-Drain Schaltung mit einem GPIO des 
Compute Modules verbunden

Versuchtes Vorgehen:
- BOOT0 Pin per GPIO des Compute Modules auf 3.3V setzen
- Reset für 1s gegen GND ziehen, dann wieder loslassen
- per UART Bootloader neuen Code auf den STM32 aufspielen

Beobachtetes Verhalten:
- in jedem Fall springt der Mikrocontroller in einen Zustand in dem 
keine Usercode ausgeführt wird (mit blinkender LED verifiziert), und 
schaltet die, dem Bootloader zugeordneten UARTs ein (High-Pegel auf TX 
verfiziert)
- in etwa 5 von 10 Fällen lässt sich der Bootloader aber nicht 
ansprechen. Nicht über das "stm32flash"-Tool und nicht über den 
"STM32CubeProgrammer". Auch auf die rohen Befehle definiert in AN3155 
reagiert der Mikrocontroller nicht.
- Manchmal funktioniert das vorgehen 10 mal in Folge, dann wieder 10 mal 
in Folge nicht
- Längerer Reset scheint gelegentlich zu funktionieren
- IN JEDEM FALL funktioniert ein Anstecken eines USB Kabels und das 
verwenden des DFU Bootloaders über den "STM32CubeProgrammer".
- korrekte Signalpegel am NRST und BOOT0 Pin habe ich verifiziert.

Anbei die Schematics und die Beschaltung des NRST Pins. Hat jemand eine 
Vermutung woran das liegen könnte?

[drm (Gast)]

ST AN2606: STM32 microcontroller system memory boot mode
one of the available serial peripherals (such as USART, CAN, USB, I2C, 
SPI).

wenn du mit Boot0 der CPU zu erkennen gibst das sie nicht vom internen 
Flash booten soll, sondern über eine der oben aufgeführten "serial 
peripherals", dann bootet sie von der seriellen Schnittstelle, an der 
der Bootloader als erstes einen Flankenwechsel feststellt.
Soll also von UART gebootet werden, dann musst du sicherstellen das auf 
allen anderen seriellen Schnittstellen kein Flankenwechsel stattfindet 
bevor nicht der Bootvorgang auf Uart erfolgreich war.

Lösung: Pullup/Pulldown Widerstände an alle betroffende Leitungen.
Falle für Anfänger: Das Pinout von denen gebootet werden kann ist fix ! 
Also Datenblätter lesen. Ein Ummappen von z.B. I2C auf andere Pins 
bedeutet nicht das diese Änderung auch für den Bootloader gilt.

[drm (Gast)]

für dich/STM32H743VI in AN2606:
Seite 267ff

[Dustin L. (weeky)]

drm schrieb:

> Lösung: Pullup/Pulldown Widerstände an alle betroffende Leitungen.
> Falle für Anfänger: Das Pinout von denen gebootet werden kann ist fix !
> Also Datenblätter lesen. Ein Ummappen von z.B. I2C auf andere Pins
> bedeutet nicht das diese Änderung auch für den Bootloader gilt.

Danke, die AN2606 habe ich die ganze Zeit schon offen, dachte aber 
nicht, dass meine offenen UART Leitungen das Problem sein könnten?
Die anderen Leitungen sind momentan einfach nur über das Board auf 
Ausgänge geführt. Also können es einfach Störungen von Außen sein, die 
das beeinflussen? Also Pull-Up an TX und Pull-Down an RX?

[Dustin L. (weeky)]

Ich dachte, dass der Controller ein 0x7F erwartet, bevor er andere 
Quellen ausschaltet.

[drm (Gast)]

Seite 267 bis 270 listet alle IO Pins auf die nicht floaten dürfen.
Je länger die offenen Leitungen an diesen Pins sind, um so eher erfolgt 
darauf ein Flankenwechsel. Übrigens, das floaten messen geht nicht, das 
Messgerät wäre ein Pulldown von 1M Ohm, das kann schon reichen. 100k Ohm 
ist meist eine sichere Sache.

[drm (Gast)]

>Ich dachte, dass der Controller ein 0x7F erwartet
jede Datenübertragung startet mit einem Flankenwechsel.
Um zu prüfen ob 0x7f übertragen wurde muss er schon in den 
entsprechenden Bootloader der Schnittstelle wechseln. Wie in deinem 
Screenshot zu sehen gibt es keine Rückkehr in die Schnittstellenauswahl 
wenn nicht 0x7f empfangen wurde

[drm (Gast)]

0x7f gilt eh nur für USART, bei allen anderen reicht der Flankenwechsel

[Dustin L. (weeky)]

Danke! Ganz verstehe ich es aber noch nicht. Wieso lässt sich DFU aber 
in jedem Fall verwenden?

[Dustin L. (weeky)]

drm schrieb:
> 0x7f gilt eh nur für USART, bei allen anderen reicht der Flankenwechsel

Danke, ich denke das war das Problem. Ich schicke jetzt direkt nach dem 
Reset (ohne Zeiverzögerung) ein 0x7F auf dem entsprechenden UART und 
warte auf das ACK Byte. Sollte das nicht kommen wird das von vorn 
ausgeführt. Vorher war zwischen Reset und Flashversuch ein Delay von 
einigen Sekunden. So "reserviere" ich diesen UART mit geringer Chance, 
dass Störungen von außen ein anderes Interface forcieren. Das 
funktioniert jetzt soweit.