Hallo, ich möchte gern einen Bootloader basteln, der ein Gerät von einer Chipkarte her aus Firmwareupdaten kann. Es handelt sich dabei um 32kB Chipkarten. Das Problem ist, dass das Hexfile vom eigentlichen Programm nach dem compilieren > 64kB groß ist, daher passt es nicht mehr auf die Karte. Jetzt habe ich einen Hex to Binary decoder im www gefunden, der mir mein Hexfile auf ~8kB zusammengedampft hat. Leider weiß ich jetzt nicht mehr weiter, wie ich diese Daten in den Flash schreiben kann? Warauf muss ich achten, bzw. wie fasse ich die Daten zu einer Seite zusammen? kann mir jemand helfen? Ingo
Also ich sehe auf jeden Fall alle 32 Byte ein CR + LF, ich denke hierbei handelt es sich um eine Seite?
Mit einem Bootloader flasht man normalerweise .bin-Dateien. .hex sind Text, die muesste der erst wieder uebersetzen. fonsana
Oh, ich habe versehentlich eine Hex-to Binary Converter benutzt, der mein Programm als Zahl gesehen hat, kann ja so nicht funktionieren... Woher bekomme ich nun ein Binary (-.bin Dateien), AVR Studio spuckt sowas nicht aus. Ingo
Ich arbeite selbst nicht damit, aber das sollte mich wundern, da wird es eine Einstellmoeglichkeit geben. fonsana
Stefan Ernst schrieb: > avr-objcopy -I intel -O binary XXX.hex XXX.bin Danke, aber wo füge ich das ein?
Ingo schrieb: > Stefan Ernst schrieb: >> avr-objcopy -I intel -O binary XXX.hex XXX.bin > Danke, aber wo füge ich das ein? Google mal nach "Kommandozeile". Alternativ kannst du in deiner IDE auch nach Post-Build-(Steps|Actions|Commands|Whatever) suchen.
Ich hab jetzt unter Atmel Studio 6 unter Postbuilt eingetragen:
1 | avr-objcopy -I intel -O binary Controller.hex Controller.bin |
und bekomme folgenden Fehler:
1 | Error 1 The command "avr-objcopy -I intel -O binary Controller.hex Controller.bin" exited with code 1. C:\Program Files (x86)\Atmel\Atmel Studio 6.0\Vs\Avr.common.targets 27 5 Controller |
Ich verstehe den Fehler nicht. Wenn ich das unter der Windows-Eingabeaufforderung eingebe kommt immer:
1 | avr objcopy:Controller.hex: Invalid bfd target |
Und jetzt?
Hi
>Und jetzt?
Es gibt auch ein Programm, 'hex2bin.exe', das hex-Files in bin-Files
wandelt.
MfG Spess
So einen Konverter sollte man als Anwender selbst schreiben koennen, sonst sollte man's seinlassen.
Zer.Troll schrieb: > So einen Konverter sollte man als Anwender selbst schreiben koennen, > sonst sollte man's seinlassen. Trollen sollte man können, sonst sollte man es lassen.
und wie kriege ich das jetzt in den AVR bzw. wie ist es aufgebaut? Es sieht ganz schön chaotisch aus! Ingo
Ingo, du hast jetzt ein lineares binäres imgae deines programmes, welches bei adresse 0x0000 mit seinem ersten byte anfängt. je nachdem was für einen avr du benutzt, kannst du diese daten pageweise (128 oder 256 bytes, je nach uC-typ) nun vom bootloader aus in den codespeicher schreiben. wie ? - dafür gibt es appnotes mit beispilecode oder du schaust mal in die diversen bootlaoder implementierungen die hier so in der codesammlung rumfliegen rein. viel erfolg, tom.
Ingo schrieb: > und wie kriege ich das jetzt in den AVR bzw. wie ist es aufgebaut? Das ist gar nicht irgendwie "aufgebaut". Das sind die puren binären Daten, die ins Flash müssen.
Eigentlich muss ich doch "nur" eine Seite im Programmspeicher puffern und diese dann in einem rutsch in den Flash schreiben, oder? Das Binary ist ja schon mein "Programm", oder? Ingo
Ingo schrieb: > Das Binary > ist ja schon mein "Programm", oder? das Binary sind die Daten die Du direkt in den Programmspeicher schreiben kannst
Da fehlt noch was... Das Binaerfile wird so geschrieben wie es kommt. Das Datenblatt des AVR zeigt wie man programmieren muss. Allenfalls muss man eine Seite im RAM buffern oder auch nicht.
So, soweit klappt jetzt alles, das Binary landet im Flash und alles ist gut. Jetzt stehe ich noch vor dem kleinen Problem, dass ich gern vor die Daten im Binary einen Kontrollstring packen würde, der die Karte als gültig kennzeichnet. Ich habe bis jetzt mit "TinyHexer" versucht das Binary zu editieren, was grundsätzlich auch möglich ist, aber nur, indem ich vorhandenes überschreibe. Ich will es jedoch davor einfügen und alles um 16 Positionen nach hinten schieben! Kennt jemand ein Tool das das kann? Ingo
Ingo schrieb: > Ich will es jedoch davor einfügen und > alles um 16 Positionen nach hinten schieben! Kennt jemand ein Tool das > das kann?
1 | cat id.dat data.bin > all.bin |
Ingo, berechne eine crc16 oder crc32 über dein binäres image und füge das am ENDE an. bevor du die daten wegprogrammierst mit der crc-berechnung die konsistenz auf deinem speichermedium überprüfen. wenn du jetzt noch am anfang "steuerinformationen" unterbringen willst, hex2bin hat m.A. nach einen offset parameter, mit dem sich das zu erzeugende image verschieben lässt. davor wird dann mit 0xff oder was auch immer (anderer parameter) aufgefüllt. viel erfolg, tom.
Soweit so gut, eine Frage nur noch bezüglich des Flashens: Der Bootloader wird ab Adresse 0x8000 im Flash geflasht. Wenn ich jetzt die Anwendung nicht über den Bootloader, sondern "normal" flashen will, geht das nur, wenn ich das Häkchen bei "Erase Flash bevore programming" weg mache, da er sonst den Bootloader mitlöscht. Der eigentliche Programmiervorgang soll zwar über die Chipkarte laufen (später), jedoch in der Programmentwicklungsphase ist es sehr müssig, immer eine neue Karte auszusetzen, diese per hand noch etwas zu editieren und dann per Bootloader zu flashen. Daher die Frage, wie kriege ich den Speicherplatz der Application 0- 0x7FFF sauber programmiert (also gelöscht vorm flashen) ohne den Bootloader zu killen? Leider habe ich dazu keine passende Information gefunden. Im Artikel hier von -D geredet, jedoch nicht näher darauf eingegangen. Ingo
Ingo schrieb: > Daher die Frage, wie kriege ich den Speicherplatz der Application 0- > 0x7FFF sauber programmiert (also gelöscht vorm flashen) ohne den > Bootloader zu killen? Per ISP? Gar nicht. Ingo schrieb: > Der eigentliche > Programmiervorgang soll zwar über die Chipkarte laufen (später), jedoch > in der Programmentwicklungsphase ist es sehr müssig, immer eine neue > Karte auszusetzen, diese per hand noch etwas zu editieren und dann per > Bootloader zu flashen. Vorschlag 1: Füge die Bootloader-Hex der App-Hex hinzu (z.B. mit srec_cat), dann wird der Bootloader auch immer wieder neu mit der App zusammen programmiert. Vorschlag 2: Ersetze den Bootloader für die App-Entwicklungs-Phase durch einen "einfacheren" (z.B. seriellen) Bootloader.
oder Vorschlag 3: während der Entwickungsphase den Bootloader ganz weglassen und a) die Bootloaderfuse auch raus nehmen b) an der Bootloaderstartadresse ein jmp 0x0000 mit flashen Sascha
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.