ich habe ein Board in den ich den Atmega 1284P und 644P einsetze, die wiederum einen Bootloader, der über CAN Bus bedient wird.
Soviel dazu. Das Board mit dem Atmega644p funktioniert einwandfrei mit dem Bootloader.
Jetzt habe ich mich mal wieder an die Bestückungsvariante mit dem 1284p ran gemacht, da ich den Bootloader nicht zum laufen bringe. Aus versehen habe ich den Bootloader vom 644 aufgespielt und schon meldet er sich.
Der Bootloader ist 512 Word groß.
So jetzt das Interresante wo ich langsam glaube, dass der Hardwaremäßig einen becker hat, oder ich was einfach übersehe.
Wenn ich den Bootloader an die Addresse 0xFC00 spiele wie am 644p obwohl es ein 1284p ist meldet sich der Bootloader und will Programieren. Klar das Programmieren geht schief.
Was auch interresant ist, egal wie ich die Bootloader BOOTSZ setze meldet sich der Bootloader trozdem.
Es handelt sich defenitiv um einen 1284p verlötet und das meldet auch das AVRStudio.
Die Fuses:
LFUSE: 0xF7
HFUSE; 0xD6
EFUSE: 0xFC
Ich habe das ganze auch überprüft und ausgelesen.
Mache ich da einen denkfehler zweck den 64k Flash und addressierung?
Als Startaddresse habe ich für den Bootloader am:
644p: 0xFC00 => --section-start=.text=0xFC00
1284p: 0x1FC00 (laut datenblatt ist es bei 512 Word 0xFE00 * 2)
=> --section-start=.text=0x1FC00
Gut wenn das so ist das beim Atmega1284 am ende des ersten 64k blocks der Bootloader steht dann ist nur noch der Fehler zu finden warum der Bootloader die Application nicht schreibt, weil 24k sollten doch gehen da muss er ja noch nicht umadressieren auf den zweiten Addressblock (16bit).
1
avrdude: AVR device initialized and ready to accept instructions
Bitte nur Konstruktive Beiträge - Kritik hilft nur dem der Sie gibt =>
da er sein Ego stärken will.
Nein. Kritik hilft auch dem, der zu dumm ist, zu erkennen, dass es zur sinnvollen Beantwortung der Frage unerlässlich ist, zu wissen, um welchen Bootloader genau es sich handelt.
Zumindest könnte diese Kritik helfen, wenn der Delinquent zwar derzeit noch so dumm, aber immerhin lernwillig ist.
na dummheit ist eine frage des betrachters.
Dummheit ist eine Beleidigung und damit stellt man sich über den anderen und meint man ist besser als der andere und unfehlbar -> nur fürs Ego.
So hier geht es um etwas sachliches!
Es ist doch irrelevant, um welchen Bootloader es sich handelt es ist ein teil selbst geschriebener auf der bassis vom Kreativen Chaos. Denn der Code vom Bootloader wird ausgeführt wie in meiner aussführung gezeigt unter der bedinung das als Startaddr die vom 644p verwendet wird.
Es ist doch irrelevant, um welchen Bootloader es sich handelt
Nein, ist es nicht. Punkt.
ist ein teil selbst geschriebener auf der bassis vom Kreativen Chaos
Dann steckt in diesem selbstgeschriebenen Bootloader ganz sicher der Fehler. Wie er sich genau auswirkt, kann man halt erst sagen, wenn man den Bootloadercode kennt. Und natürlich: was man dagegen tun könnte, ausser dem Gemeinplatz: "behebe den Fehler".
Wie wird denn der Bootloader angesprungen?
Wenn sonst nichts im Flash ist ist es praktisch egal in welchem Speicherbereich der BL ist, der Controller geht den Speicher durch, der eben lauter NOPs hat bis er eben zum BL kommt und führt den dann aus.
Ist dieser jedoch außerhalb des BL-Speicherbereichs kann er beim AVR, wenn ich mich nicht ganz falsch erinnere, den Flash nicht beschreiben, er führ also aus aber der Programmspeicher bleibt leer.
In welchem Speicherbereich der BL liegt musst Du sowohl in den Fuses als auch beim Compiler mitteilen.
Den BL kannst entweder aus dem Programm anspringen, brauchst aber die Adresse, die dann bei 2 verschiedenen eben unterschiedlich sein werden, früher hab ich es so gemacht, dass ich den BL per Watchdog angesprungen hab indem ich den Controller in ne Endlosschleife schickte, dann gehts nämlich über die Fuses.
Wenn sonst nichts im Flash ist ist es praktisch egal in welchem
Speicherbereich der BL ist, der Controller geht den Speicher durch, der
eben lauter NOPs hat bis er eben zum BL kommt und führt den dann aus.
Ist dieser jedoch außerhalb des BL-Speicherbereichs kann er beim AVR,
wenn ich mich nicht ganz falsch erinnere, den Flash nicht beschreiben,
er führ also aus aber der Programmspeicher bleibt leer.
Das ist die Situation ausschließlich bei den klassischen ATMegas (um die es hier allerdings tatsächlich geht). Bei klassischen Tinys und allen modernen AVR8 läuft der Hase anders.
In welchem Speicherbereich der BL liegt musst Du sowohl in den Fuses als
auch beim Compiler mitteilen.
Jepp. Und es muß zur Hardware und zueinander passen.
avrdude: erasing chip
avrdude: reading input file CanBootloaderDisplay.hex for flash
with 1020 bytes in 1 section within [0x1fc00, 0x1fffb]
using 4 pages and 4 pad bytes
Dein Bootloader will also nach Byteadresse 0x1fc00 geschrieben werden, und wird es auch. Und deine Fuses sind auch für einen 512-Wort-Bootloader an Byteadresse 0x1fc00 gesetzt. Also läuft der Bootloader aud dem 1284P sauber los.
Ich würde das Prozessorkürzel (also hier m1284p) in den Dateinamen des Bootloaders mit hineinnehmen, um Verwechslungen zu vermeiden.
Wenn du einen m644p-Bootloader auf den 1284p programmierst, der an Byteadresse 0xfc00 anfängt, dann funktioniert das zunächst trotzdem. Der 1284P springt nach einem Reset, wie durch die Fuses eingestellt, an Adresse 0x1fc00. Dort findet er nur gelöschten Flash, also 0xFF. 0xFF ist aber ein NOP-Befehl. Also läuft er weiter bis 0x1ffff, dann zu 0x0000, und dann weiter bis 0xfc00, wo der Bootloader jetzt liegt, und führt den aus.
Datenblatt schon Studiert? Ich denke nicht das du einen Bootloader vom 644p mal so einfach auf einen 1284 geht, da es schonmal ein anderer Controller ist.
Welchen Bootloader hast du? Selber Programmiert?
Ist der CAN im Controller oder über RS232 auf CAN?
Wenn du einen bootloader suchst, probiere den mal, vieleicht hilft es dir weiter:
Danke für die bestätigung Weingut P. mit dem Speicherdurchlauf.
Erstmal ist nichts im Speicher und der Bootloader wird angesprungen durch den Start. Was ja auch immer Passieren sollte, wenn nur er alleine im Speicher rumliegt. Ist es nicht.
Ich starte den MCU und er sollte durch die Bootbit.
Ja das weis ich mit den Fusebits, wie er angesprungen wird habe die Fuse Bits ja schon geschrieben .
Somit währe BOOTSZ = 11 => 512 Word was die Boot Resetaddr: 0xFE00 in wörtern währe.
Dem Compiler teile ich mit wo sich der Bootloader befindet wie auch schon im Eröfnungsartikkel geschrieben mit --section-start=.text=0x1FC00 beim Atmega1284p.
Wie auch im readout.hex zu sehen ist liegt der ganz hinten im flash wie es auch sein soll. Somit sollte er auch bei einem Leeren ATmega auch angesprungen werden. Dies ist nicht der fall.
Den Bootloader springe ich auch an wenn die Firmware aufgespielt ist nach bedarf durch ein Reset.
Es geht hier wirklich um einen Leeren AVR1284p nur mit Bootloader aufgespielt auf die Addr 0x1FC00.
Datenblatt schon Studiert? Ich denke nicht das du einen Bootloader vom
644p mal so einfach auf einen 1284 geht, da es schonmal ein anderer
Controller ist.
Welchen Bootloader hast du? Selber Programmiert?
Ist der CAN im Controller oder über RS232 auf CAN?
Wenn du einen bootloader suchst, probiere den mal, vieleicht hilft es
dir weiter:
Ja danke hab das Datenblat hoch und runter geschaut (kann schon sein das ich was übersehen habe) das Forum ist schon meine aller aller letzte anlaufstelle.
der 644p ist der kleine Bruder vom 1284p mit dem Doppelten an flash/ram/eeprom somit schon. Es ist schon so das der Bootloader auf der Addr vom 644p bzw als 644p compileriert funktioniert!
Den Bootloader habe ich schon sehr lange am laufen auf vielen verschiedenen AVR der Läuft ja prinzipiel nur ist das hier die Startaddr bzw der zweite 64k Flash block wenn der Bootloader sich hier befindet wird er nicht gestartet.
Kurze Zusammenfassung:
Wenn ich den Bootloader in den Speicherbereich größer 64k schreibe wird er nicht gestartet. Der Flash ist sonst komplett leer.
Dies ist mit den Fuse Bits und einem ATmega1284p MCU:
Die Fuses:
LFUSE: 0xF7
HFUSE; 0xD6
EFUSE: 0xFC
Danke für die bestätigung Weingut P. mit dem Speicherdurchlauf.
Erstmal ist nichts im Speicher und der Bootloader wird angesprungen
durch den Start. Was ja auch immer Passieren sollte, wenn nur er alleine
im Speicher rumliegt. Ist es nicht.
Ich starte den MCU und er sollte durch die Bootbit.
Ja das weis ich mit den Fusebits, wie er angesprungen wird habe die Fuse
Bits ja schon geschrieben .
Somit währe BOOTSZ = 11 => 512 Word was die Boot Resetaddr: 0xFE00 in
wörtern währe.
Das ist richtig.
Dem Compiler teile ich mit wo sich der Bootloader befindet wie auch
schon im Eröfnungsartikkel geschrieben mit --section-start=.text=0x1FC00
beim Atmega1284p.
Wie auch im readout.hex zu sehen ist liegt der ganz hinten im flash wie
es auch sein soll. Somit sollte er auch bei einem Leeren ATmega auch
angesprungen werden. Dies ist nicht der fall.
Den Bootloader springe ich auch an wenn die Firmware aufgespielt ist
nach bedarf durch ein Reset.
Es geht hier wirklich um einen Leeren AVR1284p nur mit Bootloader
aufgespielt auf die Addr 0x1FC00.
Für die Wortadresse $FE00 ist 0x1FC00 die Byteadresse, die man dem
Linker in der -section-start Option mitteilen muss.
LG, Sebastian
Also du sagst dem Linker das der das an die Adresse 0x1FC00 Compilieren soll, ist das so richtig?
Gehst du vom .HEX File aus?
Also zum Verständniss , ich sehe den Speicher des Atmels von 0x0000 - 0xffff.
Siehe Seite 30 vom Datenblatt.
Dir ist schon klar das du den vergleich mit .HEX oder SREC datei so nicht machen kannst? Du vergleichst aber schon die ROH Daten , damit du ein Speicherabbild bekommst.
Also Bootloader Programmieren und als BIN Datei den Flash einmal lesen, dann an der gewünschten Adresse kontrollieren ob das drinnensteht was du willst.
Also ab Adress 0xF000 usw. alles andere ist unübersichtlicht.
Der Bootloader liegt schlicht nicht im Bootloaderbereich eines 1284P.
Nichtmal näherungsweise...
Verdammt, ich habe einen Tippfehler beim Suchen gemacht, hier ist die von mir vermisste Zeile:
1
> :020000040001F9
Damit liegt das Ziel schonmal deutlich näher, der Bootloadercode ist also zumindest nicht in den unteren 64k des Flash, wie ich fälschlicherweise angenommen hatte.
ich habe auch tests gemacht und mit absicht den bootloader durch die 64k - 128k bereich geschoben. ohne erfolg.
Aus verzweiflung weil er ja nicht gestartet wird in den vorgesehenen Bootloader bereichen.
Auch die Fuse bits bzw BOOTSZ alle durchzusezten bringt kein effekt wenn der bootloader in den letzten 512 Word liegt (128k - 1k)Flash.
Im 0k - 64k bereich kann er beim ersten start liegen wo er will da wird er angelaufen.
mit absicht vor der addresse 0x1FC00 gelesen (damit klar ist es geht
auch wirklich hier los)
Seite 292 ist es übrigens...
Ich mag keine .HEX Files.
The filename field indicates the name of the file to read or write. The format field is optional and contains the format
of the file to read or write. Format can be one of:
1
i Intel Hex
2
3
I Intel Hex with comments on download and tolerance of checksum errors on upload
4
5
s Motorola S-record
6
7
r raw binary; little-endian byte order, in the case of the flash ROM data
8
9
e ELF (Executable and Linkable Format)
10
11
m immediate mode; actual byte values are specified on the command line, separated by commas or spaces in place of the
12
filename field of the -U option. This is useful for programming fuse bytes without having to create a single-byte
13
file or enter terminal mode.
14
15
a auto detect; valid for input only, and only if the input is not provided at stdin.
16
17
d decimal; this and the following formats generate one line of output for the respective memory section, forming a
18
comma-separated list of the values. This can be particularly useful for subsequent processing, like for fuse bit
19
settings.
20
21
h hexadecimal; each value will get the string 0x prepended.
22
23
o octal; each value will get a 0 prepended unless it is less than 8 in which case it gets no prefix.
24
25
b binary; each value will get the string 0b prepended.
Nim die Option :r wie raw und vergleich dann nochmal. Sollte doch nicht schwierig sein das mit einem Hex Editor dann anzuschauen.
Nim die Option :r wie raw und vergleich dann nochmal. Sollte doch nicht
schwierig sein das mit einem Hex Editor dann anzuschauen.
siehe einfaches lesen im AVRdude - es ist auf der richtigen Addresse.
Wie auch anfangs einer geschrieben habe wenn der Flash leer ist läuft er durch den ganzen falsh und führt den Code aus was dann notgedrongen zum starten führen müsste.
Nim die Option :r wie raw und vergleich dann nochmal. Sollte doch nicht
schwierig sein das mit einem Hex Editor dann anzuschauen.
siehe einfaches lesen im AVRdude - es ist auf der richtigen Addresse.
Wie auch anfangs einer geschrieben habe wenn der Flash leer ist läuft er
durch den ganzen falsh und führt den Code aus was dann notgedrongen zum
starten führen müsste.
Nim die Option :r wie raw und vergleich dann nochmal. Sollte doch nicht
schwierig sein das mit einem Hex Editor dann anzuschauen.
(mist jetzt ist mein kompletter eintrag verloren gegangen)
siehe einfaches lesen im AVRdude - es ist auf der richtigen Addresse.
Wie auch anfangs einer geschrieben habe wenn der Flash leer ist läuft er durch den ganzen falsh und führt den Code aus was dann notgedrongen zum starten führen müsste.
Ob man Hex (IntelHex) mag oder nicht es steht hier auf der richtigen addresse (ein Edito hilft dir im hervorheben dabei) wie durch mehrere methoden schon getestet ich gehe schon langsam von nen Hardware fehler im Chip aus.
Hier bitte wer es immer noch nicht glaubt beide wege noch mal gemacht....
ich gehe schon langsam von nen Hardware fehler
im Chip aus.
Das kann natürlich sein. Aber was für ein Hardwarefehler sollte verhindern, dass der Code des Bootloaders, der sichtlich an der richtigen Stelle im Flash steht, in der zweiten Flashhälfte nicht ausgeführt wird?
Dein Bootloader beginnt bei 0x1FC00 mit 17 C0. Das ist ein relativer Sprung zu Byteadresse 0x1FC30. Das sieht korrekt aus.
Allerdings wundert mich, dass dein Bootloader am Anfang noch eine Vektortabelle enthält. Diese Vektoren sind ja zunächst nur für ein "normales" Programm interessant, das an Adresse 0x00000 beginnt und die den Vektoren zugeordneten Interrupts verwendet.
Ich habe hier auch einen von mir mit Microchip Studio selbstgeschriebenen CAN-Bootloader, der ebenfalls auch den m1284p unterstützt. Der ist allerdings 2048 Worte groß, funktioniert aber an Byteadresse 0x1F000 problemlos.
Woher weißt du eigentlich, dass dein Bootloader nicht anläuft?
ich gehe schon langsam von nen Hardware fehler
im Chip aus.
Das kann natürlich sein. Aber was für ein Hardwarefehler sollte
verhindern, dass der Code des Bootloaders, der sichtlich an der
richtigen Stelle im Flash steht, in der zweiten Flashhälfte nicht
ausgeführt wird?
Dein Bootloader beginnt bei 0x1FC00 mit 17 C0. Das ist ein relativer
Sprung zu Byteadresse 0x1FC30. Das sieht korrekt aus.
Allerdings wundert mich, dass dein Bootloader am Anfang noch eine
Vektortabelle enthält. Diese Vektoren sind ja zunächst nur für ein
"normales" Programm interessant, das an Adresse 0x00000 beginnt und die
den Vektoren zugeordneten Interrupts verwendet.
Ich habe hier auch einen von mir mit Microchip Studio
selbstgeschriebenen CAN-Bootloader, der ebenfalls auch den m1284p
unterstützt. Der ist allerdings 2048 Worte groß, funktioniert aber an
Byteadresse 0x1F000 problemlos.
Woher weißt du eigentlich, dass dein Bootloader nicht anläuft?
LG, Sebastian
weil der bootloader sich melden würde bzw wenn ich hallo zu ihm sage ihr mir antwortet das macht er hier nicht mehr.
Gute frage was die Tabelle da soll, die ist auch da auf dein anderen Atmegas die damit funktionieren.
@ob s. vermuttlich habe ich da mal eine andere addresse ausprobiert die die euch ausversehen hochgeladen... Uhrsürunglich ist 0x1FC00
Was doch fraglich ist warum läuft dieser Bootloader wenn er in dem Addressbereich von 0-64k egal wo gelegt wird.
Er startet nicht wenn er ausserhalb den 64k gelegt wird.
Es liegt hier nicht an den BOOTSZ, da der PC einfach weiter läuft.
Woher weißt du eigentlich, dass dein Bootloader nicht anläuft?
LG, Sebastian
weil der bootloader sich melden würde bzw wenn ich hallo zu ihm sage ihr
mir antwortet das macht er hier nicht mehr.
Bist Du da schon mal mit einem JTAG-Debugger bei gewesen und hast den gesamten Ablauf vom Reset an durchgesteppt? Mit dem passenden Werkzeug würdest Du nicht rumraten müssen, sondern könntest ganz klar sehen, was Sache ist.
@ob s. vermuttlich habe ich da mal eine andere addresse ausprobiert die
die euch ausversehen hochgeladen... Uhrsürunglich ist 0x1FC00
Nunja, das zeugt zumindest definitiv nicht von kompetenter (d.h.: systematischer) Fehlersuche. Sowas wie die physische Lokalität des Codes hält man da einfach erstmal konstant.
Wir haben also erstmal zwei Code-Lokalisationen, einmal auf 1fc00 und einmal auf 1e000. Da stellt sich natürlich unmittelbar die Frage, wie die BOOTSZ-Fuses in diesen beiden Fällen jeweils gesetzt waren...
Ich würde ja den Bootloader erst mal abschalten und dann trotzdem nach 1FC00 schreiben.
Dann ein kurzes ASM Prog schreiben
in etwa
org 0
JMP 0xFE00 Da muss sich der Loader wenn er den funktioniert. Wenn das funktioniert kann es ja nur an den BootSZ Fuses bzw BOOTRST Fuse liegen.
Vielleicht läuft er ja doch los, aber kommt nicht bis an die Stelle mit der Meldung? Beim 1284P muss ja zum Beispiel der Zugriff auf im Flash gespeicherte Daten über pgm_read_byte_far erfolgen. Wenn man nur pgm_read_byte verwendet, funktioniert es nur, wenn die Daten in der vorderen Flashhälfte liegen. Aber dazu müsste man deinen Bootloader näher unter die Lupe nehmen ...
Vielleicht läuft er ja doch los, aber kommt nicht bis an die Stelle mit
der Meldung? Beim 1284P muss ja zum Beispiel der Zugriff auf im Flash
gespeicherte Daten über pgm_read_byte_far erfolgen. Wenn man nur
pgm_read_byte verwendet, funktioniert es nur, wenn die Daten in der
vorderen Flashhälfte liegen. Aber dazu müsste man deinen Bootloader
näher unter die Lupe nehmen ...
LG, Sebastian
Vielen dank an alle für die Mühe und Zeit die ihr hier investiert habt.
Danke genau das war auch mein gedanke.
Jetzt weis ich wo ich suchen darf. Das Zeitliche ist immer so ein Problem wenn man nur 1-2 Stunden für das Projekt hat und dann es liegen bleibt da vergisst man so oft dinge...
Ich habe mich gestern abend im Bett wo sonst auf einmal errinert, das ich ne LED doch angeschalten habe vor x monaten als ich das letzte mal mich damit beschäftgt habe.
Der CAN-Controller ist über SPI angeschlossen und die Kommunikation hat nicht funktioniert. Es scheint hier ein Problem zu sein wenn es überhalb von 64k Flash verwendet wird das Programm.
So ist jetzt meine vermuttung ich hoffe ich errinerre mich da richtig.
Werde es die nächsten Tage mal Probieren noch mal.
Zu JTAG ist leider nicht verfügbar, Designe Technisch ohne Aufwand.
@Ob S. sehr schön das du Kompetenter und Fehlerfrei bist und alle gegebenheiten schon durschaut hast, dann kann ich ja noch was von einem hoch Kompetenten Vollprofi was lernen. Ich lernen immer gerne was dazu, jeder hat mal unten angefangen! Wie war das mit dem Intel Hex?
Der Bootloader muß natürlich für die richtige Adresse gelinkt werden, sonst scheint er zu funktionieren, aber nur bei leerer Applikation, da der PC einfach durch den leeren Bereich (0xFFFF) durchrauscht, bis er ihn findet.
Ansonsten ist der einzige Unterschied, daß man vor dem SPM-Befehl das RAMPZ Register laden muß. Dazu muß natürlich der Adreßzähler auch mindestens 3 Byte groß sein.
In meinem Bootloader sieht das dann so aus:
Hab nen avrice somit jtag nur müsste ich da schaltungstechnisch was machen. Mal schauen, vieleicht die schnellere variante. bis ich im labor bin erst mal theoretisch danach suchen.
wie gesagt der bootloader läuft los es ist wohl in der canlib die in asm geschrieben ist begraben so nach den überlegungen.
Wer lust hat hab die asm datei angehängt. Hab gerade anderes zu tun, die ernte ist gerade wichtiger.
es ist wohl in der canlib die in asm geschrieben ist begraben so nach
den überlegungen
In mcp2515_asm.S sehe ich weder (E)LPM noch SPM-Befehle. Insofern denke ich die Ursache liegt noch woanders. In meinem Bootloader ist zum Beispiel __do_copy_data (und btw auch __do_clear_bss) leer, und ich greife auf alle Literale stattdessen explizit mit pgm_read_byte_far zu ...
Florian schrieb im Beitrag #7524188:
Ich habe mich gestern abend im Bett wo sonst auf einmal errinert, das
ich ne LED doch angeschalten habe vor x monaten als ich das letzte mal
mich damit beschäftgt habe.
Der CAN-Controller ist über SPI angeschlossen und die Kommunikation hat
nicht funktioniert. Es scheint hier ein Problem zu sein wenn es überhalb
von 64k Flash verwendet wird das Programm.
So ist jetzt meine vermuttung ich hoffe ich errinerre mich da richtig.
@Sebastian danke für deine Mühe und Zeit dies durchzuschauen.
Ich weis, dass er in die Init geht bis zu dem wo auf ne Can nachricht gewartet wird und ich sehe am Oszi die Zugriffe wie ich noch weiter verifizieren kann.
Der Controller hat auch nachricht anliegen, da der ISR gezogen wird.
Wie schon erwähnt er kommt ja gar nicht erst zum Programieren, denn er übt sich in schweigen auf die Aufforderung.
Die Funktion: mcp2515_get_message gibt NO_MESSAGE zurück was nicht stimmt. Soweit war ich damals,da hatte ich noch was anderes in verdacht das sicher 3 Monate her wo ich das Probiert habe.
Das könnte der Casus Knaxus sein. Eine ISR braucht einen Vektor. Das
schaue ich mir später mal genauer an.
LG, Sebastian
das ganze läuft ohne ISR im Bootloader - die config ist nur gleich wie in der Firmware.
Hab den fehler gefunden, es ist in der Config vom CAN-Controller bei der Initialisierung über den 64k Falsh - sowas musste es ja sein.
Jetzt passt er leider mit 1032 Bytes nicht mehr in die Handlichen 512 Wörtern. Bei einen 128k MCU sollte aber 1024 Wörter für eine Bootloader schon noch zu entbeeren möglich sein.
es ist in der Config vom CAN-Controller bei der
Initialisierung über den 64k Falsh
Ja, dort wird RAMPZ0 nicht gesetzt, und dann wird 46* 0xFF aus 0xFC02-0xFC2F an den MCP2515 gesendet; das mag der nicht :)
Soweit war ich auch gerade.
Aber beim Schreiben der Flash-Seiten musst du auch aufpassen, dass RAMPZ0 korrekt je nach Adresse gesetzt wird. Und Speicheradressen sind beim 1284P 17 Bit lang, das muss dein CAN-Bootprotokoll auch unterstützen.
