Bootloader stoppt Mikrocontroller

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • $prog &HEC , &HFF , &HDC , &HFC

      Mitch64 wrote:

      stimmt die von dir im Programm angegebene Bootadresse nicht mit dem überein, was in den Fusebits eingestellt ist.
      Weshalb? FuseHigh =$DC (1101 1100) Bootsz1 High , Bootz0 Low = Bootladeradresse 1FC00
      Die lockbits verhindern ein vergleichen ob richtig gebrannt wurde, aber können sie verhindern das der Bootloader "brennt"?
    • Okay Mitch64, das mit den per $Prog gesetzten Fuses für Atmega 2561 dürfte ein Problem sein.
      Ich habe nur einen Atmega 128 und bei meiner Untersuchung, warum der MCS Bootlader für diesen Prozessor nicht funktioniert,
      habe ich was ganz anderes entdeckt.
      Am Anfang des Programmes wird der Stackpointer auf 1FFF gesetzt, und etwas später das Register PINE angesprochen.
      Nur weisen die entsprechenden Registeradressen die Werte für den Atmega103 an. Nicht für Atmega128!

      Nun, MCS ging wohl davon aus, Anwender belassen die ab Werk gesetzte Fuse für den Kompatibilitätsmodus, also Werte für Atmega 103.
      Ich habe jedoch die Fuse auf den Atmega 128 gesetzt, jedoch werden die entsprechenden Register-Adress-Unterschiede nicht berücksichtigt.
      Ich wüsste nicht, wie ich welche Bootlader-Anweisung so ändern müsste, dass die richtigeren Registeradressen bedient werden.
      Hat jemand entsprechende Tipps, oder einen Bootlader für einen richtig gefusten Atmega 128?
      Bzw einen Bootlader für den Atmega 128, der dann auch die "passenden" Registeradressen bedient.
    • bitlogger wrote:

      Okay Mitch64, das mit den per $Prog gesetzten Fuses für Atmega 2561 dürfte ein Problem sein.
      Ob das das Problem ist, kann man erst sagen, wenn man den Fehler ausschließen kann, also %Prog remmen und die Einschränkungen in den Fuse- und Lockbits wieder rausnimmt. Und am besten raus lässt, bis der Bootloader funktioniert.

      Wenn das der Fehler ist, ist alles klar, wenn nicht, dann hat man die Sicherheit, dass es daran nicht liegt. Dann muss man weiter schauen.

      So ist meine Vorgehensweise bei der Eingrenzung von Fehlern, die man nicht direkt fix machen kann.

      bitlogger wrote:

      Ich habe nur einen Atmega 128 und bei meiner Untersuchung, warum der MCS Bootlader für diesen Prozessor nicht funktioniert,
      habe ich was ganz anderes entdeckt.
      Ich weis nicht, ob man anstelle eines 2561 einfach einen 103/128ger nehmen kann. Nach Datenblatt das mir vorliegt, sind da die Controller 640, 1280, 1281, 2560, 2561 zusammen gefasst. Ich interpretiere daraus, dass die funktionstechnisch relativ gleich sind. Dennoch gibt es Unterschiede in Flaschgröße, EEPromgröße und entsprechend bei den Bootloader Adressen.

      Für meine Test würde ich daher also einen dieser Controller nehmen. Zufällig gibts den Arduino-Mega mit den 2560 drauf, den wohl viele zu hause zum experimentieren haben. Der würde sich hier anbieten.

      bitlogger wrote:

      Nur weisen die entsprechenden Registeradressen die Werte für den Atmega103 an. Nicht für Atmega128!
      Wenn der Controller 2 Modis beherrscht, dann würde ich aus dem Bauch raus auch den Controller in $Regfile angeben, dessen Mode ich benutze.
      Also entweder
      $Regfile = "m128def.dat" oder
      $Regfile = "m103def.dat" angeben.


      bitlogger wrote:

      Hat jemand entsprechende Tipps, oder einen Bootlader für einen richtig gefusten Atmega 128?
      Bzw einen Bootlader für den Atmega 128, der dann auch die "passenden" Registeradressen bedient.
      Schau mal im Verzeichnis "Samples\Boot" nach. Da finden sich mehrere für den 128ger, unter anderem auch dieser: Bootloader.bas
    • So ähnlich gehe ich bei Untersuchungen auch vor. Einen Arduino 2560 habe ich zwar, nur keine Lust, den dortigen Arduino Bootlader zu crashen.
      Richtig, die Atmegas der Baureihen auf den jeweiligen Datenblättern sind ziemlich baugleich, verwenden die selbe Peripherie etc.
      Nur gibt es diverse Unterschiede in den Adressbelegungen, die zu berücksichtigen wären.

      Nun, Du hast mich auf ne Idee gebracht. MCS hat die mega128def.dat wohl deswegen auf die gleichen Werte wie der m103def.dat gesetzt, weil der M128 ab Werk die Fuse 103 gesetzt bekam. Ein Blick in die jeweiligen def.dat, bestätigt dies. Nun könnte ich einfach die Werte in m128def.dat so anpassen, dass sie für die m128 Registerbelegung passen. Sollte funktionieren.
      Nur habe ich dann das Problem, ich müsste das in jeder Bascomversion etc tun. Eine gewisse Unsicherheit bei Updates etc bliebe dann. Oder ich ändere den Dateinamen in m128_echtdef.dat.
      Dann jedoch ist es nicht mehr Bascom-Konform, müsste ich jeweils beachten. Wenn Mark sowas offiziell anbietet, wäre es richtiger.
      Mark kompensiert mit seiner Methode gewisse Fehler die Atmel gemacht haben, und die man nur kennen lernt, wenn es Probleme gibt. Ein Mega128 ist ab Werk kein Mega128 sondern ein Mega103.

      Zurück zum Thema des Threaderstellers. Die $Prog Anweisung sollte erst gesetzt werden, wenn der Bootlader funktioniert.
    • bitlogger wrote:

      Nun könnte ich einfach die Werte in m128def.dat so anpassen, dass sie für die m128 Registerbelegung passen. Sollte funktionieren.
      Nur habe ich dann das Problem, ich müsste das in jeder Bascomversion etc tun.
      Mache einfach eine Kopie von der originalen DAT-Datei und gib ihr einen eigenen Namen, z.B. "m128_modified.dat".
      In der kannst du dann fummeln wie du willst.

      Im Programm dann eben die geänderte Datei einbinden.

      Wenn ich eigene Lib's schreibe, habe ich auch ein ähnliches Problem.
      Da liegen dann die einenen Libs und die von MCS im gleichen Ordner. Und wenns ein Update gibt frage ich mich immer, welche sind die von MCS.

      Ich habe dazi eindach im Lib-Verzeichnis einen weiteren Ordner angelegt, der ebenfalls Lib heist. Und dort liegen meine und modifizierte Libs drin.

      Einbinden dann mit
      $Lib "Lib\Libname.lib"

      Den Pfad mit angeben!

      Das gleiche sollte auch mit $Regfile funktionieren

      $Regfile="MyDat\Datfile.dat"

      bitlogger wrote:

      Zurück zum Thema des Threaderstellers. Die $Prog Anweisung sollte erst gesetzt werden, wenn der Bootlader funktioniert.

      Da stimme ich zu.
    • Tja, wäre zu schön wenn es so einfach wäre, die def.dat anzupassen. Habe die Bereiche IO mit den Adressen der Teile für Atmega103 auf Adressen für M128 angepasst. Datei den Namen gegeben den Du vorgeschlagen hast. Nach erstem compilen der angepassten Originaldatei Bootlader.bas kam ein Error 330. (Out > 3F)
      Suchte in Def.dat nach Out, fand nichts. Auch nichts, was vermutlich den Adressbereich für IO Register etc einschränkt.
      Also Error330 ignorieren lassen, compiliert. Funktionierte.

      Hex in Mega128 geladen etc. Im Disassembler wurde jedoch sichtbar, der Stackpointer wird nicht mehr gesetzt. Zu erwarten gewesen wäre ein SER 24, Out 0x5D,R24 anstatt das Out 0x3D,r24. Einige andere Dinge vom neuen Registeradressbereich zwischen 3F und 00 die auf 5F bis 20 gelten sollten, werden nicht wie erwartet bedient.

      Falls jemand weiß, warum das so einfach nicht zu ändern ist, bitte ich um Info etc.
      Werde nun die m103def.dat und m128def.dat genauer auf Unterschiede vergleichen, vielleicht fällt mir dann einiges auf.
    • bitlogger wrote:

      Habe die Bereiche IO mit den Adressen der Teile für Atmega103 auf Adressen für M128 angepasst.
      Hast du die beiden Datenblätter man angeschaut?
      Soweit ich verstehe, kann man nur den 128ger in den Mode vom 103er zurückversetzen.
      Der Speicher ist bei beiden gleich groß. Warum sollte also beim 128ger der Stack wo anders liegen?

      Der sogenannte Backward-Compability-Mode hat aber seine Grenzen.
      Schau mal hier, was da steht zum Bootloader-Support. Das wird der Grund sein, warum es bei dir nicht funktioniert.
      Bildschirmfoto vom 2022-05-29 14-39-20.png

      Bootloader not supported!
    • Anscheinend habe ich mich nicht klar verständlich ausgedrückt.
      Der M128 wird von Atmel mit gesetztem Fusebit m103 geliefert. Ist kein echter M128.
      Mark hat deswegen in seiner m128def.dat die Adressen für den IO Bereich von 5F bis 20 auf die Adressen 3F bis 00 angepasst.
      In dem Doku für Atmega128 ist erkennbar in der Register Summary unterhalb von $60 sind zwei Eintäge zu sehen.
      $3F ($5F) Name Sreg usw. 3F gilt für den M103, 5F gilt für M128.

      Also habe ich in m128def.dat den Wert für Sreg von den dort eingetragenen 3F auf 5F geändert, und für diese Werte in ().
      Nun wäre zu erwarten, wenn der Stackpointer in einem Programm mit geänderter m128_modified.dat bedient werden soll, dass dann anstatt wie sonst die
      Anweisungsfolge SER R24, Out 0x3d,R24 folgendes stehen sollte: SER R24, Out 0x5D,R24.

      Für den M128 gilt die Adresse des Sreg = 5F und nicht 3F! Ebenso andere Registeradressen im Bereich 5F bis 20.
      Zu erwarten wäre nach compilieren mit m128_modified.dat dass z.B dem Stackregister die Werte 5D für SPL und 5E für SPH zugewiesen werden.
      Estaucht jedoch keine dementsprechende Zuweisung (momentan) auf.

      Schau Dir bitte die Register Summary genauer an. Dort sind nur Unterschiede im Bereich 5F bis 20 zu erkennen. Somit sollten diese Werte angepasst werden, damit diese Register passend bedient werden können. Die Werte für den M103 passen nicht für den M128, weil es ab Adresse 3F Überschneidungen, krasse wechsel der Register gibt.
      Die Register die fürs Bootladen benötigt werden, z.B. SPMCSR liegen außerhalb des unterschiedlichen Bereiches 5F-20; 3F-00. Somit dürfte es keine Einschränkung für Bootloader geben.

      Fazit: der Mega128 ist in der m128def.dat zu einem Mega103 zwangsweise mutiert worden. Es gibt somit keinen "echten, echt nutzbaren" Mega128 wegen der m128def.dat.
      Klar hätte Mark das schneller angepasst, eine bessere M128def.dat unter angepasstem Namen generiert, weil er genau weiß, was da anzupassen ist.
      Ich vermute, Six könnte das wahrscheinlich ähnlich gut anpassen. Ob andere Foren-Profis das ebenso könnten, anbieten?
    • Ertmal Danke für das viele Feedback zu meinem Problem und es tut mir leid, dass ich erst heute wieder Antworte.

      Zu den Lock und Fuse Bits ich setzte sie nur weil der Bootloader ja an sich funktioniert hat (nur halt mit dem alten Programmer). Ich habe natürlich auch schon versucht die Lock Bits nicht zu setzten und den Bootloader hochzuladen, leider mit dem selben Problem das die erste Anweisung die den Programcounter (jmp) verändert dazu führt das sich der Mikrocontroller aufhängt. Es ist auch kein einfaches Aufhängen, da nicht einmal der Watchdog den Mikroconroller resettet kann.
      Wenn ihr nochmal in den ersten Post schaut habe ich einen Testcode noch drinnen der einen Port schaltet (welcher einen Led einschaltet) danach einen waitms ausführen sollte und danach einen anderen Port (LED) schaltet. In dieser Version kommt der MC genau bis zum waitms also er schaltet die erste LED ein und bleibt danach bei der waitms Anweisung hängen.

      Zu dem Thema einen andern MC zu verwenden: Es wäre möglich den ATMega128 zu verwenden (entsprechende änderungen wurden schon am Programm vorgenommen) jedoch wollen wir das Produkt weiter mit dem ATMega2561 führen um noch platz für zukünftige Änderungen zu haben und nicht 2 Versionen führen zu müssen, da wir sonst darauf vertrauen müssten das Kunden die Richtigen .bin Files auf ihre geräte laden, wenn ein Update rauskommt. Auch haben wir noch über 100 Platinen mit dem ATMega2561 auf lager.

      Zum ablauf des Bootloaders: Wir führen mehrere Produkte mit ATMega128 und ATMega2561, der Bootloader wurde für die ATMega128 entsprechend angepasst und funktioniert ja auch ansicht so wie er es soll. Nur mit dem neuen Programmer haben wir ein Problem, dass das Hochladen auf den ATMega2561 zwar funktioniert, aber das Program nach dem hochladen haufängt sobald der Programcounter ausertürlich verändert (sprich jmp). Solange der Programcounter nur um 1 erhöht wird wie es normalerweise der fall ist läuft das Program ohne Probleme.

      Pluto25 wrote:

      Weshalb? FuseHigh =$DC (1101 1100) Bootsz1 High , Bootz0 Low = Bootladeradresse 1FC00
      Weil dass die Fuse Einstellung ist, die den Bootloader an die Adresse 1FC00 setzt, also einen Bootloader mit der größe von 1024 word ist und den Bootvector an die Bootloaderadresse bindet. Die restlichen Einstellungen sind laut meines Vorgängers so gewollt und sollen nicht verändert werden und wie bereits mehrfach erwähnt, wenn der alte Programmer verwendet wird funktioniert der Bootloader normal und tut was er soll.
      Bedeutet:
      OCD und JTAG Disable
      Serial Download
      Watchdog über Software
      EEPROM löschen wenn chip löschen

      Das einzige was mir jetzt noch zum Thema aufgefallen ist, ist dass BASCOM bei der Bootsize 1024 als Adresse $FC00 angibt statt $1FC00, sollte aber nur ein Ausgabefehler von BASCOM sein da der MC ja selbset wissen sollte wo der Bootloder startet, wenn die Fuse Bits für den Bootloader auf 10 gesetzt werdern.

      Leider hab ich heute ein neues Projekt bekommen, bedeutet ich werde die nächsten 2-3 wochen nicht mehr an diesem Problem arbeiten können. Würde mich trotzdem freuen, wenn noch ihr mich weiterhin dabei unterstützt mein Problem zu lösen.
      Soll ich den ersten Post anpassen, sodass bereits besprochene Lösungsversuche dort aufscheinen?
    • Das "Weshalb" bezogt sich auf angeblich falsche Adresse.

      Prepe wrote:

      dass BASCOM bei der Bootsize 1024 als Adresse $FC00 angibt statt $1FC00
      Vielleicht nicht nur ein Ausgabefehler. Ist erkennbar welche Stackadressen es vergibt? Wenn die auch teilweise daneben liegen würde das den Fehler erklären. Setzt der neue Programmer die Fuses richtig?
      Villeicht mal die Locks nicht setzen um auszulesen wo der neue was vermasselt.
    • @Pluto25 also laut Programmer würde der Code bei Adresse 3F800 den ersten Byte schreiben, was wenn ich es von Byte in Word umrechne 1FC00 sein sollte.
      Da ich auch immer mit Erase and Prog chip arbeite, wird der MC auch immer resettet bevor ein neuer Bootloader hochgeladen wird, was auch die $prog Anweisung irelevant macht ob ich die immer setzte oder nicht da vor dem Programmieren die Lock Bits auf FF gesetzt werden und der Flash auf jeden fall leer ist.

      Außerdem sollte die Ausgabe von BASCOM egal sein, da der MC die Adressen vordefiniert hat und die Fuse bits Steuern welche Adresse gewählt wird. Soweit mein wissen mich nicht täuscht sollte der Programmer nur die Bits setzten und keinerlei Daten übertragen welche den MC umprogrammieren, demnach ist die Ausgabe der Adresse flasch in BASCOM referenziert, wahrscheinlich etwas im m2561def.dat file.

      Wobei wenn ich so darüber nachdenke die m2561def.dat wird mit BASCOM mitgeliefert oder? Nicht das mein Vorgänger das file selbst vom m128def.dat abgewandelt und eingebunden hat. Hab schon so einen Fail von ihm bei den Platinenbaublänen gefunden. Er hat den Vorgefertigten MC vom ATMega128 genommen und als ATMega2561 gespeichert, deswegen ist bei jedem ATMega2561 der OC0B Pin mit dem VCC verbunden, weil der beim ATMega128 auf den PEN Pin mapped.
    • Prepe wrote:

      da vor dem Programmieren die Lock Bits auf FF gesetzt werden
      Und da würde ich sie stehen lassen um später auslesen zu können was der Neue falsch schreibt. Sobalt sie FC sind ist das nicht mehr möglich.

      Prepe wrote:

      sollte die Ausgabe von BASCOM egal sein
      Die kann nicht egal sein. Bascom muß ganz präzise die rchtigen Adressen kennen, sonst führen Spünge ins Nirwana. Wenn bascom denkt der Code würde in FC00 geladen kann er nicht funktionieren wenn er woanders geladen wird. Schreib mal versuchsweise den selben Code an beiden Stellen (FC00 und 1FC00)
      vermutlich läuft er dann.
      Nur zum Verständniss. Die Platinen mit dem 2561 funktionieren mit dem alten Programmer, mit dem neuen nicht? Das kann kein Bascom Fehler sein? Oder ist die Platine der Programmer und hat einen anderen Chip bekommen?
    • Genau wie Pluto sagt ist es.

      Die Fuse-Bits geben die Adresse vor, an die der Bootloader geschrieben werden muss. Entsprechend ist auch $Loader einzustellen.
      Und wenn der Controller beim Flashen resettet wird, bleiben die Fise und Lockbits davon unberührt.

      Damit du deinen Fehler finden kannst, musst du also die die Anweisung $PROG auskommentieren und manuell in den Fuse- und Lockbits alles einstellen, damit du keine Sperren mehr drin hast. Dann kannst du den geflashten code auch verifizieren lassen, ob der mit dem zu brennenden Programm übereinstimmt.

      Vielleiucht ist da schon das Problem.

      Wenn du nix verifizierst, kannst du nicht sichergehen, dass der Flashinhalt so ist, wie im Compilat.

      Wenn es dann funktioniert, kannst du ja dein $Prog wieder rein machen und sehen, ob es dann ommer noch funktioniert.

      Mir ist auch nicht klar, in welcher reihenfolge geflashd und die Fuses gesetzt werden.
      Ich würde annehmen, dass zu erst geflashd wird und ganz zum Schluss (nach verifikation, wenn eingeschaltet) die Fuses gesetzt werden.
      Aber das weis ich nicht.
    • Pluto25 wrote:

      Die kann nicht egal sein. Bascom muß ganz präzise die rchtigen Adressen kennen, sonst führen Spünge ins Nirwana.
      Aber das würde ja bedeuten dass der Programmer zusätzlich zu den Fuse Bits daten übertragen würde, was sinfrei wäre weil dadurch die Angaben im Datenblatt für die MC egal wären da ich den Bootloader platzieren kann wo ich will.
      Sogesehen könnte ich dan auch sagen hey mein Bootloader ist nur 560 word groß also reserviere ich nur so viele Words für den Bootloader das keine ungenutzten Words für den Bootloader reserviert werden und den Bootvector setzte ich dann auch noch genau auf den Anfang vom Bootloader da der ja nicht auf einem vordefinierten Adresse liegt (1FE00, 1FC00, 1F800, 1F000).
      Die Fuse Bits definieren welcher Bereich der Bootloader besetzt und wo er startet. Und der Bootvector gibt an von wo gestartet wird also ob bei Adresse 0 oder beim angegebenen Bootloader gestaretet wird und diese Adressen sind im MC gespeichert und können meines wissens nach nicht verändert werden. Wenn ich die Fuse 10 wähle sage ich dem MC das der Bootloader 1024 Words reservieren soll (11 = 512, 01 = 2048, 00 = 4096) und der Bootvector bei der Startadresse 10 legen soll wobei 10 intern auf 1FC00 Zeigt wegen den Fuse Bits 10 würde ich 11 wählen würde ich sagen der Bootloader muss nur 512 Words reservieren und der Bootvector liegt bei 1FE00. Würde BASCOM jetzt dem MC umschreiben können, weil der Bootvector bei FC00 liegt da die Ausgabe das so angibt, würde mir das den MC doch schrotten.
      Da aber der Flash richtig geladen wird und der Bootlader bei Adresse 1FC00 (3F800 in Byte) startet sollte der MC doch den richtigen Bootvector ansprienen da die Fuse 10 gesetzt ist.

      Pluto25 wrote:

      Wenn bascom denkt der Code würde in FC00 geladen kann er nicht funktionieren wenn er woanders geladen wird. Schreib mal versuchsweise den selben Code an beiden Stellen (FC00 und 1FC00)
      Das hab ich schon versucht und ich habe immer noch das selbe Problem, das die erste jmp Anweisung den MC crashed, oder was auch immer dabei passiert.
      Es war auch einer meiner ersten Versuche den Bootlader an FC00 statt 1FC00 zu schreiben, leider ohne erfolg. Ich hab auch schon den Bootloader an 00000 geschrieben und den Bootvector auf 00000 gelassen, auch ohne erfolg.

      Wenn ich den MC prüfe nach dem programmieren bekomme ich diese Meldungen
      Beim Prüfen auf Leer: Chip not empty at bytes address : 3F800 with value 8F
      Beim Prüfen ob Flash den Buffer entspricht:
      - Verified OK
      - Buffer read
      - STK500 V2 detected

      Leider kann ich keine Bilder hochladen da ich sonst die Fehlermeldung: maximal 10.000 Zeichen erhalte

      The post was edited 1 time, last by Prepe: zusätzliche Info ().

    • Nun, hier wird im Kreise gesprochen, sich nur auf gewisse Theorie verständigt, geeinigt. Ich hatte nach so einer Platine gefragt. Frage nun auch nach dem von Dir, bzw Euch verwendeten Programmer. Habe dein Programm mangels 2561 mit einem 128 untersuchen wollen. Geht nicht, weil Programm zu groß, angeblich nicht rein passt.
      Okay, ich war früher (zu Z80 Zeiten, etc) Profi mit entsprechendem Equipment. Lange her, und andere Hardware (CPU).
      Mich wundert, dass dieser Bootlader nicht in einen Mega128 passen sollte, obwohl das Grundgerüst ziemlich ähnlich den üblichen MCS Bootladern ist. Es kam da nur gewisse Überwachung per LED hinzu, die normalerweise überflüssig sein sollte. Verstehe nicht, wieso ihr einen Programmer verwendet der scheinbar unsicher, unzuverlässig ist. Grundvoraussetzung für gewisse Sicherheiten sind zuverlässige Geräte, Programmer etc. Welcher Bootlader war denn die Basis, ist erweitert worden und warum genau?
    • Prepe wrote:

      Bootvector bei der Startadresse 10 legen soll wobei 10 intern auf 1FC00 Zeigt
      Wir sprechen aneinander vorbei. Der Code vom Bootlader muß wissen wo er hin soll: Auch wenn sein Start noch stimmt so wird er im Code dahin springen was sein ursprüngliches zu Hause war. Wenn der Code in FC00 zu Hause war kann er nicht in 1FC00 laufen weil der erste Sprung im Code nach 0FCxy springt nicht nach 1FCxy.

      Prepe wrote:

      Verified OK
      Klar der neue ließt ja seinen eigenen Mist zurück. Was sagt der alte dazu? Bzw welcher Unterschied ist in den ausgelesenen bin zwischen beiden? Oder vielleicht einfacher: ist (mit dem neuen gelesen) ein mit dem alten Beschriebener Chip auch "Verified OK"?

      PS Wenn der Watchdog in den Fuses eingeschaltet wird kann er nicht beim Absturz versagen.
      PPS Warum steht an 3F800 etwas? Hatte er keine Lust mehr den Rest zu löschen :D

      bitlogger wrote:

      Grundvoraussetzung für gewisse Sicherheiten sind zuverlässige Geräte
      Sind Bootlader und Updates zu unterlassen. :thumbdown: :D ;)

      The post was edited 1 time, last by Pluto25 ().

    • Habe eben nochmal einiges überflogen, nach geschaut in Datenblatt etc. Da das Programm von Prepe auch in einen Mega128 passen müsste, habe ich es erneut versucht.
      Programm ist im Mega128 und funktioniert auch. Ich habe jedoch alles überflüssige wie diese LED Angelegenheiten und Modulangelegenheiten auskommentiert.

      Beim bootladen eines Programmes per MCS Bootlader kam dann folgender Hinweis:
      Sending Init byte
      Loader returned : 123
      Uploading...
      Error : -6008
      Finish code : -6008

      6008 hat Mitch64 verständlicher gemacht. Nun, was könnte in dem Bootlader von Prepe (ohne LED und Modul- Bearbeitung) solcherlei Meldung auslösen?
      Werde ich versuchen zu analysieren. (Werde noch nachschauen, welche Version ich benutzt habe, von dem was Prepe an Listings geliefert hat)
      Hier nur Vorabinfo. Übrigens, Bootlader wurde über einen originalen Atmel-Programmer eingespielt.