-
Also das Programm funktioniert und der BootLoader auch.
Irgend wo ist der Wurm drin...
Selbst wenn ich den BootLoader einzeln reinschreibe und dass
Prog damit hinter her schiebe, läuft es nicht.
Der Grund ist relativ einfach: Zeitersparnis
Bei neuen Geräten müßten wir dann zwei Schritte machen:
1. BootLoader in die CPU mit ISP-Schnittstelle programmieren
2. Dann das Prog per Sellerie in die CPU
Hat bisher auch gut funktioniert, da ich eine (ur)alte Version des
Compilers (1.11.67) verwendet habe. Der hat aber leider die "Macke",
den 64k-Wechsel nicht sauber zu verwalten und ich muß an der
Stelle eine Lücke ins Programm zaubern. Den Speicher brauche
ich aber jetzt, da es eng wird.
Wenn ich das gleiche Programm mit einer aktuellen Version des
Compiler übersetze, bekomme ich die Fehlermeldung "no more
space for Bit" im Teil des BootLoader. Selbst Marc weiß (angeblich?)
nicht, was er da gemacht hat... Habe ihn jetzt schon mehrfach
dazu befragt.
Werde morgen Versuche mit dem MegaLoader von MicroSyl machen.
Mir läuft jetzt die Zeit zu schnell davon!
Danke und Gruß,
Frank
-
Hi,
ich habe mal ähnliche Sachen ebenfalls mit dem MegaLoad gemacht.
Die Prozedur, die du scheinbar erreichen möchtest, hatte ich so gemacht:
Microsyl Bootloader in den Mega geflasht (keine Lockbits setzen).
Per Bootloader die Anwendung geladen. Wenn alles läuft (Anwendung und erneutes Flashen per Megaload) kannst du den ATMega mit deinem Programmer wieder komplett auslesen und du erhältst deine Anwendung + Bootloader hinten dran als Bin bzw. Hex File.
Dieses kannst du in deine anderen Controller flashen und bei Bedarf auch die Lockbits entsprechend setzen.
-
Danke @repi64,
habe dieses Problem erst einmal vom Eis :)
nachdem mein Kollege den Sonntag damit verbracht hat,
Hex-Files zu vergleichen, sind wir auf die Lösung gekommen:
Der "alte Assembler" BootLoader darf im Hex-File wirklich
nur Data-Records enthalten. Das haben ältere Versionen vom
Bascom-Compiler tatsächlich auch so "falsch" erzeugt. Deshalb
konnte man die "alten" Hex-Files auch nicht mit dem AVR-Studio
programmieren. Aktuelle Compiler machen echte Intel-Hex-Files,
die wiederum vom "alten" BootLoader" nicht zu gebrauchen sind...
Bei 128k wird aber bei einem "normgerechten" Hex-File zwei
Zeilen mit :02xx als Kennzeichnung "Extended Segment Address Record" eingefügt.
Diese Zeilen Programmiert der BootLoader ganz braun einfach in
den Flash der CPU und das Prog läuft nicht...
Die Idee mit dem Auslesen hatten wir auch - hatte aber auch nicht
funktioniert, da beim Auslesen mit dem AVR-Studio auch "echte"
Hex-Files erzeugt werden, die das oben genannte Problem haben.
Lösung:
1. Mit HxD das Bin-File des Programmes und des BootLoaders
verketten und den BootLoader an die Start-Adresse schieben.
Dabei die "Lücke" zwischen Programm und BootLoader brav
mit "FF" aufgefüllt lassen
2. Das verkettet Bin-File in ein Intel-Hex-File exportieren
3. Kopie davon erstellen, damit man das mit dem AVR-Studio
programmieren kann
4. Im Hex-File die zwei Zeilen :02xx löschen
Nun lässt sich das veränderte Hex-File mit dem BootLoader laden...
Habe inzwischen mit dem MCS-BootLoader experimentiert und
bin wieder voll auf die Schn**** gefallen. Aber das ist ein neues
Thema wert ](*,)
Danke an Alle,
Gruß Frank
