Hallo, ich habe ein Projekt mit einem STM32F407 gemacht. Um den einfach im Feld zu Programmieren habe ich einen MAX232 drauf. Einen Jumper für den Bootmodus gibt es auch. Die Schnittstelle geht, wird im normalen Programm genutzt. Ich habe im Netz einige Programme gefunden mit denen man angeblich den Bootloader bedienen kann. Aber wie man an an diesem Post erkennen kann geht keins richtig. Mal wird der STM32 zwar erkannt, aber beim Brennen wird abgebrochen. Mal wird der STM32 nicht mal erkannt. Es ist ein Trauerspiel. Gibt es ein TOOL (Windows/ DOS) was zuverlässig abreitet? VG, Uli
Uli schrieb: > Gibt es ein TOOL (Windows/ DOS) was zuverlässig abreitet? ..so wie die glorreichen 7 ? Also, meine Erfahrung ist, daß der Bootlader beim Löschen des Flash ein paarmal den Chip in den Reset steuert (wegen Disable Read Protect, Disable Write Protect und so) und daß dies erstens immer wieder ein neues Synchronisieren erfordert ($7F und dann auf $79 warten) UND daß das nicht wirklich immer ordntlich funktioniert, so daß man besser dran täte, den Chip per nRST selber zurückzusetzen. Ich hab mir grad sowas mal selber geschrieben, weil ich mit dem Zeugs, was ST da anbietet unzufrieden bin. Ich häng es mal hier dran, obwohl es noch in einem recht lausigen Zustand ist. Geschrieben mit Delphi 6 und weil die Exe bei Win7 und vergrößerten Fonts lausig aussieht, nochmal kurz durch Delphi 10 geleiert. Ist unverschämt viel dicker bei identischem Nutzinhalt. Also probier's aus wenn du willst. W.S.
Deine Erklärung zum Bootloader ist recht interessant und würde vieles erklären. Das Programm sieht wirklich schön aus und ich denke das es auch geht. Aber leider ist meine Hardware nicht dafür geeignet. Ich komme einfach nicht mehr an die Steuerleitungen ran. VG, Uli
Uli schrieb: > Ich komme einfach nicht mehr an die Steuerleitungen ran. Tja, beim Fußball würde man dazu "Arschkarte" sagen. Aber da du ja selber dein Projekt gemacht hast, mußt du dir wohl selber die Schuld geben dafür, daß du dir ganz am Anfang nicht genug Gedanken gemacht hast. Also Redesign... oder andere Zielsetzung. Apropos Programm: Ich hab es jetzt ein bissl erweitert und benutze es recht intensiv. Ein Automatik-Knopf ist jetzt dabei und ein Terminalfenster, so daß man mit der ja ohnehin vorhandenen seriellen Verindung gegebenenfalls mit seiner frisch einprogrammierten Firmware kommunizieren kann, ohne irgend was umstecken zu müssen. Mal sehen, vielleicht stelle ich es bei Projects&Code ein. W.S.
Das der Bootloader so schlecht ist konnte ich ja nicht ahnen. Das ist auch das einzige was ich nicht vor dem Layouten getestet hatte. Bin einfach davon ausgegangen das der schon sauber arbeiten wird. Aber welches alternative Programm hätte ich denn vor ca. 2 Jahren gehabt? Die Leitungen sind normal am STM32 dran, benutze sie aber zur Zeit nicht. Aber wie gesagt ich komme an die Leitungen nur schwer ran (4 Lagig und liegen innen). Kann man in deinem Programm nicht den original Modus einbauen, also ohne die Steuerleitungen? Wenn ich dann 2 Versuche brauche ist das immer noch besser wie jetzt. Da der Bootloader nicht geht spiele ich zur Zeit das Programm mit dem Debugger rein. Ist zwar nicht so schön aber solange es nicht anders geht muss ich halt jedes mal das Gehäuse auf schrauben. VG, Uli
Uli schrieb: > Das der Bootloader so schlecht ist konnte ich ja nicht ahnen. Der Bootlader ist nicht wirklich schlecht, sowas kann man wirklich nicht sagen. Aber er muß ja beim Löschen der Options offenbar einen Reset erzwingen (oder man macht das von außen), damit die Hardware, die das Auslesen oder Beschreiben verhindern soll, entsprechend den (dann gelöschten) Option-Bits zurückgesetzt wird. Das ist Schutz-Hardware und die kann auch von einem residenten Bootlader nicht umgangen werden. Aber so ganz kann ich deine Ausführungen nicht verstehen: Es sind ja neben den seriellen Signalen RxD und TxD nur noch Reset und BOOT, die du brauchst. Die können doch nicht überall auf innenliegenden Layern liegen, irgendwann müssen die ja mal an einen Hochzieh-R oder Runterzieh-R geführt sein - und der liegt immer außen. Siehe deine eigenen Worte: Uli schrieb: > Einen Jumper für den Bootmodus gibt es auch. Siehste. Dann fehlt dir nur noch der Reset - und der ist mit Sicherheit an irgend einem Widerstand abgreifbar. Apropos: ich hab mein Programm grad in den letzten Tagen recht intensiv genutzt und mir dabei auch noch ein kleines Terminal eingebaut. Macht sich. Ich werd's wohl bei den Projekten mal einstellen. W.S.
Gut vielleicht ist auch nur alles an getesteter Software dafür nicht so gut. Ich kenne halt andere Bootloader (Prozessoren) und die arbeiten perfekt. Klar kommt man irgendwie an die RESET Leitungen und wenn man direkt an den Pin ran gehen würde. Wenn der Pin nicht benutzt würden wäre es schon mal einfacher. Das grösste Problem ist mehr das ich ja zum Kunden komme und da nicht unbedingt den Lötkolben raus holen will. Das öffnen vom Deckel geht gerade noch! Was übrigens komplett gegen Deine Methode spricht ist das ich keinen Einfluss habe was der Kunde an Rechner dran hängt. Und damit habe ich auch keinen Einfluss auf die Steuerleitungen. Wäre echt blöd wenn der PC das System einfach in den Reset jagen kann. Bei einer neu Entwicklung kann man ja das alles berücksichtigen und absichern. Ich habe auch nur eine der Steuerleitung auf dem MAX die andere müsste ich mir übrigens erst dran basteln, was beim Kunde nicht so gut kommt. An einen eigenen Bootloader hatte ich auch schon mal gedacht, aber mangels dringlichkeit noch nicht nach einem gesucht VG, Uli
Hi Uli, der eingebaute STM32-Bootloader läuft auf dem ganzen Planeten zuverlässig. Bei meinen Kunden ist meist DFU oder UART angesagt. Die verschiedenen Errata sind auch dokumentiert. Als Einstieg ist die AN2606 Dein Freund. Allerdings habe ich im Kundenauftrag schon verschiedene Varianten STM32-Bootloader geschrieben. Die letzte hatte als Besonderheit Busfähigkeit (Zweidraht RS485) und Verschlüsselung. Eine weitere Motivation ist häufig ein zuverlässiger Fallback im Fehlerfall, wofür mehrere CRC-überwachte Images vorgehalten werden. Grüße, Marcus
Marcus H. schrieb: > Allerdings habe ich im Kundenauftrag schon verschiedene Varianten > STM32-Bootloader geschrieben. Hast Du den Bootloader in C programmiert?
Uli schrieb: > Was übrigens komplett gegen Deine Methode spricht... bringen wir's mal auf den Punkt: Wenn du eine geordnete Updatemöglichkeit beim Kunden und durch den Kunden haben willst, dann mußt du das von Anfang an eben vorsehen. Jede JTAG/SWD-Updaterei schließt sich da von selbst aus, weil zu kompliziert für Kunden. Ein Updaten per eingebautem Bootlader geht, denn dieser Bootlader idt erstens resident, kann also nicht flöten gehen - und er hat im Allgemeinen genug Intelligenz, um bei Formatfehlern usw. keinen groben Blödsinn zu machen. Aber: du mußt für sowas eben eine ordentliche Buchse vorsehen, die verpol- und versteck-sicher ausgelegt ist. Und du mußt dann auch ein narrensicheres PC-Programm nebst konfektionierter Schnittstelle vorhalten. Es geht eben nur so. W.S.
Beatrice M. schrieb: > Marcus H. schrieb: >> Allerdings habe ich im Kundenauftrag schon verschiedene Varianten >> STM32-Bootloader geschrieben. > > Hast Du den Bootloader in C programmiert? Die Frage ist insofern insofern ein Volltreffer, dass der BL-Urvater mal in AVR-Assembler geschrieben war. Da der Bootloader immer einen eigenen, geschützten, Flash-Sektor bekommt, war beim STM32 platzmäßig der Weg zu einer GCC-Implementation offen. Allerdings - falls Du eine andere Implementation (z.B. ARM-Assembler) haben möchtest - kein Problem. Nur als Arduino-Sketch würde ich das nicht machen wollen, alles hat seine Grenzen. ;)
Also wie gesagt habe ich einen Software Bootloader noch nicht gesucht. Das der dann in einem eigenen Bereich sitzen müsste und so weiter ist doch wohl selbstverständlich. Ich denke das man sich über eine Möglichkeit zum Updaten Gedanken machen sollte ist klar. Aber auf einer frei zugänglichen Schnittstelle, wo sogar ein PC vom Kunden immer dran sein kann weil darüber im normalen Betrieb Daten ausgetauscht werden, eine RESET Leitung dran zu hängen finde ich grob fahrlässig. Bei einer gesicherten Service Schnittstelle ist das wieder was ganz anderes. Aber das habe ich nicht. Ich würde hier doch auch nicht fragen wenn alle getesteten Programme nicht total versagt hätten. Was einem auch zeigt das der interne Debugger anscheinend halt doch nicht so gut ist bzw alle Programme diese internen Probleme nicht ausbügeln können. W.S. hat es doch selber klar gesagt der interne Bootloader braucht um stabil zulaufen einen externen Reset. Was ich ehrlich gesagt schade finde. Bei mir kommt man an die Debugleitungen zum Glück recht gut dran. Deckel aufschrauben und debugger einstecken. Der Anschluss wurde absichtlich gleich so gelegt das ich beim Testen nicht immer alles zerlegen musste. VG, Uli
Du kannst den internen Bootloader auch aus Deiner eigenen Firmware aufrufen. Das Triggern dieses Aufrufs kannst Du beliebig sicher gestalten. Durch geeignete Schutzmaßnahmen kannst Du diese Triggerroutine gegen den Bootloader schützen.
Uli schrieb: > um stabil zulaufen einen externen Reset Vielleicht solltest du das mal verstehen: Uli schrieb: > Aber auf einer frei zugänglichen Schnittstelle, wo sogar ein PC vom > Kunden immer dran sein kann weil darüber im normalen Betrieb Daten > ausgetauscht werden, eine RESET Leitung dran zu hängen finde ich grob > fahrlässig. Das ist es bei Weitem nicht, wenn man Vorkehrungen trifft. Entweder wird für's Update eine separate Buchse benutzt, die eben NICHT für den Normalbetrieb dient oder man führt die beiden Signale über Jumper, die zum Programmieren umgesteckt werden müssen... und zum Normalbetrieb eben wieder zurückgesteckt werden müssen. Das ist zwar nicht so bequem wie "lall" sagen, aber es geht - und zwar sicher. Reset und Boot ohne alles an die Normalbuchse würde wohl niemand machen. Aber für alles sowas muß man sich eben ganz früh beim Entwurf bereits Gedanken machen. W.S.
Das ich versäumt hatte den Bootloader zu testen hatte ich doch schon zugegeben. Das man vieles in einem neuen Design besser machen kann ist doch auch klar, aber das System muss jetzt erstmal die nächsten 10-20 Jahre laufen. Alle System die draussen sind laufen noch mit Version 1.0 und werden es so wie es aussieht auch bis zum Ende. Es gibt nur 34 System bei denen es sonder Wünsche gab und die wurden vor Ort eingespielt. Bei einem aktuellen Projekt an dem ich gerade sitzt gibt es eine Service USB Buchse, da muss ich die Tage mal testen ob darüber ein Update geht. Was bei diesem System aber nicht wichtig wäre da das Teil immer eingeschickt werden muss wenn was nicht geht. VG, Uli
Das jedes mal bei egal welcher PC Software der bootloader abgebrochen hat und ich nach einer Funkionierenden Version gefragt hatte. Wenn ich dann eine Bestätigung bekomme das der besser läuft mit einem externen Reset sagt das doch schon mal viel über die Qualität. Vg, Uli
Hallo Leute, für meine STM32F4, STM32Lx Projekte benutze ich einen selber geschriebenen. Mein Problem ist: im eingebauten Zusatnd komme ich nicht an den BootPin ran. Meine Bootloader Firmware ist logischerweise bei Offset 0. Die Applikation beginnt bei 64kByte. Ich muss in der Applikation StartAddresse und Interrupt-Vektoren veschieben. Der Bootloader checkt sowas wie eine Signatur und überprüft das Firmware Image auf CRC. HTH, Adib. --
Uli schrieb: > Wenn ich dann eine Bestätigung bekomme das der besser läuft mit einem > externen Reset sagt das doch schon mal viel über die Qualität. https://de.wikipedia.org/wiki/Qualit%C3%A4t Korrekt, es sagt viel über die Beschaffenheit Deines Gesamtsystems. Frage: was ist in >Deinem< System bei einem externen Reset anders, als bei einem internen Reset? Ein STM32 System ist ein Konglomerat von Modulen. Ein firmwareseitig ausgelöster ARM-Core Reset bedeutet nicht, dass die Peripherie in den Einschaltzustand versetzt wird. Der Bootloader kümmert sich nur um die Subsysteme, die er für seinen Betrieb braucht, ausgehend von einem PowerOn-Reset. Springst Du den Bootloader aus Deiner Firmware an, musst Du dafür sorgen, dass der Bootloader seine benötigte Umgebung vorfindet. Die hierfür notwendige Doku befindet sich in: AN2606, RM0090, PM0214, Errata, Datasheet. Der einzig wirklich lästige Bootloaderbug ist die Sache mit der VUSB-Erkennnung, wodurch der Bootloader ein paar Milliampere mehr zieht als notwendig wären. Zuletzt wäre auch noch das Verhalten Deiner hinzugebauten Peripherie zu bewerten.
Uli schrieb: > Wenn ich dann eine Bestätigung bekomme das der besser läuft mit einem > externen Reset sagt das doch schon mal viel über die Qualität. Wessen Qualität? Also, mein Eindruck ist, daß es hier nicht vorangeht - allen Tips und Hinweisen zum Trotz. W.S.
W.s. den Eindruck habe ich schon lange. Du selber hast bestätigt das der interne bootloader besser mit einen ext. Reset arbeitet. Also mit deiner und meiner Erfahrung zusammen kann man doch wohl sagen das der interne bootloader einem Probleme bereitet kann. Was man an der Hardware falsch machen kann? Nichts! Jumper an den bootpin rx tx nach draußen und eine Versorgung . Auf dem PC eines von den freien Tools starten und ab gehts. wenn dann alle Programme auf mehrern PCs an mehreren Modulen nicht laufen kann man halt annehmen das irgendwas faul ist. Uli
Uli schrieb: > Auf dem PC eines von den freien Tools starten und ab gehts. > wenn dann alle Programme auf mehrern PCs an mehreren Modulen nicht > laufen kann man halt annehmen das irgendwas faul ist. Du hast ne seltsame Sicht auf die Dinge. Bei all diesen "freien Tools" muß man bedenken, daß diese in aller Regel von Privatleuten für deren eigenen Bedarf geschrieben wurden und dort auch zur Zufriedenheit fuktioniert haben. Sei also froh, wenn so einer in der Annahme, daß sein Zeug vielleicht auch anderen nützlich sein könnte, selbiges zum Download anbietet. Das ist eine grundsätzlich andere Sache als Software, die von Firmen zum Kauf angeboten wird. Was da faul ist, kann ich dir sagen: Es ist die begrenzte Informationsmenge, die man als privater Bastler zur Verfügung hat. Deswegen sind Mißverständnisse angesagt oder Algorithmen, die wackelig sind, weil sie auf zu dürftigen oder gar im Detail falschen Informationen des Chipherstellers beruhen. Hab davon in den letzten Tagen auch so einiges erleben müssen. Ach ja, ein Update ist jetzt eingestellt. Vielleicht kommst du damit klar. Und nochwas: Jedes Stück HW oder SW bereitet einem Probleme, solange man es noch nicht im Griff hat. Binsenweisheit. Ich sehe aber keinerlei Anlaß, sich davon entmutigen zu lassen, also jammere nicht. Zumindest ist es aus meiner Sicht dramatisch einfacher, mit meinem Progrämmle zu Potte zu kommen als mit sowas wie OpenOCD oder dem Download aus uVision über nen Segger EDU. Letzteres ist ein Oberkrampf, sobald man seinen eigenen Startupcode verwenden will oder CMSIS nicht verwenden will. Dann müßte man nämlich die Aufrufparameter der eigentlichen Tools selbst festlegen - und genau DAGEGEN wehrt sich dieses uVision nach Kräften und verkorkst dabei auch den Download per eingebautem Debugger. Aber das nur nebenbei, es ist mir inzwischen ganz und gar unwichtig geworden. W.S.
uVision Kenne ich nicht!!!! Gut besser benutze ich nicht. EM::Blocks reicht damit kann ich alles machen was ich will. Sogar an der Arbeit wird für alle Systeme nur der GCC benutzt und das hat nichts mit Geld zu tun. Mit der ganzen Tool-Kette hatte ich eigentlich keine grösseren Probleme. SEGGER Vollversion, EDU und ST-Link2 arbeiten Perfekt. Bei mir arbeitet nicht mal das TOOL von STM sauber und das ist nicht von einem Hobbyprogrammierer für den eigen bedarf geschrieben. Dein Tool (neueste Version) muss ich noch testen. Hast Du vor davon auch eine Shell fähige Version zu machen? Dann könnte man das so schön in eine Batch Datei rein packen. Also Übergabe Parameter dem Programm mitgeben, so mache ich es immer wenn was quasi automatisch ablaufen soll. VG, Uli
Nun, wir leben ganz gewiß in zwei völlig verschiedenen Welten. Ich hab in der Firma den Keil angeschafft und habe mich mit dem GCC nur bei der Lernbetty herumgeschlagen. Das war grauenhaft und extrem umständlich aus meiner Sicht, es sind so viele kleine und große Mistigkeiten damit. Zu meinem Programm: man kann ihm eine Konfig-Datei oder eine Hexdatei als Kommandozeilenparameter geben. Ich denke mal, das reicht. Schließlich ist das Programmieren eine interaktive Angelegenheit. Ich habe vielmehr den Schwerpunkt auf die tatsächliche Nützlichkeit gelegt. Zum einen gibt es einige Testfunktionen, mit denen man sein Programmiergeschirre einrichten und testen kann - was ich für extrem wichtig halte. Zum anderen ist auch ein kleines Terminalfenster drin, was zumindest mir außerordentlich wichtig ist. Ich arbeite µC-intern eigentlich immer ereignisgsteuert und damit mit einem Event-System. Das hat sich seit gefühlten 100 Jahren so richtig gut bewährt. Obendrein hab ich auch immer einen genz kleinen Kommandointerpreter mit drin - jedenfalls wenn der Chip ohnehin eine Serielle hat. Das sind bei mir mittlerweile meine eigenen Standard-Moduln - und sie arbeiten im Gegensatz zu eine Debugger eben nichtintrusiv. Sowas wie dieses EM-Blocks oder so kenne ich nicht aus eigener Anschauung. Hatte ich mir mal runtergeladen, aber noch nie installiert aus Mangel an Interesse daran. Ich arbeite lieber mit einem ganz gewöhnlichen Editor, einer Batchdatei für's Projekt und einem separaten Brennprogamm - und in manchen Fällen mit dem Oszillografen. Da ist es außerordentlich hilfreich, im Brennprogramm gleich ein Terminalfenster zu haben. Einen Bedarf an einer Verwendung als Kommandozeilentool sehe ich hingegen nicht. Wozu sollte es auch gut sein, eine ohnehin schon gestartete und auf dem Bildschirm sichtbare Anwendung noch einmal zu starten? Andererseits wenn man mal zwei oder mehr Chips brennen will, wozu sollte man dafür die gesamte Übersetzungskette neu durchziehen? Die zutreffende Hexdatei ist ja ohnehin vorhanden, also wozu neu übersetzen? Ich halte diese Skript/Batch & Tool-Idee an dieser Stelle für unsinnig. W.S.
Das wir unterschiedlich an Probleme ran gegen und andere Tools bevorzugen ist doch normal. Ich arbeite nun seit vielen Jahren im Programmier Zirkus und kenne schon recht viele Tools, Compiler und IDEs. Am ende bleibt man halt bei dem was einem am besten gefällt. Interne Abläufe kann man so oder anders lösen, ist doch immer eine frage von der Anforderung. Wer in einen Programm Update script ein neu kompilieren drin hat würde bei uns wegen unfähigkeit gefeuert. Vg Uli
Uli schrieb: > Wer in einen Programm Update script ein neu kompilieren drin hat würde > bei uns wegen unfähigkeit gefeuert. O ha! Da frag ich mich, was ihr wohl mit jemandem macht, der die Hardware für's Update versemmelt hat... teeren+federn? oder so wie im alten Rom ab ins Kolosseum vor die Löwen? Aber mal im Ernst, ein Update-Skript? make update und das von Hand per Kommandozeile? Anstatt einfach das Brennprogramm mit nem simplen Mausklick zu starten? Aber laß mal, heut ist der Tag des Grillens und endlich das Märzen austrinken... W.S.
Letztendlich ist es immer so das man irgendwas startet, nur ich bevorzuge halt das Prinzip starten, Finger weg und warten aufs ende. Da geht seltener was schief. Die Schnittstelle geht ja, nur das Update nicht. Dein System teste ich endlich am Montag. Wenn es geht dann kann endlich auch ein Servicetechniker das machen wenn es mal nötig wäre. So jetzt ist alk abbauen angesagt. Vg Uli
Uli schrieb: > Die Schnittstelle geht ja, nur das Update nicht. Hör mal, du hast da was ganz Grundsätzlichen NICHT verstanden: Eine Schnittstelle ist nur das Medium, nur der Transportkanal. Aber was hier - wie immer bei solchen Aktionen - wichtig ist, ist das Zusammenspiel zweier voneinander unabhängiger Systeme. In diesem Falle PC und µC. Das bedarf eines Protokolles, was beide Seiten (jaja, BEIDE) einzuhalten haben, sonst geht es schief. Und zum Protokoll gehört eben auch, daß sich beide abstimmen - egal, ob der eine aus triftigen internen Gründen zwischendurch mal in den Sack hauen (sprich resetten) muß oder nicht. Normalerweise verkneife ich mir, mit automobilen Vergleichen zu kommen, aber hier versuche ich das mal: Wenn du ne Straße hast und Autos, die drauf fahren können, dann hast du noch lange keinen geordneten Verkehr und du kannst nicht sicher sein, unbeschädigt von Berlin nach Zürich zu kommen. Was du brauchst, ist eine Straßenverkehrsordnung, an die sich alle halten, sonst kracht es und du landest nicht in Zürich, sondern im Hospital: "Die Straße geht ja, aber nicht die Fahrt nach Zürich". W.S.
Ich habe das schon verstanden. Nur um bei deinen Beispiel zubleiben. Du Strasse habe ich gebaut und getestet, die regeln und alles andere haben andere gemacht. also was kann ich dafür das hier jemand falsch fährt. Für mich bedeutet das halt das was nicht ankommt und ich nicht weiter komme. Vg, Uli
Uli schrieb: > also was kann ich dafür das hier jemand falsch fährt. Nun, du hast keine Ampeln (Reset) und Wegweiser (Boot) aufgestellt - aber laß mal, Autovergleiche waren schon immer eher schräg... W.S.
Bitte 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.