STM32L1 Bootloader (USART)

[Joe F. (easylife)]

Ich versuche erfolglos auf einem STM32L1 den USART Bootloader zum 
Antworten zu bewegen.
BOOT0 ist high, BOOT1 low. Das Flash ist komplett erased.
Ich hole den STM32 aus dem Reset, warte > 3 Sekunden, und schicke dann 
über USART2_RX ein 0x7F in der Erwartung, dass der Bootloader auf 
USART2_TX ein ACK schickt. Es sollte ja aufgrund des 0x7F eine 
Baudratenerkennung stattfinden, und ein ACK byte rausgeschickt werden. 
Dies passiert nicht. TX ist einfach dauer-high.

Baudrate ist 57600 baud, 8E1, LSB first, Polarität wie im Anhang.

Hat jemand eine Idee, was da schief gehen könnte?
LSB/MSB falsch? Polarität falsch? Ich finde zu den Hardware-Details des 
USART im Bootloadermode auch keine Doku.

[W.S. (Gast)]

Lade dir mal mein STM32Prog von hier herunter und probiere es damit. Da 
kannst du jedenfalls erstmal testen, ob deine Verbindung überhaupt 
funktioniert.

W.S.

[Marcus H. (Firma: www.harerod.de) (lungfish)]

Aus leidvoller Erfahrung:
Welcher Chip / Revision?
Pinout?
Restbeschaltung an Pins für die sich der Bootloader interessiert?
Idealerweise Schaltplan.

Was macht das ST-eigene Tool?

[Joe F. (easylife)]

Ich kann zu der Hardware keine Details rausgeben (kommerzielles Produkt, 
NDA, etc.), der STM ist auch nicht "meine" Baustelle. Mein Job ist dafür 
zu sorgen, dass dem Teil von einem anderen System auf dem PCB eine neue 
Firmware übergebraten werden kann.
Meine Vermutung war, dass mit meinem gesendeten Byte etwas nicht stimmt, 
was jemandem der sowas schon mal gemacht hat sofort auffallen würde 
(z.B. falsche Polarität).
Oder dass es irgendwelche undokumentierte Timing contraints gibt, z.B. 
dass das Byte nach min./max. x ms nach dem Reset geschickt werden 
muss...

Marcus H. schrieb:
> Restbeschaltung an Pins für die sich der Bootloader interessiert?

BOOT0/1 sind momentan hart auf VCC und GND gepatched.
Welche Pins ausser den beiden Boot-Pins und Reset kämen da denn noch in 
Frage?

[Marcus H. (Firma: www.harerod.de) (lungfish)]

Joe F. schrieb:
> Marcus H. schrieb:
>> Restbeschaltung an Pins für die sich der Bootloader interessiert?
>
> BOOT0/1 sind momentan hart auf VCC und GND gepatched.
> Welche Pins ausser den beiden Boot-Pins und Reset kämen da denn noch in
> Frage?

Alle Pins, die der Bootloader Deines STM32L1xxx Vyyy laut AN2606 mit 
Beschlag belegt.

Für Dinge, die Du hier nicht offenlegen darfst, freue ich mich über eine 
direkte Kontaktaufnahme.

[Marc V. (Firma: Vescomp) (logarithmus)]

Joe F. schrieb:
> Baudrate ist 57600 baud, 8E1, LSB first, Polarität wie im Anhang.

 Flashloader macht das aber mit 115200B.

 Anbei 2 Bilder.

 P.S.
 Und die Zeit zwischen Antwort und 2-tem Req.

[Joe F. (easylife)]

Marc V. schrieb:
> Flashloader macht das aber mit 115200B

Ja, bis zu... Ich habe beides ausprobiert, 115200 und eben die Hälfte, 
um das Ding nicht unbedingt am Limit zu testen.
Danke für die Messungen, sieht im Prinzip genauso aus wie bei mir (nur 
eben mit Antwort...) und ich kann jetzt sicher sein, dass es nicht am 
von mir übertragenen Byte liegt.
USART1_TX und _RX sind auf meinem Board einfach offen gelassen worden, 
evtl. müssen da pullups hin, damit der Bootloader nicht denkt, er soll 
auf USART1 kommunizieren... Ich werde weitersuchen und berichten was das 
Problem war.

[Horst (Gast)]

JTAG dranpfrimeln und gucken ob er überhaupt in den System Code springt 
und nicht Main Flash.

[Joe F. (easylife)]

Horst schrieb:
> JTAG dranpfrimeln und gucken ob er überhaupt in den System Code springt
> und nicht Main Flash.

Macht er. Wenn BOOT0 low ist, steht der program counter bei 0 (flash ist 
komplett leer).
Wenn BOOT1 high ist ist PC > 0x1ff00000

[Horst (Gast)]

Joe F. schrieb:
> Macht er. Wenn BOOT0 low ist, steht der program counter bei 0 (flash ist
> komplett leer).
> Wenn BOOT1 high ist ist PC > 0x1ff00000

Hm, checken ob da was sinnvolles drinsteht? Vector table sollte ja recht 
leicht verifizierbar sein.
Ansonsten kann ja eig garnichts mehr außer HW schief gehen...

[Horst (Gast)]

Und sollte der PC nicht auf 0x08000000 stehen statt 0 wenn System Flash 
aktiviert ist? Könnte auch anders sein wenn ganz leer, aber ich meine 
mich zu erinneren noch nie die 0 gesehen zu haben

[Joe F. (easylife)]

Mit meinem z.Zt. noch sehr rudimentären Verständnis für den STM liegt am 
Anfang des Flashs (0x08000000) eine Jumptable und er springt dann an die 
Adresse die dort steht (oder +4?.. erstmal egal...). Wenn eine FW im 
Flash ist, ist das eine Adresse innerhalb der FW (im Flash), wenn da 0 
steht (leeres Flash), springt er eben nach 0.

[Pete K. (pete77)]

Laut AN2606 sind pullups an RX und TX empfohlen. GND auch verbunden?

Mal schreibst Du USART1, mal USART2. Was denn nun? Hast Du auch die 
richtigen Pins erwischt?

[Joe F. (easylife)]

Pete K. schrieb:
> Laut AN2606 sind pullups an RX und TX empfohlen.
Ja, die fehlen. Bin gerade dabei ein Breakoutboard ranzupfriemeln, und 
das hat dann Pullups. Meine momentane Vermutung ist, dass das Ding sich 
auf den nicht angeschlossenen USART einschießt.

> GND auch verbunden?
Na logo.

> Mal schreibst Du USART1, mal USART2. Was denn nun?
USART1 ist einfach offen (wird wie gesagt als nächstes per Breakoutboard 
geändert), über USART2 möchte ich kommunizieren.
Werde es testweise auch anders herum versuchen.

> Hast Du auch die richtigen Pins erwischt?
100 pro.

Ich danke erstmal für alle Hinweise und Tips, habe einige Anregungen 
denen ich nachgehen werde, und melde mich wieder (bei Erfolg oder 
Misserfolg). So weit bis zum Ziel kann es jetzt eigentlich nicht mehr 
sein... ;-)

[Marc V. (Firma: Vescomp) (logarithmus)]

Joe F. schrieb:
> Misserfolg). So weit bis zum Ziel kann es jetzt eigentlich nicht mehr
> sein... ;-)

 Habe ich auch gedacht, dann kamen aber die Probleme auf und ich habe
 es aufgegeben, vor allem weil die Anwendung (Update beim Kunden) anders
 gelöst wurde.

 Und mit dem Befehl 0x01 (Get Version & Read Protection Status), bzw.
 mit der Antwort kam ich nie klar...

 P.S.

Joe F. schrieb:
> USART1 ist einfach offen (wird wie gesagt als nächstes per Breakoutboard
> geändert), über USART2 möchte ich kommunizieren.
> Werde es testweise auch anders herum versuchen.

It is recommended to keep the RX pins of unused Bootloader interfaces (USART_RX, SPI_MOSI, CAN_RX and USB D+/D- lines if present) at a known (low or high) level at the startup of the Bootloader (detection phase).
Leaving these pins floating during the detection phase might lead to activating unused interface.

[Joe F. (easylife)]

Ich war an den falschen Pins. AN2606 gefühlt 1000x angeguckt, und die 
Pinbelegung, die der Bootloader benutzt trotzdem die ganze Zeit 
übersehen.
Danke an alle, insbesondere die Hinweise, dass die unbenutzten 
Interfaces (incl. USB) auf definierte Pegel gezogen werden sollten 
werden in die nächste Hardware Runde einfließen. Die Pins einfach offen 
lassen kann funktionieren, muss aber nicht, also ein sehr unschöner 
Zustand...

[W.S. (Gast)]

Horst schrieb:
> Und sollte der PC nicht auf 0x08000000 stehen statt 0 wenn System Flash
> aktiviert ist?

Wieso?

Der Flash steht nicht nur bei 0800-0000, sondern ist auch ab 0 sichtbar 
und abarbeitbar. Die gesamte Firmware kann auch ab 0 laufen.

W.S.