Ich suche nach der für meinen fall idealen Bootloader Lösung, ich hab mir schon Zettel und Tabellen voller Ideen und Vergleiche gemacht aber hab immer noch nicht die ideale Lösung gefunden, da dacht ich mir ich frag mal euch, da ich mir nicht vorstellen kann das ich der erste bin der vor dieser Problemstellung steht. Es wird eine eigene PC Software geben welche auch die Funktion beinhaltet das USB-Gerät zu flashen. Ausser einer USB-micro Buchse verfügt das Gerät nur über Anschlüsse um den internen Akku zu laden. Es gibt also keine Schalter, Jumper oder ähnliches. Das Gerät soll jederzeit geflash werden können, also sowohl wenn die software auf dem Gerät läuft, als auch wenn sie sich aufgehängt hat oder die Software aus irgendwelchen Gründen defekt ist. Weitere Punkte sind, dass die USB-Schnittstelle des Device nicht nur zum flashen genutzt wird, sondern auch zum Datenaustausch. Auch darf das Device nicht bei jedem Anstecken an den USB Port geresetet werden. Eine Lösung die mir vorschwebt ist ein Monoflop das beim Anstecken an einen USB-Host (PC) gestartet wird und das Gerät, nach einer definierten Zeit, in den Flash-Zustand versetzt, sollte das Device dies nicht verhindern, durch eine Reset Leitung am Monoflog oder ähnliches. Meinungen zu dieser Idee? gibt es vielleicht sogar Monoflops die für einen solchen Anwendungsfall speziell ausgelegt sind? Andere Idee, den Bootloader aus der uC-Software heraus aufrufen und für den Fall das die uC nichtmehr reagiert, eine USB-mikro-ab Buchse verwenden und den ID Pin dazu verwenden einen Reset auszulösen und das Device in den Flash Zustand zu versetzen. Das diese Verwendung des ID Pins nicht USB 2.0 konform ist und das eine Verwendung eines Mikro-Buchse Typ AB zu der Annahme führen könnte das es sich um ein OTG Gerät handelt, beim Kunden, ist mir bewusst und der Hauptgrund warum mich diese Realisierung stört. Meinungen? Gegenvorschläge? Infos die ich vergessen habe mitzuteilen?
Chris S. schrieb: > Infos die ich vergessen habe mitzuteilen? Welcher µC? Evtl: Die "Haupt-Firmware" setzt auf Befehl hin ein Flag im EEPROM, damit beim nächsten Reset in den Bootloader gesprungen wird, und resetted. Der Bootloader löscht das Flag wieder. d.H. Für das Firmware-Update muss der PC den µC in den Update-Modus schalten, und warten bis sich das Device ab- und wieder anmeldet (andere PID, sonst kommen evtl Treiber durcheinander!)
da ist mir doch glatt selbst noch was aufgefallen das ich vergessen habe, zum einen das Guten Tag und die Freundlichen Grüße, zum Anderen die Info das es sich um einen, in den uC integrierten, USB-controller handelt und keinen externen FTDI beispielsweise. Daher gibt es keine GPIO welche per USB jederzeit angesprochen werden könnten. Grüße und ein schönes Wochenende, Chris
Εrnst B✶ schrieb: > Chris S. schrieb: >> Infos die ich vergessen habe mitzuteilen? > > Welcher µC? EFM32GG330F1024, Cortex-M3 Kern, von energy micro > > Evtl: Die "Haupt-Firmware" setzt auf Befehl hin ein Flag im EEPROM, > damit beim nächsten Reset in den Bootloader gesprungen wird, und > resetted. > Der Bootloader löscht das Flag wieder. das ist Grundidee in meinem zweiten Ansatz, allerdings mit angesprochenen Problemfall: was passiert wenn der uC sich aufhängt? Gibt es da was besseres als den USB-ID Pin zu "missbrauchen"? > (andere > PID, sonst kommen evtl Treiber durcheinander!) Danke, auf die Frage wollt ich mir grad eine antwort suchen gehn.
Ich hatte mal ein ähnliches Problem und hab es so gelöst: Am Ende des Flash ist eine Prüfsumme. Der Bootloader startet immer zuerst und vergleicht Prüfsumme mit Inhalt des Flash. Wenn die Prüfsumme stimmt wird sofort die normale Applikation gestartet. Wenn sie nicht stimmt wird auf neue Flash-Daten per USB gewartet. In der normalen Applikation gibt es einen Befehl den Flash-Vorgang explizit auszulösen. Außerdem läuft ein Watchdog-Timer. Wenn der auslöst, wird der Flash-Vorgang mit einem Timeout gestartet, auch wenn die Prüfsumme stimmt. Das ganze ist in größerer Stückzahl im Einsatz und die rausgegebenen Flashfiles werden vor der Freigabe sorgfältig geprüft. Das ganze ist primär gegen Fehler wie Abschalten während des Flashvorgangs oder Übertragungsfehler. Es gibt natürlich das Restrisiko daß ein freigegebenes Flashfile mit korrekter Prüfsumme Bugs enthält die dafür sorgen, daß man den Bootloader nicht mehr explizit aufrufen kann. Dafür braucht man halt ne gewisse Qualitätskontrolle. Hat in der Praxis bisher wunderbar funktioniert, gab nur einen Ausfall durch ne kalte Lötstelle. Dagegen hilft der beste Bootloader nix.
So, nen ResetTaster wirst du brauche. Meine meinung. Die FW kann sich in jedem belibigen systemzustand verabschieden. Da das gerät einne batterie hat. bleibt es in diesem zustand. es wieder in einen definierten zustand zurück zuführen währe dann den akku abziehen und neu stecken (blöd) oder solange wartet bis der akku selber abschaltet, oder der Reset taster. Oder jede andere art den reset auszulösen. Du solltest sicherstellen, das der FW Update so durchgeführt wird das er jederzeit ohne fehler unterbrochen werden kann und auch wiederholt werden kann, ohne das du rückläufer produzierst. Der akku kann lehr sein zum zeitpukt des FW Updates. die verbindung zum PC kann getrennt werden, ... Ich weiss jetzt nicht was der ROM code des Bausteins alles für funktionen zur verfügung stellt. Viele bieten ja einen FW Update über USB an. In wie weit man sowas verwenden kann. mit eigener Software versehen kann. hängt vom Hersteller ab. weiter sich nicht umbedingt darauf verlassen, das die ihre dlls weiter pflegen. In wie weit es möglich ist gefordert ist eine eigene USB VID PID zu verwenden / einzubinden. Wie man die Baustein in diesen Mode zwingen kann. ...
@ Gerd E. das klingt doch garnicht schlecht. Auf den dritten Schritt mit dem Watchdog bin ich nicht gekommen, zwar das ich mit dem watchdog den controller sowolh überwachen als auch reseten kann, aber garnicht dran gedacht das ich im bootloader ja checken kann aus welchem Grund er geresetet wurde. Nehm ich auf jedenfall in meiner Listen auf und checke ob es all meine eventualitäten abgedeckt, oder ob es das zumindest besser tut als alle anderen Realisierungsideen.
und für den Hardwarereset kannst du einen kleinen Reedkontakt einbauen. Da kannst du dann mit einem Magneten resetten. k.
Klaus De lisson schrieb: > und für den Hardwarereset kannst du einen kleinen Reedkontakt einbauen. > Da kannst du dann mit einem Magneten resetten. > > k. xD die idee hat was, für die entwicklungs garkeine schlechte idee, aber ich stell mir grad vor ich hab nen Kunden am Telefon der sein Gerät nicht flashen kann weil es sich aufgehängt hat und ich sag ihm "halt nen Magnet über den grauen Fleck auf dem Gehäuse". Lustig wird die Unterhaltung mit Sicherheit.
naja, dann für die Kundengeräte dann lieber einen Erschütterungssensor. Dann sagst du dem Kunden halt, er solle mal ordentlich drauf klopfen. k.
Klaus De lisson schrieb: > naja, dann für die Kundengeräte dann lieber einen Erschütterungssensor. > Dann sagst du dem Kunden halt, er solle mal ordentlich drauf klopfen. > > k. dann kann ich ihm auch gleich nen windowsrechner verkaufen
Klaus De lisson schrieb: > Dann sagst du dem Kunden halt, er solle mal ordentlich drauf klopfen. Obwohl die primäre Problemlösungsstrategie bei unerfahrenen Anwendern ja eigentlich erwähntes Klopfen oder Schütteln ist... Auch eher unvorteilhaft, wenn das Gerät dann dauernd in den Update-Modus wechselt. ;)
Chris S. schrieb: > Ich suche nach der für meinen fall idealen Bootloader Lösung Du hast ne mir unverständliche Herangehensweise drauf. Ich versuch mal, die Situation aus meiner Sicht zu beschreiben: 1. Du brauchst in jedem Falle ein Stück Code, das im Werk ein für alle mal in deine Box gebrannt wird und das nie geändert wird. Nenne wir das mal Kaltstarter. 2. Diese Stück Code muß die grundlegenden Funktionen des uC nach Kalt- oder Warmstart einrichten (Pins aufsetzen, Takt aufsetzen usw) 3. Du brauchst einen Bootlader, der vermutlich auf den im uC vorhandenen RAM gelinkt ist, aber als "Block" in dem Bereich des Kaltstarters gespeichert ist, damit er auch nie überschrieben werden kann. 4. Du brauchst drei Methoden, diesen Bootlader zu starten: a) wenn der Kaltstarter feststellt, daß der eigentliche Anwendungscode ungültig ist (Prüfsumme, Magic's an bestimmter Stelle usw) b) auf manuelle Weise, also wenn einer dediziert nen Knopf drückt oder so c) aus dem Anwendungscode heraus. Wie der dazu kommt (Kommando vom PC o.ä.) ist ne andere Sache. 5. Der Bootlader muß halt so eingerichtet sein, daß er dafür sorgt, daß der Kaltstarter und sein gespeichertes Image nie überschrieben werden. Obendrein muß er sich um die Sicherheitsdinge kümmern, die du beim Flashen festlegst: also wenn du ein Magic an bestimmter Stelle vorsiehst, dann soll er vor dem Flaschen diese Stelle mit allem Anderen zusammen zwar ablöschen, aber er darf nix, was im zu flashenden Code an dieser Stelle vorkommt, dorthin schreiben. erst wenn das Ende des zu flashenden Codes erreicht ist, die Prüfsumme(n) stimmen und sonstnochwas was du festgelegt hast stimmt, schreibt er an die betr. Stelle das Magic. So ist sichergestellt, daß das Magic nur dann dasteht, wenn der gesamte Flashvorgang nach deinen Wünschen perfekt durchgelaufen ist. So hast du immer eine (rudimentäre) Firmware in der Box, mit der du jederzeit erneut flashen kannst und du kannst das Flashen jederzeit tun - entweder vom PC aus, oder wenn deine Anwendung es selber initiieren will oder wenn der Kaltstarter es auslöst, weil er Gründe dafür hat oder von Hand, weil z.B. die Box abgestürzt ist. Ach ja, ich hab sowas bei meinen Geräten und ich hab als Datenübertragung mir 1 K große Blöcke ausgeguckt, die jeweils mit Adler32 abgesichert und auf simple Weise ein bissel komprimiert sind. Die Kompression ist nicht doll, aber sie beinhaltet eben auch, daß es ein Bitstream ist, falls das bei dir ein Thema sein sollte. W.S.
Chris S. schrieb: > das ist Grundidee in meinem zweiten Ansatz, allerdings mit > angesprochenen Problemfall: was passiert wenn der uC sich aufhängt? Gibt > es da was besseres als den USB-ID Pin zu "missbrauchen"? Den ID Pin habe ich auch schon erfolgreich missbraucht: Ein kommerzielles Produkt eines Fremdherstellers wurde von mir mit einer Zusatzplatine versehen, welche den ID-Pin sowohl für eine Fernbedienungsfunktion als auch für die Programmierung des Controllers meiner Erweiterung genutzt wurde. Als Bootloader nutzte ich den AVR Bootloader FastBoot von Peter Dannegger im 1-Wire-Modus.
Hab ich mich etwa so undeutlich ausgedrückt? Mir ist bewusst was ein Bootloader ist und was er tun soll. Auch ist mir bekannt wie die grundsätzlichen Konzepte aussehen und wie ein Bootloader überprüft ob eine gültige Applikation geflasht wurde oder vorhanden ist. mein Problem ist: Was mach ich wenn die Software sich aufgehängt hat? Einen Resetschalter gibt es nicht, nur eine USB-Buchse und einen Ladestecker. Das der eigentliche Weg vorsieht, keine software zu flashen/herrauszugeben die sich aufhängen kann, oder einen versteckten Reset-Taster vorzusehen wenn man diesen Fall nicht ausschließen kann, ist mir auch bewusst. Falls jemand eine gute Idee hat oder sogar praktische Erfahrung mit dem genannten Problem, würde ich mich freuen. Ansonsten werde ich den Bootloader nach dem von Gerd E., oder zumindest so ähnlich, umsetzten und mir eine kreative monoflop schaltung ausdenken welche auf welche auf ein USB_Vbus event Trigger und mir einen reset auslöst sollte die Anwendungssoftware nicht rechtzeitig reagieren.
IMHO wäre das ein klassischer Einsatz eines Watchdogs. Wenn die Software sich verrannt hat und den Watchdog nicht mehr regelmäßig resetten kann, wird sie selbst vom Watchdog resettet. Viele moderne µC haben eine Watchdog-Einheit an Board, wenn nicht kann man ein externes Watchdog-IC im Gerät einbauen. Häßlich wird es dann bei deinem "FW Update aufgrund hängender SW" Konzept.
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.