Ich habe eine Steuerung mit einem Atmega64-16AU für einen kleinen Güterzug bei der so ziemlich alles defekt war. Die Defekte wurde behoben und der Atmel auch mit getauscht. Die Firmware, die per Download bereit gestellt wird, habe ich auch per ISP geflasht. Allerdings fehlt der Bootloader vom Atmel. Dieser wird leider nicht zur Verfügung gestellt. Wie bekommt man denn die Einsprungadresse für die Mainloop des Hauptprogramms raus und könnte das Hauptprogramm auch ohne Original Bootloader laufen?
Sollte man von einem 'neutralen' Bootloader so erwarten, aber theoretisch ist im Zusammenspiel Bootloader - Firmware ja sehr viel möglich.
Könnte David G. ja einfach mal ausprobieren, wenn - ja wenn da nicht die Angabe der Fuse-Bytes fehlte. Das ist der nächste Stolperstein.
Die Startadresse wird von der Hardware des Prozessors vorgegeben. Bei allen mir bekannten ATMega und Co ist das NULL. Zeig doch bitte das Hexfile. Nicht immer fängt es bei 0 an und ist ein monolithischer Block. Das kann durchaus munter hin und her gehen. Am Anfang jedes Records stehen die Ladeadresse und die Länge. Das Brennprogramm sortiert dann passend.
Die Fuse Bits habe ich so gesetzt, das kein Bootloader vorhanden ist...
Schon, nur - sonst gibt es bei den Fuse-Bytes (des Güterzuges) keine Abweichungen von denen des Auslieferungszustandes? Zum Beispiel das legendäre M103C?
Dann startet der Mikrocontroller an Adresse 7E00. Dort liegt typischerweise ein Bootloader, und der springt typischerweise nach Adresse 0000.
Aber es könnte natürlich ein untypischer Bootloader sein, der woanders hin springt. Nur bezweifle ich, dass der dann von Atmel kommt.
Der Bootloader von Arduino (Optiboot) würde dort hin passen, aber der springt nach Adresse 0000 und ist somit optional. Dein Projekt hätte auch ohne ihn funktioniert.
Der Reset-Vektor steht als erster Eintrag in der Interruptvektortabelle. Und da geht der Programmanlauf nach einem Reset los. In diesem ersten Eintrag muss dir Startadresse für das Programm stehen. (Datenblatt Reset and Interrupt Handling). Dort steht auch wie der Einsprung in den Bootloader mit BOOTRST Fuse gesteuert wird.
Der Reset-Vektor steht als erster Eintrag in der Interruptvektortabelle.
Und da geht der Programmanlauf nach einem Reset los. In diesem ersten
Eintrag muss dir Startadresse für das Programm stehen. (Datenblatt Reset
and Interrupt Handling). Dort steht auch wie der Einsprung in den
Bootloader mit BOOTRST Fuse gesteuert wird.
Hi,
Das Problem ist halt,das bei einem defekten Controller keine Fusebits mehr auszulesen sind... Wie nun also die Originalen sind bleibt ein Rätsel...
Es ist im übrigen ein Güteraufzug... 🤣
Blöde Korrektur...
Es hätte ja sein können, dass sie mit der Hex-Datei mitgeliefert wurden.
Dann wäre es wohl einen Versuch wert, die M103C wieder einzuschalten - oder gab es einen Grund, sie zu ändern?
(Ich hatte mich schon gefragt, was das wohl für ein Modellzug sein mag mit einem solchen Controller ...)
Es hätte ja sein können, dass sie mit der Hex-Datei mitgeliefert wurden.
Dann wäre es wohl einen Versuch wert, die M103C wieder einzuschalten -
oder gab es einen Grund, sie zu ändern?
(Ich hatte mich schon gefragt, was das wohl für ein Modellzug sein mag
mit einem solchen Controller ...)
Das werde ich morgen mal versuchen.
Gibt es denn die Möglichkeit ein Programm zu schreiben, was die Bootloader Daten über RS232 ausgegeben kann, von einer funktionierenden Steuerung?
Gibt es denn die Möglichkeit ein Programm zu schreiben, was die
Bootloader Daten über RS232 ausgegeben kann, von einer funktionierenden
Steuerung?
Nicht wirklich. Wenn der Controller gelockt ist, kannst du Code nur darauf bringen, indem du den vorhandenen löschst (chip erase). Dann gibt es aber nichts mehr zum Auslesen.
Ist der Controller hingegen nicht gelockt, brauchst du kein spezielles Programm zum Auslesen. Das kannst du dann einfach mit dem Programmer machen.
Die Fusebits müssen auf Quarz >8MHz gestellt werden und der M103 Mode auf disabled. JTAG muß auch disabled werden, wenn dessen 4 Portpins benutzt werden.
Bezüglich Bootloader war das bei den älteren AVRs clever gelöst, der Bootloader wird oberhalb der Applikation abgelegt. Der Bootloader weiß also, daß die Applikation immer an 0x0000 startet. Und die Applikation muß nicht wissen, ob überhaupt ein Bootloader benutzt wird.
Die neuen AVR128 usw. haben das leider vergessen. Bei denen muß der Bootloader gesagt bekommen, wo die Applikation liegt. Und die Applikation muß mit einem speziellen Linkerscript hinter den Bootloader gelinkt werden.
Weiterhin kann man natürlich die bei den ATtiny gebräuchliche Methode verwenden. Der Bootloader sitzt am hinteren Flashende, schnappt sich den Sprungeintrag an 0x0000 und ersetzt ihn durch einen Sprung zu sich selber. Er kann dann allerdings keine Interrupts benutzen, was aber auch nicht nötig sein sollte.
Bei der Firmware.hex Datei sind die Bytes vertauscht, der erste Befehl ist "940C 01E2", also "JMP 0x01E2". Wenn die Bytes stimmen sollte ziemlich am Anfang das Program-Datum "20130724" sein. Eventuell liegt es ja daran.
Der Rest ergibt auf den ersten Blick sinnvollen Code, auch die Interrupt-Funktionen liegen an sinnvollen Stellen.
Bei der Firmware.hex Datei sind die Bytes vertauscht, der erste Befehl
ist "940C 01E2", also "JMP 0x01E2". Wenn die Bytes stimmen sollte
ziemlich am Anfang das Program-Datum "20130724" sein. Eventuell liegt es
ja daran.
Der Rest ergibt auf den ersten Blick sinnvollen Code, auch die
Interrupt-Funktionen liegen an sinnvollen Stellen.
Ok, soll ich die Bytes alle tauschen und es nochmal versuchen?
Ok, soll ich die Bytes alle tauschen und es nochmal versuchen?
Ja, die HEX Datei mit getauschten Bytes ist im Anhang.
Es gibt allerdings im Code einen Sprung an die Adresse 0x7000, also vermutlich in den nicht vorhandenen Bootloader. Ich muss mir das noch genauer ansehen wann dieser Sprung ausgeführt wird.
Wie sieht es mit dem internen EEPROM aus, gibt es dafür einen Dump?
Es gibt eine Möglichkeit die Steuerung über RS232 mit einem BT Dongle und einer App zu updaten.
Eventuell springt er dann in den Bootloader um die Daten im Flash auszutasuchen.
Ein EEPROM Dump liegt leider nicht vor, aber kann im Betrieb auch über den BT Dongle mit einer App gespeichert werden. Ich nehme an das es sich dann um die Konfiguration der Etagenazahl usw. handelt.
Die Firmware ist ziemlich umfangreich und es erfolgt relativ viel Zugriff auf den EEPROM.
Falls die Firmware jetzt startet sollte man das daran erkennen dass Daten in den EEPROM geschrieben werden. Auf die Schnelle sieht es so aus als ob beim Programmstart ein Teil des EEPROMs initialisiert wird falls dort nicht die erwarteten Daten stehen.
Die Firmware ist ziemlich umfangreich und es erfolgt relativ viel
Zugriff auf den EEPROM.
Falls die Firmware jetzt startet sollte man das daran erkennen dass
Daten in den EEPROM geschrieben werden. Auf die Schnelle sieht es so aus
als ob beim Programmstart ein Teil des EEPROMs initialisiert wird falls
dort nicht die erwarteten Daten stehen.
Also die Steuerung läuft wieder ganz normal, und der EEPROM wurde initialisiert.
Wenn man mit dem BT Dongle ein Firmwareupdate anschiebt, geht die Anlage aus und startet erneut. Konfigurationen programmieren geht alles problemlos.
Ich gehe also davon aus das der Bootloader nur für das Firmwareupdate genutzt wird.
Die Kommunikation über RS232 erfolgt mit 9600 Baud und wenn er ein Update anstößt, schickt er immer 256Byte Blöcke...
Vielleicht hilft das ja den Bootloader zu identifizieren!!!
Der Bootloader muss ja auch wissen dass er ein Software Update machen soll.
Zum einen wird er eine Prüfsumme über das Programm berechnen, bei dem Hex File stehen wohl die letzten beiden Bytes im Zusammenhang mit der Prüfsumme. Wenn die Prüfsumme passt wird das Programm ab 0x0000 aufgerufen, wenn nicht wartet der Bootloader auf ein Update.
Zum Anderen gibt es Flags im EEPROM die dem Bootloader signalisieren dass er ein Update durchführen soll. Die Software schreibt dabei entweder 0x55 oder 0xAA in die EEPROM Adresse 0x001, 0x01 in 0x000 und 0x55 in 0x01F bevor sie nach 0x7000 springt.
Der Bootloader muss ja auch wissen dass er ein Software Update machen
soll.
Zum einen wird er eine Prüfsumme über das Programm berechnen, bei dem
Hex File stehen wohl die letzten beiden Bytes im Zusammenhang mit der
Prüfsumme. Wenn die Prüfsumme passt wird das Programm ab 0x0000
aufgerufen, wenn nicht wartet der Bootloader auf ein Update.
Zum Anderen gibt es Flags im EEPROM die dem Bootloader signalisieren
dass er ein Update durchführen soll. Die Software schreibt dabei
entweder 0x55 oder 0xAA in die EEPROM Adresse 0x001, 0x01 in 0x000 und
0x55 in 0x01F bevor sie nach 0x7000 springt.
Ok, dann ist das ein spezieller Bootloader und nicht Optiboot oder ähnlich...
