Hallo Zusammen, mein MSP430 Projekt neigt sich allmählich dem Ende, alle Funktionalitäten sind implementiert. Nun stehe ich vor einer Letzten Herausforderung. Da der MSP430 fest verbaut ist, muss der MSP430 sich seine Firmware über SPI von einem FPGA holen. Der FPGA schreibt also über SPI ins RAM des MSP430. Soweit die Idee. Was muss der MSP430 in diesem Fall tun? Wie muss er sich selbst umkonfigurieren? Ich habe von dem Thema bisher nur sehr wenige Kenntnisse. Ein Schlüsselwort hierbei ist wohl: Bootstrap Kann mir Jemand Tipps geben, nach welchen Begriffen mann hier am Besten sucht und ob es eventuell Beispiele gibt? Beste Grüße, Michael
Was du brauchst ist ein Bootloader. Die Firmware ins RAM wird wohl kaum gehen. Ich weiß zwar nicht welchen Typ du einsetzt aber das Flash ist dutzende male größer als das RAM. - Du wirst direkt in das RAM schreiben müssen, ggf. mit einer Checksumme zum prüfen Bootloader Idee: 1. Start 2. Warte auf SPI Befehl binnen x ms, andernfalls starte "weiter" 3. SPI Befehl kommt vom FPGA 4. FPGA schickt Datenpacket x von y 5. Prüfe Empfangenes Datenpacket -> Gut dann ab ins Flash an Stelle z (Überschreibe aber nicht den Bootsektor!); Schlecht, verwerfen und FPGA melden 6. Neustart So in etwa ;-)
Ich hab das mit einem eigenen "Bootloader" gemacht, der per Linker-Script in ein paar Sektoren im Flash sitzt, die beim Update nicht gelöscht werden. Für das Update wichtige Funktionen sind da drin und überschreiben dann den Rest vom Flash. Ansonsten kannst du auch Code aus dem Flash in den RAM kopieren und von dort ausführen und dann den gesamten Flash löschen, wenn nötig und genug RAM vorhanden.
Tüddel schrieb: > lass deinen FPGA das JTAG/TWI interpretieren und benutze den FPGA als > Programmer Schwierig, denn das MSP430 JTAG ist nur auf oberster elektrischer Ebene wirklich JTAG. Darunter ist der Mist zu nix kompatibel. Dann eher noch über den in jedem MSP430 fest eingebrannten UART Bootloader.
Warum denn eigentlich ein FPGA? Wenns kein Bootloader sein soll, kannst Du grundsätzlich doch auch einen zweiten MSP430 als Programmer für den ersten MSP430 nehmen? Wenns nicht alles bis aufs letzte kByte ausgereizt ist, wohl sogar mit derselben Flash-Größe?
Danke für eure Ratschläge. Ich nutze einen MSP430FR5729 mit integriertem FRAM. Der MSP430 ist lediglich über CS, MOSI, MISO, und CLK mit dem FPGA verbunden. Ich lese mich gerade quer durch die TI Dokumentation und stelle fest, dass der MSP über eine bestimmte Frequenz am RST und TEST Pin erst in einen definierten Zustand gebracht werden muss, um neue Firmware empfangen zu können. >Ich hab das mit einem eigenen "Bootloader" gemacht Daran habe ich auch schon gedacht: 1. FPGA spricht MSP mit "festgelegeter" Adresse an 2. MSP startet Watchdog und deaktiviert alle Interrupts 3. FPGA sendet Firmware 4. MSP schreibt nächsten x Datenpakete ab Startadresse aufwärts ins FRAM 5. FPGA beendet vor Ablauf des Watchdogs seinen Schreibvorgang 6. Watchdog läuft ab, MSP430 startet mit neuer Firmware neu So in etwa müsste das doch funktionieren, oder?
nein. falsches Bit und du hast einen Brick gemacht. Im groben wird's gehen, aber den Watchdog kannst ja regelmäßig zurücksetzten bis der reset benötigt wird. mfg ich
Ich habe mit dem MSP430 noch nichts gemacht, aber wie beschrieben könnte es gehen. Nur das mit dem Watchdog halte ich für gefährlich, wenn das Programm nicht richtig/komplett übertragen wurde knallt es. Über ein SPI Register kann man die Daten übertragen und über ein weiteres Kommandos, wie Verify und dann Block schreiben. Zum Schreiben muss wahrscheinlich mit der Memory Protection Unit der Schreibschutz aufgehoben werden, für das FRAM Handling hat Ti dieses Dokument: http://www.ti.com/lit/an/slaa628/slaa628.pdf
> Nur das mit dem Watchdog halte ich für gefährlich Guter Hinweis. Ja, man sollte besser ein Protokoll anlegen: 1. FPGA sendet Status Wort: START_FIRMWARE_DOWNLOAD 2. MSP430 deaktiviert alle Interrupts 3. FPGA überträgt Firmware 4. FPGA überträgt Status Wort: END_OF_FIRMWARE 5. MSP startet Watchdog 6. Watchdog läuft ab 7. Restart Das sollte funktionieren. Zusätzlich kann der MSP noch ACKs übertragen um Fehler bei der Übertragung zu erschweren. Ich habe zwei Launchpads hier zum testen und probiere das einfach mal aus :-) Ich muss nur aufpassen ab welcher Adresse und bis zu welcher Adresse ich schreibe. Aufschluss sollte mit das *.cmd file geben.
Ich hab selber noch keinen Bootloader von außen geschrieben, aber interessieren würde es schon, da ja dann alle Geräte wenigstens updatebar wären, ohne jedesmal JTAG anschließén zu müssen. Mein Ansatz wäre eher ein externes Flash gewesen, mikeelectric hat dazu ein ganz gutes Video, wobei ichs auch noch nicht umgesetzt habe, vorteil daran ist, dass es quasi auf alle Platformen anwendbar ist: https://www.youtube.com/watch?v=jbLy6kE-Szg vielleicht hilfts.
> Mein Ansatz wäre eher ein externes Flash gewesen
Das gibt meine Hardware leider nicht her ;-)
Hallo zusammen, mir ist im Laufe der letzten Tage noch eine Idee gekommen. Ich dachte die ganze Zeit, ich könnte den BSL nur über eine Entry-Sequenz starten. Das geht aber auch Software-gesteuert. Außerdem kann ich das USCI_A Modul auch für das UART-Protokoll konfigurieren. Damit erfülle ich nun alle Anforderungen, um den BSL verwenden zu können. Was ich noch nicht ganz verstehe: Liegt dann die komplette Steuerung auf der Master-Seite? Oder muss ich auf Slave-Seite, abgesehen vom starten des BSL, auch etwas machen? Beste Grüße, Michael
Michael schrieb: > Hallo zusammen, > > mir ist im Laufe der letzten Tage noch eine Idee gekommen. Ich dachte > die ganze Zeit, ich könnte den BSL nur über eine Entry-Sequenz starten. > Das geht aber auch Software-gesteuert. Das schon, aber... > Außerdem kann ich das USCI_A Modul auch für das UART-Protokoll > konfigurieren. Damit erfülle ich nun alle Anforderungen, um den BSL > verwenden zu können. ...der BSL reagiert nur auf diese Timer-Pins, die z.B. auch für die Timer-gesteuerte UART benutzt werden. Das musst du entsprechend verdrahten. Beim FRAM basierten müsste ich jetzt schauen, aber bei den anderen geht die Hardware UART nicht für den BSL zu verwenden. > Was ich noch nicht ganz verstehe: > > Liegt dann die komplette Steuerung auf der Master-Seite? > Oder muss ich auf Slave-Seite, abgesehen vom starten des BSL, auch etwas > machen? Ja, macht alles der Master, das protokoll ist offengelegt. Der BSL sitzt ja in einem geschützten Flash-Bereich. Du kannst aber bei den aktuellen MSPs den BSL auch überschreiben mit einem eigenen, da könntest du dann die SPI verwenden. Edit: Hab eben mal nachgeschaut, bei deinem MSP liegt der BSL auf P2.0 und P2.1 das kannst auch als UCA0SIMO und UCA0SOMI verwenden, von daher sollte das halbwegs gehen.
:
Bearbeitet durch User
Hallo Christian, danke für deine Antwort. >Edit: Habe eben mal nachgeschaut, bei deinem MSP liegt der BSL auf P2.0 >und P2.1 das kannst auch als UCA0SIMO und UCA0SOMI verwenden, von daher >sollte das halbwegs gehen. Bie mir ist das USCI_A1 Modul verdrahtet, sprich P2.5 und P2.6. Habe ich auch grade im Datenblatt entdeckt. Damit geht das leider doch nicht so einfach wie gedacht. Dann doch die eigene Variante. Es gibt von TI das MSPBoot Beispiel. http://www.ti.com/lit/an/slaa600a/slaa600a.pdf Da wird die ganze SPI Kommunkation durch pollen auf IRG-Flags geregelt. Ich möchte hierzu aber eine SPI IRQ Service Routine verwenden. Kann ich während dem Laufenden Betrieb das FRAM neu beschreiben und dananch softwaregesteuert einen Reset auslösen lassen? Das aktuelle Programm wird nach meinem Verständniss nach vom RAM ausgeführt. Es sollte also nicht tragisch sein, wenn ich wärendessen das FRAM neu beschreibe.
Hallo allerseits, mittlerweile habe ich Fortschritte gemacht. Ich kann über SPI das FRAM des Slave beschreiben. All das läuft auf der Slave Seite in der SPI Interrupt Service Routine ab. Frage: Während des Updates muss die SPI Kommunikation / IRQ Routine erhalten und funktionsfähig bleiben. Wie ist eine IRQ Routine abgelegt? Wie kann ich mir das vorstellen? Ist diese schreibgeschützt oder ehe wie eine Funktion die überschrieben werden kann abgelegt? Beste Grüße, Michael
Michael schrieb: > Während des Updates muss die SPI Kommunikation / IRQ Routine erhalten > und funktionsfähig bleiben. Das geht nur, wenn du entweder den Bootloader Teil vom Flashen ausklammerst, oder den Bootloader in den RAM kopierst und von dort ausführst. In beiden Fällen kannst du aber nicht mit Interrupts arbeiten, da die Interrupt-Tabelle ja auch neu beschrieben werden muss. > Wie ist eine IRQ Routine abgelegt? Wie kann ich mir das vorstellen? Ist > diese schreibgeschützt oder ehe wie eine Funktion die überschrieben > werden kann abgelegt? Es gibt eine Interrupt-Tabelle, in der für jeden Interrupt eine Adresse eingespeichert ist, die bei Eintreten des INT angesprungen wird. Mehr ist das nicht. Der eigentliche Code steht ganz normal in der .text Section.
Hallo, danke für die schnelle Antwort. Ich habe nach einem Nachmittag voler grübeln mein Konzept leicht geändert. 1. Ich habe das FRAM in eine Partition A und B unterteilt. 2. Wenn neue Firmware geladen werden soll, wird diese in den Teil B + Checksumme abgelegt. 3. Der MSP430 läuft nach wie vor weiter, seine Firmware liegt ja in Teil A. Sobald er mitgeteilt bekommen hat, das neue Firmware für ihn bereit liegt, berechnet er zunächst die Prüfsumme der neuen Firmware in B und überprüft seine Prüfsumme mit der dort hinterlegten. Stimmen beide überein, startet er neu 4. Beim Neustart muss der Bootloader starten (durch vorheriges setzen eines flags an einer bestimmten Adresse, externes Event, etc.) und die Firmware von Teil B nach A kopieren. Ich denke, das ist die sinnvollere Methode und relativ "sicher". Was meint ihr? Beste Grüße, Michael
Hallo zusammen, ich habe die Aufgabe erfolgreich lösen können und meinen eigenen Bootloader implementiert. Anregungen habe ich mir unter Anderem hier geholt: https://daniel.duchna.pl/index.php/Msp430_bootloader An dieser Stelle danke ich Allen für die konstruktiven Ratschläge!
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.