Hallo, ich möchte gerne den internen Bootloader des Stm32f4 nutzen. Dazu springe ich aus meinem Hauptprogramm in den Bootloader. Dann sende ich 0x7F an den USART und bekomme das auch mit 0x79 bestätigt. Jetzt fangen die Abweichungen vom Handbuch an. Wenn ich einen Befehl, bestehend aus 2 Byte sende, dann bekomme ich keine Antwort. Bei den ersten 3 Befehlen (Get, Get Version und Get ID) bekomme ich eine positive Antwort und Daten gesendet, wenn ich zuvor noch eine weiteres Byte, egal welchen Inhalts, sende. Bei allen anderen Befehlen bekomme ich immer ein NACK. Die Daten schicken ich über ein Script in Python über die COM-Schnittstelle am PC an den Controller. (Einstellungen der Schnittstelle: baudrate=9600, bytesize=8, parity="E", stopbits=1, timeout=0.5) Hat jemand eine Idee, was da schief läuft? Danke
Read Protection aktiviert? Nähere Infos hierzu in AN3155, Tabelle 2 auf Seite 7, in Anmerkung 2 unter der Tabelle. Ich hab zwar noch nicht damit gearbeitet, aber sollte es daran liegen musst du nach meiner Lesart das Kommando "Readout Unprotect" senden, bevor weitere Kommandos verfügbar werden.
Wahrscheinlich ist es aktiviert. Leider bekomme ich ein NACK zurück, wenn ich [0x79 0x92 0x6d] sende. Wenn ich nur [0x92 0x6d] sende, bekomme ich keine Antwort.
Versuch mal mit dem "Get Version & Read Protection Status" Kommando sicher herauszufinden, ob Read Protection aktiv ist. Dann wissen wir, ob die grobe Richtung überhaupt stimmt :) Dass gar keine ACK bzw. NACK kommt finde ich aber eigenartig. Laut AppNote sollte das eher nicht passieren. Ist dein USART stabil (kleiner baud rate error, keine langen Drähte, ...)?
Die Antwort auf den Get Befehl: [ 0x79 0xb 0x31 0x0 0x1 0x2 0x11 0x21 0x31 0x44 0x63 0x73 0x82 0x92 0x79 ] Der Befehl ist also aktiv. Den USART würde ich für stabil halten. Ich habe auch schon eine andere Kommunikation im Hauptprogramm mit dem selben Aufbau bei einer höheren Baudrate durchgeführt und da gab es keine Probleme.
Ok, und dann einmal "Get Version & Read Protection Status" (0x01) als Kommando, weil du da die Zähler für Read Protect/Unprotect erfährst. Ansonsten könnten 0,5s timeout für den Read Unprotect Befehl zu kurz sein; immerhin löscht er den gesamten Flash und macht abschließend ein System Reset. ACKs bzw. NACKs solltest du natürlich bekommen. "For most STM32 products, the readout unprotect operation induce a mass erase of the flash memory, so the Host has to wait sufficient time after the second ACK and before restarting connection. To know how much time this operation takes, please refer to the mass erase time in the product datasheet (when relevant)." "Mass erase command on STM32F40xxx/41xxx takes longer than on other STM32 devices due to their memory density. Make sure that the timeout used by your host interface to wait for an acknowledge event after sending a Mass erase command is sufficient."
Get Version Antwort: [ 0x79 0x31 0x0 0x0 0x79 ] Richtig, das Löschen des gesamten Speichers könnte lange dauern (max. 32 s). Nach der AN3155 wird das erste ACK direkt nach dem Empfangen des Befehls gesendet wird. Ich bekomme jedoch zügig nach dem senden des Readout Unprotect [ 0x0 0x92 0x6d ] ein NACK und auch nach warten über einer halben Minute erhalte ich keine weitere Botschaft. Weshalb ich davon ausgehe, dass der Befehl nicht erkannt wird. Auf [ 0x92 0x6d ] bekomme ich keine Antwort, auch nicht nach langem warten.
Im Moment fällt mir auch nichts weiter ein. Du könntest noch das Script hochladen, vielleicht hat sich da ein Fehler eingeschlichen. Aber ansonten weiß ich leider auch nicht weiter.
Mir ist erstmal nichts aufgefallen, aber ich bin auch nicht wirklich firm in den Feinheiten von Python. Du könntest mal https://github.com/jsnyder/stm32loader probieren; basiert auch auf Python und ermöglicht dir das Problem in deinem Skript auszuschließen. Ansonsten solltest du es ggf. auch mal via Terminal versuchen. Vielleicht hat ja auch die von dir genutzte PySerial Implementierung eine Macke.
Ich tippe darauf, dass der Parity Bit falsch gesetzt ist. Nimm doch die definierte Konstante serial.PARITY_EVEN
Das Script stm32loader.py hatte ich auch schon gefunden. Leider funktioniert die bei mir nicht so richtig. Etwas ausgeben funktioniert. Die Baudrate habe ich auf 19200 gesenkt. Das Einlesen funktioniert aber irgendwie nicht so richtig. Wenn ich mit aber auf dem Oszi die Kommunikation ansehe, dann kann ich sehen, dass die Initialisierung klappt. Das nächste Kommando Get funktioniert, wenn ich in cmdGeneric() einfach zweimal das Kommando sende und damit auch 3 Byte. Also das gleiche Problem, welches ich auch schon bei meinem Script habe. Das Paritätsbit auf serial.PARITY_EVEN statt "E" setzen hilft leider nicht. In serialutil.py Zeile 87 wird das sowieso wieder durch 'E' ersetzt:
1 | PARITY_NONE, PARITY_EVEN, PARITY_ODD, PARITY_MARK, PARITY_SPACE = 'N', 'E', 'O', 'M', 'S' |
Liegt es evtl. an deinem COM Port? Funktioniert der Flash loader demonstartor von STM?
Der Flash Loader Demonstartor funktioniert leider nicht. Die Fehlermeldung lautet: "Unrecognized device" Das zurücksetzen hilf jedoch nicht. Wenn ich mir die Botschaften mit dem Oszi ansehe, dann wird 0x7F gesendet und der Controller antwortet auch mit 0x79. Genau wie in meinem Python Script, nur dass die Flanken weniger steil sind bei den STM FLD Botschaften. Einstellungen STM FLD: Baud Rate: 19200, Data Bits: 8, Parity: Even, Echo: Disabled, Timeout(s) 10 Ich habe es auch zusätzlich anstatt des COM Ports es über ein USB to COM Adapter angeschlossen, aber da ist keine Veränderung aufgetreten.
ich hatte das gleiche Problem mit dem bootloader beim LPC1768. Stundenlange Suche, hat nie funktioniert. Kauf Dir für 10€ einen jtag-link-programmer, das klappt dann auf Anhieb und du hast einen Debugger. Der Murks mit dem bootloader ist den Aufwand nicht wert.
Wie ist dein STMf4 beschaltet? Mit dem STM32f4-discovery kit hatte ich bis jetzt keine Probleme mit dem bootloader. Verwende auch einen FT232RL basieren TTL Wandler.
Ich benutze ein STM32VLDISCOVERY mit einem STM32f415. Die für den Boot Mode nicht verwendeten Kommunikations-Pins (PA10, PC11, PB05, PA 11 und PA 12) habe ich alle mit GND verbunden. Betrieben wird es über ein Netzteil an 5 V und GND, damit nicht über USB noch Störungen vom PC kommen können. Boot0 Pin habe ich mit dem 3 V Pin verbunden und PB2 (Boot1) mit GND verbunden. Bei RX und TX wird es etwas komplizierter. TX und RX sind an einem LIN Transeiver (TPIC1021) angeschlossen. Damit der TPIC1021 funktioniert ist der Enable Pin auf 3 V gelegt. Die LIN Seite wird dann mit einem LIN zu COM Adapter (RS232-LIN V3, http://www.freitag-elektronik.de/pdf_en/RS232-LIN%20%20User%20Documentation.pdf) an den PC angeschlossen.
Aber du hast gesagt es funktioniert auch nicht direkt am PC... Hast du es auch vom PC direkt über USART1 probiert?
Daniel W. schrieb: > Wie ist dein STMf4 beschaltet? Mit dem STM32f4-discovery kit hatte ich > bis jetzt keine Probleme mit dem bootloader. Verwende auch einen FT232RL > basieren TTL Wandler. Und warum brueckst Du nicht Boot0 nach VDD, und PB2 (Boot1) nach GND, steckts einen Micro USB Stecker in das Boardund verwendest DFU?
Der Wechsel zum USART 1 ändert nichts. Über USB kann ich im Moment natürlich auch ein Programm laden, z.B. ST Link Utility, aber ich möchte den Chip später ohne Discovery Board benutzen.
Gemeint war der DFU Modus des STM32-seitigen USB Ports. Wenn der Bootloader in den System Memory boot Space startet, sucht er automatisch nach einem passenden Interface. In deinem Fall ist es momentan USART3, kann aber auch der USB-OTG port sein. Da du mit Python arbeitest, kannst du dir das mal anschauen: https://github.com/vpelletier/python-dfu
Von der zukünftigen Schaltung ist mir vorgegeben, dass ich den USART3 nutzen muss. Ich habe jetzt mal noch einen anderen Test gemacht und zwar lese ich mit einem weiteren LIN zu COM Wandler (+ COM zu USB Wandler, da ich nur einen COM Anschluss habe) die Signale auf dem LIN ein. Man sieht, dass beim Zweiten gesendeten Byte Unterschiede zwischen gesendeten und auf LIN zu lesenden Signalen zu sehen ist. Wenn ich die Transitive Leitung nicht verbinde, dann gibt es keine Unterschiede, aber auch keine Antworten ;-). Ich vermute, dass der Controller anfängt zu senden nach dem ersten Byte. Hier die das Ergebnis: Gesendet von PC [Gelesen auf LIN] 0x0 0x0 0xff [ 0x0 0x0 0xff 0x79 0xb 0x31 0x0 0x1 0x2 0x11 0x21 0x31 0x44 0x63 0x73 0x82 0x92 0x79 ] 0x0 0x1 0xfe [ 0x0 0x0 0xfe 0x79 0x31 0x0 0x0 0x79 ] 0x0 0x2 0xfd [ 0x0 0x2 0xfd 0x79 0x1 0x4 0x13 0x79 ] 0x0 0x11 0xee [ 0x0 0x10 0xee 0x79 ] 0x0 0x21 0xde [ 0x0 0x21 0xde ] 0x0 0x31 0xce [ 0x0 0x30 0x4c ] 0x0 0x44 0xbb [ 0x0 0x4 0xbb 0x1f ] 0x0 0x63 0x9c [ 0x0 0x3 0x9c 0x1f ] 0x0 0x73 0x8c [ 0x0 0x13 0x8c 0x1f ] 0x0 0x82 0x7d [ 0x0 0x2 0x7d 0x1f ] 0x0 0x92 0x6d [ 0x0 0x12 0x6d 0x1f ] 0x0 0xff [ 0x0 0x1f ] 0x1 0xfe [ 0x1 0x3e ] 0x2 0xfd [ 0x2 0x3c ] 0x11 0xee [ 0x11 0xe ] 0x21 0xde [ 0x21 0x1e ] 0x31 0xce [ 0x31 0xe ] 0x44 0xbb [ 0x44 0x1b ] 0x63 0x9c [ 0x63 0x1c ] 0x73 0x8c [ 0x73 0xc ] 0x82 0x7d [ 0x82 0x3c ] 0x92 0x6d [ 0x92 0x2c ]
Der Lin Transceiver könnte das Problem sein. Der Sendet nämlich jedes Byte auch direkt zum Sender wieder zurück, soweit ich das sehe.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.