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 MSP430JTAG 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.
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.
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!
