Bootloader Mega103 und Mega128

    Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

    Aufgrund technischer Veränderungen ist der Mailverkehr innerhalb des Forums (Private Nachrichten) nur noch eingeschränkt möglich. Die Einschränkung ist notwendig, um zusätzliche Betriebskosten für das Forum zu vermeiden. Näheres zu den Hintergründen im Thread "Aktuelles zum Forum".Wir bitten um Verständnis.

    Hinweis kann nach Kenntnisnahme deaktiviert werden!

    • Bootloader Mega103 und Mega128

      Hier ist die Fortsetzung von
      Bootloader stoppt Microcontroller

      Pluto schrieb:

      Gibt es nicht die Möglichkeit Baskom den Speicherbereich mitzuteilen in den der Code beginnen soll? Damit könnte jeder AVR einen Bootloader nutzen (falls man es für sinnvoll hält)

      Doch, die Möglichkeit gibt es.

      Man kann $Loader benutzen oder
      die Anweisung .org

      Man kann auch den Loader mit option "Bootonly" angeben, dann wird nur der Bootloader-Teil als Bin-File generiert.
      Den kann man dann einem Befehl (glaube Lib) einfach zum normalen Programm am Schluss mit einbinden.
      Geflashed wird dann ein die Applikation, die den Bootloader beinhaltet.

      Siehe Bascomhilfe unter "$Loader"


      Bitlogger schrieb:

      Der M128 wird von Atmel mit gesetztem Fusebit m103 geliefert. Ist kein echter M128.
      Dann ist es wohl auch kein M128.
      Wieso sollte man dann den 103 als 128 laufen lassen können?

      Vielleicht hat der Hersteller wegen Lieferschwierigkeiten für den Mega103 einfach den Mega128 genommen, den vorkonfiguriert und dann entsprechend abgespeckt.
    • Das neue Thema passt zwar nicht richtig, kann bereits beendet werden. (Lichtblicke meinerseits) ;)
      Es ging hier nur nebenbei um ein generelles Problem mit dem Atmega 128, im Zusammenhang mit Prepes Thema Bootlader für Atmega2561.
      Zufällig, weil kein 2561 zur Hand, ersatzweise laut Datenblatt 2560, 640 und 128 in Frage kämen.

      Dabei ist aufgefallen, und das sollte Kernthema sein, ein Atmega128 ist kein echter Atmega 128, sondern ein vermutet (sinngemäß) auf Niveau Mega103 reduzierter Chip.
      Sowohl Hardwaretechnisch ab Werk, wie auch hier in Bascom wegen m128def.dat reduzierter Prozessor.

      Anstatt wie im Datenblatt vom Mega128 benutzten Registeradressbereiche für SRG bis runter zu PINF den Werten für den Mega128 zu zuweisen, wird in der m128def.dat die entsprechenden Werte für den m103def.dat zugewiesen.

      Das ist bei genauer Betrachtung kein wirkliches Problem, denn dann gilt der untere Registeradressbereich nur von Adresse 0 bis 3F, und der Bereich von 40 bis 5F bleibt frei, unbenutzt. Im anderen Fall bleibt halt der Registerbereich von 1F bis 0 frei, wenn die richtigeren Adressen für den m128 zugewiesen würden.

      Es gibt somit zwischen Mega103 und mega128 folgende Unterschiede.
      Dem Mega128 sind der untere Registeradressbereich wegen gesetztem Fusebit mega103 zugewiesen und die Adressen für sonstige, nur in Mega128 vorhandene Register-Adressen vorhanden.
      Im Mega 103 gibt es nur dessen Register. Okay, meine Konzentration ist nicht mehr wie früher. Die Def-Datei für m128 kann unverändert bleiben, macht kein vermutetes Problem.

      Bedeutet, dieses Thema kann abgeschlossen werden.
      Werde mich nun mit original m128def.dat wieder dem Bootlader für Mega128 zu wenden. Es macht zumindest Sinn, nicht immer einen ISP Programmer benutzen zu müssen, für diverse Projekte. Der Mega2560 hat ja einen Arduino Bootlader der per Bascom mit gewisser Einstellung im Programmer zu bedienen ist. (Ich vermute Arduino mit STK500V2 Version.)
      Entsprechende Hinweise, Informationen zum Thema Bootlader vermisse ich im Abschnitt Lexikon.
    • Weil die Frage da war, ob man jedem AVR ein Bootloader verpassen kann, lautet die Antwort ja, aber auch nein.

      Ja heißt, man kann einen Bootloader schreiben und praktisch an jede Stelle im ROM plazieren.
      Nein heißt,wenn der Controller von sich aus nicht schon Selfprogramming unterstützt, kann auch nichts geflashed werden.

      Der Tiny48 z.B. kann selfprogramming und daher habe ich ihn für einen kleinen Democode hergenommen.

      Da im Datenblatt keine Angabe war, wo denn der Bootbereich im Flash liegt, habe ich einfach eine Adresse angenommen, ausgehend vom Flashende weg, damit der Bootloader noch reibpasst und die Loader-Adresse halbwegs gerade ist.

      Ein Vektor kann man auch nicht umstellen, damit man durch einen Reset im Bootloader direkt landet. Das muss man dann von einer Applikation aus machen.

      Also von vorne.

      Der Bootloader soll an Adresse $780 angesiedelt sein.
      Also ergibt sich folgender Code mit Angabe $Loader=&h780 mit Option BootOnly.

      BASCOM-Quellcode: Bootloader.bas

      1. ' Bootloader für Tiny48 an fast beliebiger Adresse
      2. $Regfile = "attiny48.dat"
      3. $HWStack = 20
      4. $SWStack = 20
      5. $Framesize = 26
      6. $Crystal = 1000000 ' int. RC-Oszillator
      7. $Loader = &h780 , BOOTONLY ' Bin-Datei ab $780 erstellen
      8. Disable Interrupts
      9. LED Alias PortC.2 ' Testsignal
      10. Config LED = Output
      11. Dim count as Byte
      12. ' LED blinkt mehrmals um den aktiven Bootloader anzuzeigen
      13. For Count = 1 to 50
      14. Toggle LED
      15. Waitms 100
      16. Next Count
      17. ' Bootloader wird beendet
      18. Reset LED ' LED aus
      19. Goto _Reset ' Applikation starten
      Alles anzeigen

      Die Option BootOnly bewirkt, dass das compilierte Bin-File nicht ab Adresse $0 beginnt, sondern mit der angegebenen Boot-Adresse bei $780.

      Das ist wichtig, damit man den Bootloader in der Applikation gleich mit einbinden kann.

      BASCOM-Quellcode: Applikation.bas

      1. ' Applikation für Tiny, die den Bootloader bereits beinhaltet
      2. $Regfile = "attiny48.dat"
      3. $HWStack = 20
      4. $SWStack = 20
      5. $Framesize = 26
      6. $Crystal = 1000000 ' int. Oszillator
      7. LED Alias PortC.4
      8. Config LED = Output
      9. Dim Count as Byte
      10. ' Hauptprogramm
      11. Do
      12. Incr Count
      13. Toggle LED
      14. Waitms 500
      15. If Count = 20 then ' nach 10s Bootloader starten
      16. Goto Bootloader ' Bootloader aktivieren
      17. End If
      18. Loop
      19. ' Bootloader mit $INC mittels .org an die selbe Adresse einbinden,
      20. ' für die der Bootloader compiliert wurde.
      21. !.org $780 ' Das war die Loader-Angabe
      22. $INC BootLoader , nosize , "Bootloader.bin" ' Bootloader binär einbinden
      Alles anzeigen
      Der Bootloader wird am Ende der Applikation mit der $INC-Anweisung binär eingebunden.
      Damit die Adresse auf der des Bootloaders entspricht, habe ich ein
      !.org $780
      davor gesetzt. Das sagt dem Compiler, dass ab dieser Adresse der nachfolgende Code einzubinden ist.

      Das Ergebnis ist dann eine Applikation, die bereits den Bootloader beinhaltet.

      Da es kein Boot-Vector gibt (Reset-Vector = Boor-Vector), kann man auch nicht direkt durch ein Reset in den Bootloader gelangen.
      Das muss dann in der Applikation erfolgen. Hier im Beispiel blinkt eine LED in Sekundentakt und nach 10 Sekunden wird der Bootloader aufgerufen.

      Der Bootloader lässt eine andere LED blinken, aber 5x pro Sekunde (50x), dann ist der Bootloader fertig mit seiner Arbeit und startet mit Goto _Reset wieder die Applikation.

      Nachteil
      Wenn das Programm defekt ist, kann auch per Software der Bootloader nicht mehr aktiviert werden.
      Abhilfe könnte hier ein externer Pin sein, der ein Interrupt auslöst (INTx, PCINTx), den man zur Aktivieren des Bootloaders verwendet.

      Ansonsten läuft das Programm im Simulator wunderbar.

      Übrigens ist das jetzt nicht an den Tiny gebunden. Man kann das auch mit einem Mega ausprobieren.
      Allerdings darf der Reset-Vector nicht als Boot-Vector eingestellt werden.
      Und die Adresse für den Bootloader muss natürlich beim Bootloader und in der Applikation übereinstimmen, kann aber variiert werden.

      Vielleicht bringt das den einen oder anderen auf eine tolle Idee ?
    • Danke für deinen zwischenbericht und Anregung!

      Ich habe mittlerweile "Erfolgserlebnisse" mit meinem Bootlader für den Atmega128.
      Habe zuerst den Bootlader mit ISP Programmer auf den Mega128 geladen.
      Dann ein kurzes Testprogramm geschrieben in dem eine LED im Sekundentakt blinkt.
      Das habe ich mit dem MCS Bootlader auf den Mega128 per Bootlader rein geladen.
      Und siehe da, LED blinkt! Bedeutet: Bootlader funktioniert.

      Habe versuche mit $Prog im Blinkprogramm zu erkennen, ob und wann es sinngemäße Fehlermeldungen gibt.
      Geschickt habe ich einmal $PROG &HFF,&HFF,&HFA,&HFF und einmal $PROG &HFF,&HFF,&HFD,&HFF


      Darauf hat der MCS Bootlader jedesmal das gemeldet:
      Sending Init byte
      Loader returned : 123
      Uploading...
      Error : -6006
      Finish code : -6006

      Was das bedeutet, versuche ich zu ermitteln.
    • bitlogger schrieb:

      Ich habe mittlerweile "Erfolgserlebnisse" mit meinem Bootlader für den Atmega128.
      Habe zuerst den Bootlader mit ISP Programmer auf den Mega128 geladen.
      Ja das macht man so mit ISP.

      bitlogger schrieb:

      Dann ein kurzes Testprogramm geschrieben in dem eine LED im Sekundentakt blinkt.
      Das habe ich mit dem MCS Bootlader auf den Mega128 per Bootlader rein geladen.
      Und siehe da, LED blinkt! Bedeutet: Bootlader funktioniert.
      Gratulation!


      bitlogger schrieb:

      Geschickt habe ich einmal $PROG &HFF,&HFF,&HFA,&HFF und einmal $PROG &HFF,&HFF,&HFD,&HFF


      Darauf hat der MCS Bootlader jedesmal das gemeldet:
      Sending Init byte
      Loader returned : 123
      Uploading...
      Error : -6006
      Finish code : -6006

      Was das bedeutet, versuche ich zu ermitteln.
      Da kann ich dir nur teilweise Info geben.
      Das MCS-Programm (Uploader) sendet den Ascii-Code 123 um dem Bootloader anzuzeigen, dass ein Programm übertragen werden soll.

      Das kommt auch beim Bootloader an, der das zurück sendet.

      Daraufhin versucht der Uploader zu übertragen (Uploading...), was aber fehl schlägt.

      Dass der Bootloader aber offensichtlich zuvor funktioniert hat, kanns eigentlich nur an den Fuse bzw. Lockbits liegen.

      Dazu solltest du dir jedes eintelne Bit ansehen, was das Bewirkt.

      Vielleicht gibts in der Bascomhilfe etwas Info, was die Fehlercodes (-6006) bedeuten.
    • Habe tatsächlich in der Hilfe was gefunden (Suche nach "mcs-bootloader")

      Hier die Error-Codes:

      ERROR CODES
      -6001 - Bad format in file name
      -6002 - file not found
      -6003 - file not found in folder
      -6004 - folder not found
      -6005 - canceled
      -6006 - time out
      -6007 - protocol error
      -6008 - too many errors
      -6009 - block sequence error
      -6016 - session aborted

      Der Bootloader muss nach jedem Block ein ACK oder NACK senden.
      Das kommt wohl nicht mehr zurück.

      Ich vermute, die Werte können nicht in den Flash geschrieben werden, Programm bleibt bei WritePage wohl stehen.

      Daher Timeout und der Fehler -6006

      Liegt wohl an den Fuse- und Lock-Bits.