Hallo, 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?
Ähmm.. Ist die Startadresse nicht immer auf Null? Der Bootloader wird doch gar nicht gebraucht, dessen Startadresse liegt weit oben im Speicher.
> Ist die Startadresse nicht immer auf Null?
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.
Arduino F. schrieb: > Ähmm.. > > Ist die Startadresse nicht immer auf Null? > > Der Bootloader wird doch gar nicht gebraucht, dessen Startadresse liegt > weit oben im Speicher. Warum muss die Startadresse immer Null sein? In der Firmware stehen am Anfang irgendwelche Konfigurationstabellen...
> In der Firmware stehen am Anfang irgendwelche Konfigurationstabellen...
Unwahrscheinlich; dort müssten die Interruptvektoren der Firmware
stehen.
David G. schrieb: > Warum muss die Startadresse immer Null sein? 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.
David G. schrieb: > In der Firmware stehen am > Anfang irgendwelche Konfigurationstabellen... Immer Null! Da steht der Resetvektor. Meist in Form eines Sprungs. Das ist im Datenblatt auch nachzulesen.
:
Bearbeitet durch User
> Die Startadresse wird von der Hardware des Prozessors vorgegeben. > Bei allen mir bekannten ATMega und Co ist das NULL. Die Startadresse wird durch das Fuse-Bit BOOTRST vorgegeben. Anschließend könnte ein Bootloader theoretisch irgendwohin springen.
Hallo, anbei das Firmware.hex file. Hmm, dann ist es schon komisch das es nicht läuft. Die Fuse Bits habe ich so gesetzt, das kein Bootloader vorhanden ist...
> 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?
Hallo, wie meinen sie das? Ich habe mehrere Varianten probiert, aber irgendwie passiert nichts. Programmiert habe ich den ATMEGA mit einem BeeProg über ISP.
David G. schrieb: > anbei das Firmware.hex file. klassischer Aufbau mit Vektortabelle auf 0. Zeig bitte, wie die Fuses aussehen.
> wie meinen sie das?
Im Auslieferungszustand des ATmega64 ist das Fuse-Bit M103C gesetzt,
d.h. der uC arbeitet als ATmega103.
Also ohne Kenntnis der Fuse-Bytes des Güterzuges wird es jetzt etwas
schwierig ...
Angehängte Dateien:
-
Fuses.jpg
73 KB
Die habe die Fuse Bits gesetzt: Die Steuerung arbeitet mit einem Quarz mit 15Mhz.
:
Bearbeitet durch User
Beitrag #7813909 wurde vom Autor gelöscht.
David G. schrieb: > Die habe die Fuse Bits gesetzt 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.
:
Bearbeitet durch User
Arduino F. schrieb: > Ist die Startadresse nicht immer auf Null? 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.
>> Die habe die Fuse Bits gesetzt > Dann startet der Mikrocontroller an Adresse 7E00. Nanu - da steht doch eindeutig "unprogrammed" bei BOOTRST, und das Fuse-High-Byte mit 0xFF bestätigt das: folglich startet der ATmega64 bei 0. Aber mir ist noch immer unklar, ob die gezeigten Fuses die des Originalzustandes (des Güterzuges) sind.
Rainer W. schrieb: > Arduino F. schrieb: >> Ist die Startadresse nicht immer auf Null? > > 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...
> keine Fusebits mehr auszulesen sind
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 ...)
S. L. schrieb: >> keine Fusebits mehr auszulesen sind > > 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?
Rainer W. schrieb: > Der Reset-Vektor steht als erster Eintrag in der Interruptvektortabelle. > Und da geht der Programmanlauf nach einem Reset los. So weit stimmt das. > In diesem ersten > Eintrag muss dir Startadresse für das Programm stehen. Nein. Dort muss normaler Code stehen. Und der besteht typischerweise aus einem Sprung zur tatsächlichen Startadresse des Programmes. Das ist bei den AVR8 anders als bei den meisten anderen Architekturen, bei denen in den diversen Vektoren tatsächlich nur Adressen stehen.
S. L. schrieb: > Nanu - da steht doch eindeutig "unprogrammed" bei BOOTRST Oh, ich habe nur auf die Zeile darüber geachtet
David G. schrieb: > Gibt es denn die Möglichkeit ein Programm zu schreiben, was die > Bootloader Daten über RS232 ausgegeben kann, von einer funktionierenden > Steuerung? Nein, das müsste dann schon Bestandteil der funktionierenden Steuerung sein.
David G. schrieb: > 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.
Ob S. schrieb: > Rainer W. schrieb: > >> Der Reset-Vektor steht als erster Eintrag in der Interruptvektortabelle. >> Und da geht der Programmanlauf nach einem Reset los. > > So weit stimmt das. > >> In diesem ersten >> Eintrag muss dir Startadresse für das Programm stehen. > > Nein. Dort muss normaler Code stehen. Und der besteht typischerweise aus > einem Sprung zur tatsächlichen Startadresse des Programmes. > > Das ist bei den AVR8 anders als bei den meisten anderen Architekturen, > bei denen in den diversen Vektoren tatsächlich nur Adressen stehen. Da steht 0c94 E201 Ist das der Sprung zur Adresse E201?
David G. schrieb: > Da steht 0c94 E201 > Ist das der Sprung zur Adresse E201? Ich denke, ja https://ww1.microchip.com/downloads/en/DeviceDoc/AVR-Instruction-Set-Manual-DS40002198A.pdf
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.
Dieter S. schrieb: > 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?
:
Bearbeitet durch User
David G. schrieb: > Ob S. schrieb: >> Rainer W. schrieb: > Da steht 0c94 E201 > Ist das der Sprung zur Adresse E201? Nein. Springt zur Word-Adresse 0x1E2, also Byte-Adresse 0x3E4.
David G. schrieb: > > 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?
:
Bearbeitet durch User
Hi, vielen Dank für die geswappten Daten. 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.
Dieter S. schrieb: > 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!!!
:
Bearbeitet durch User
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.
Dieter S. schrieb: > 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...
Der Bootloader lässt sich bestimmt nachbauen. Ob sich der Aufwand lohnt ist eine andere Frage, so oft wird es wohl kein Software Update geben.
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.