Hallo. Ich habe ein STM32 [=A] an einem STM32 [=B] (über Usart3) an einem Computer (über Usart1). Das Boot und Resetpin vom A habe ich an B angeschlossen und kann damit A in den Bootmodus versetzen (Reset = 1 -> Boot = 1 -> Reset = 0, richtig?). Die normale Kommunikation (Boot von A = 0) funktioniert. Für die Flashprozedur wollte ich mich an das vorgehen von http://code.google.com/p/stm32flash/ halten. Wenn ich das richtig deute, bekomme ich nach jedem Kommando was ich sende erst einmal ein ACK (0x79) von A. Nach dem senden vom Init-Kommando (0x7F) bekomme ich dies auch. Danach wollte ich wie bei obigem Projekt die ID usw. des STM32 A auslesen und sende dafür Kommando (0x00) gefolgt von (0xFF) und wieder erhalte ich ein ACK, jedoch keine weiteren Bytes (ID usw.). Hat jemand von euch schon einmal händisch eine Flash-Prozedur geschrieben für die STM32 und kann mir sagen ob es irgendwelche tücken gibt? Kann es sein, dass es problematisch ist Kommandos wie 0x00 über die Usart zu senden bzw. solche zu empfangen?
Gast
#2943993
Michael B. schrieb: > Kann es sein, dass es problematisch ist Kommandos wie 0x00 über > die Usart zu senden bzw. solche zu empfangen? Problematisch ist das nicht - es gibt ja Start- und Stopp-Bits, somit ist auch ein 0x00 deutlich zu erkennen.
Danke schon mal für die erste Antwort! Dann werde ich wohl kaum drum rum kommen mal n oszi dran zu hängen (wollte ich vermeiden, weil es kein Eval-Board is wo man bequem an alle pins kommt...) und zu gucken warum / ob wirklich nach dem Senden von 0x00 nichts passiert.
Falls jemand mal das Selbe vor hat: es empfiehlt sich nicht im STM32-A die Read-Protection aktiviert zu haben, da man sonst nicht auslesen kann, um welche Art STM32 es sich handelt. Leider hat die Änderung der Read-Protection mich bisher noch nicht weiter gebracht, es bleibt dabei das STM-A nach 0x00 und 0xFF nur ein ACK (0x7F) sendet und sonst nichts weiter.
Gast
#2944178
Michael B. schrieb: > Leider hat die Änderung der Read-Protection mich bisher noch nicht > weiter gebracht, es bleibt dabei das STM-A nach 0x00 und 0xFF nur ein > ACK (0x7F) sendet und sonst nichts weiter. Das ist schade. Schon mal das entsprechende AppNote von ST zur Rate gezogen?
Die Appnote die dazu gehört ist folgende: http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/APPLICATION_NOTE/CD00264342.pdf Ich arbeite sie zZ. noch einmal durch um sicher zu gehen, dass ich nichts übersehen habe, jedoch ist mir bisher kein Fehler auf meiner Seite aufgefallen (auf Seite 7/37 der Appnote sieht man auch die Befehle und den Grund warum ich auf 0x00 mehr erwarte als ein ACK). Danke für den Hinweis auf die Appnote. Falls ich Fortschritte mache werde ich diese hier auch Posten, vielleicht hat ja jemand mal Interesse, das Opensource Crossplattform Projekt http://code.google.com/p/stm32flash/ um die Plattform STM32 zu ergänzen (ich werde leider fürs erste nicht dazu kommen).
Aus magischen Gründen funktioniert es nur, wenn ich kein Interrupt bei der Usart-Kommunikation verwende (STM-B), sondern Polling zum empfangen von Bytes die STM-A gesendet hat. Falls ich jemals verstehe warum, sage ich noch mal Bescheid, aber das könnte ein ungelöstes Mysterium bleiben.. [Interrupt-Routine zu lang kann ich ausschließen]
Hinweis/Edit: Read-Protection muss nicht deaktiviert sein wie ich oben geschrieben habe, man sollte sich jedoch im klaren sein, das man durch das Deaktivieren selbiger um das Flashen vorzubereiten (um Geräte-ID auslesen zu können usw.) bereits sämtliche Daten gelöscht werden, es gibt dann also kein Weg mehr zurück. Bei deaktivierter Readout-Protection könnte man z.B. das vorige Flashprogramm auslesen und kann es zur Not zurück schreiben falls beim neuen Programm etwas nicht in Ordnung ist.
Michael B. schrieb: > Aus magischen Gründen funktioniert es nur, wenn ich kein Interrupt bei > der Usart-Kommunikation verwende (STM-B), sondern Polling zum empfangen > von Bytes die STM-A gesendet hat. > > Falls ich jemals verstehe warum, sage ich noch mal Bescheid, aber das > könnte ein ungelöstes Mysterium bleiben.. [Interrupt-Routine zu lang > kann ich ausschließen] Das wäre allerdings sehr merkwürdig - offenbar macht B die Existenz von A im jungfräulichen Zustand nervös ;-) Ernsthaft: Welche Baudrate wird verwendet? Nach dem 0x7F wird ja A erstmal die Baudrate einstellen. Dauert das vielleicht länger und B sendet deswegen zu früh? Da wir uns hier erst langsam in die STM32-Materie einarbeiten und bisher nur über den ST-Link des STM32F4DISCOVERY gegangen sind, noch eine Frage: Habe ich das richtig verstanden? Die Bootloader, die ST bei der Herstellung einbrennt, liegen nicht im normalen Flash, können also keinesfalls überschrieben werden und stehen somit immer zur Verfügung? In der App-Note "The bootloader is stored in the internal boot ROM memory (system memory) of STM32 devices. It is programmed by ST during production." hört es sich zumindest so an. Chris D.
Also es ist so vorgesehen, dass man den ST-Bootloader nicht überschreiben kann. Ob man das nicht doch irgendwie bewerkstelligen kann (z.B. indem man am Ende vom Flash anfängt zu schreiben und ausnutzt, dass 'Letzte Adresse + 1 = 0' oderso) weiß ich an dieser Stelle jedoch nicht und das ist mir auch noch nicht ganz klar geworden aus den zugehörigen App-Notes, da gibt es hier im Forum aber bestimmt Leute die das genau wissen. Baudraten habe ich verschiedene probiert (115200, 57600, 19200), scheint auch egal zu sein welche ich nutze. Wartezeiten habe ich testweise eingefügt nach dem Init (bis 2 Sekunden) - hat aber nichts geändert. Vielleicht liegt es aber aus ner Kombination meiner Interrupt-Routine und den Timings, sollte eher jemand beurteilen, der das nicht in einer großen Firmware einarbeitet sondern eine Minimallösung erstellt - vielleicht komme ich ja doch noch dazu das ein mal zu evaluieren [aktuell wegen Zeitvorgaben schwierig].
Kleiner Tipp noch von meiner Seite: wenn man kein Hardware-Handshake einrichten kann für Kommunikation PC -> STM-B sollte man unbedingt XON/XOFF nutzen um den PC daran zu hindern Daten zu senden, während man sie an STM-A sendet zum speichern (vermute das ist allen klar, wollte es nur noch einmal erwähnen).
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.