Hallo Ihr,
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
Florian schrieb:> 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.
Florian schrieb:> 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.
Weingut P. schrieb:> 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.
Florian schrieb:> 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.
LG, Sebastian
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:
https://github.com/JChristensen/mighty-1284p/tree/v1.6.3
Hier auch noch eine Info dazu:
http://www.technoblogy.com/show?19OV
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.
Sven B. schrieb:> 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:>> https://github.com/JChristensen/mighty-1284p/tree/v1.6.3>> Hier auch noch eine Info dazu:>> http://www.technoblogy.com/show?19OV
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
Bootreset vector enabeld
Um es einfach darzustellen mit den FUse;
http://eleccelerator.com/fusecalc/fusecalc.php?chip=atmega1284p&LOW=F7&HIGH=D6&EXTENDED=FC&LOCKBIT=FF
Florian schrieb:> Wie auch im readout.hex zu sehen ist liegt der ganz hinten im flash wie> es auch sein soll.Ob S. schrieb:> Der Bootloader liegt schlicht nicht im Bootloaderbereich eines 1284P.
Ich sehe auch in readout.hex, dass der Bereich von 0x1FC00 bis 0x1FDFF
auch nach der Bootloaderprogrammierung immer noch leer ist.
Hast du die Programmierung von avrdude verifizieren lassen?
LG, Sebastian
Florian schrieb:> 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.
Was ist das jetzt für eine Adresse????
Es gibt:
Bootflash size 512 = $FE00
Bootflash size 1024 = $FC00
Bootflash size 2048 = $F800
Bootflash size 4096 = $F000
Sven B. schrieb:> Was ist das jetzt für eine Adresse????
Für die Wortadresse $FE00 ist 0x1FC00 die Byteadresse, die man dem
Linker in der --section-start Option mitteilen muss.
LG, Sebastian
Sebastian W. schrieb:> Sven B. schrieb:>> Was ist das jetzt für eine Adresse????>> 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.
Ja dem Linker wird 0x1FC00 als Startaddr gegeben und es ist auch im HEX
File zur sehen es wird der Komplette Flash damit gelesen Intel Hex halt.
Im Datenblat wird die Wordaddr (16) bit addr angegeben. Somit 0xFE00 * 2
(wie beginn schon geschrieben) = 0x1FC00
der Flashbereich 64k - 128k ist schreibbar nur wird kein Code ausgeführt
so ist es gerade.
1
avrdude> read flash 0x1fb00 1024
2
3
Reading | ################################################## | 100% 0.18 s
>> 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.
Florian schrieb:> Ja dem Linker wird 0x1FC00 als Startaddr gegeben und es ist auch> im HEX> File zur sehen es wird der Komplette Flash damit gelesen Intel Hex halt.>> Im Datenblat wird die Wordaddr (16) bit addr angegeben. Somit 0xFE00 * 2> (wie beginn schon geschrieben) = 0x1FC00>> der Flashbereich 64k - 128k ist schreibbar nur wird kein Code ausgeführt> so ist es gerade.> 1avrdude> read flash 0x1fb00 1024> 23Reading | ################################################## | 100%> 0.18 s> 451fb00 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff> |................|> 61fb10 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff> |................|> 71fb20 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff> |................|> 81fb30 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff> |................|> 91fb40 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff> |................|> 101fb50 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff> |................|> 111fb60 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff> |................|> 121fb70 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff> |................|> 131fb80 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff> |................|> 141fb90 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff> |................|> 151fba0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff> |................|> 161fbb0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff> |................|> 171fbc0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff> |................|> 181fbd0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff> |................|> 191fbe0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff> |................|> 201fbf0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff> |................|> 211fc00 17 c0 ff c0 00 00 ff c0 00 00 ff c0 00 00 00 00> |................|> 221fc10 00 80 ff c0 00 00 ff c0 00 00 ff c0 00 00 00 00> |................|> 231fc20 00 80 ff c0 00 00 ff c0 00 00 01 b5 c0 03 00 00> |................|> 241fc30 11 24 1f be cf ef d4 e0 de bf cd bf 84 b7 8e bb> |.$..............|> 251fc40 14 be 88 e1 80 93 60 00 10 92 60 00 85 b1 8f 75> |......`...`....u|> 261fc50 85 b9 84 b1 80 6b 84 b9 2a 9a 22 9a 80 e5 8c bd> |.....k..*.".....|> 271fc60 81 e0 8d bd 85 e0 8a 95 f1 f7 00 00 2a 98 80 ec> |............*...|> 281fc70 4e d1 2a 9a ef e8 f1 e0 31 97 f1 f7 00 c0 00 00> |N.*.....1.......|> 291fc80 2a 98 82 e0 44 d1 80 e0 42 d1 c2 e0 dc ef fe 01> |*...D...B.......|> 301fc90 84 91 3d d1 21 96 fc ef cf 32 df 07 c1 f7 2a 9a> |..=.!....2....*.|> 311fca0 64 e2 80 e6 3b d1 60 e2 80 e7 38 d1 60 e0 8f e0> |d...;.`...8.`...|> 321fcb0 35 d1 8c e7 91 ee 90 93 85 00 80 93 84 00 10 92> |5...............|> 331fcc0 80 00 85 e0 80 93 81 00 81 e0 86 bb cf ef 10 e0> |................|> 341fcd0 ff 24 f3 94 83 e0 e8 2e 90 ee d9 2e 01 c0 c0 2f> |.$............./|> 351fce0 f8 b8 18 b8 02 c0 b0 99 be d0 26 d1 8f 33 d9 f3> |..........&..3..|> 361fcf0 10 92 81 00 98 2f 90 7c 99 f7 8f 73 01 e0 0c 0f> |...../.|...s.. .|> 371fd00 90 91 0c 02 09 17 39 f0 00 93 0c 02 60 e0 80 6c |.. . .9...> .`..l|> 38.....>> 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:
i Intel Hex
I Intel Hex with comments on download and
tolerance of checksum errors on upload
s Motorola S-record
r raw binary; little-endian byte order, in the
case of the flash ROM data
e ELF (Executable and Linkable Format)
m immediate mode; actual byte values are specified
on the command line, separated by commas or spaces in place of the
filename field of the -U option. This is useful
for programming fuse bytes without having to create a single-byte
file or enter terminal mode.
a auto detect; valid for input only, and only if
the input is not provided at stdin.
d decimal; this and the following formats generate
one line of output for the respective memory section, forming a
comma-separated list of the values. This can be
particularly useful for subsequent processing, like for fuse bit
settings.
h hexadecimal; each value will get the string 0x
prepended.
o octal; each value will get a 0 prepended unless
it is less than 8 in which case it gets no prefix.
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.
Sven B. schrieb:> Florian schrieb:>> 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.
Florian schrieb:> Sven B. schrieb:>> Florian schrieb:>>>> 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.
Na ja, wenn du meinst , dann bin ich mal raus.
Sven B. schrieb:> Florian schrieb:>> 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....
Florian schrieb:> 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
Florian schrieb:> Hier bitte wer es immer noch nicht glaubt beide wege noch mal> gemacht....
Die sagen beide, dass der Bootloadercode auf 1fc00 liegen würde. Das von
dir ursprünglich gepostete *.hex sagt aber 1e000.
Magst du diese Diskrepanz erklären?
Sebastian W. schrieb:> Florian schrieb:>> 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.
Florian schrieb:>> 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.
fchk
Florian schrieb:> @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.
Florian schrieb:> weil der bootloader sich melden würde
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
Sebastian W. schrieb:> Florian schrieb:>> weil der bootloader sich melden würde>> 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:
Frank K. schrieb:> Florian schrieb:>>> Zu JTAG ist leider nicht verfügbar, Designe Technisch ohne Aufwand.>> Lässt sich problemlos ändern:>> https://www.microchip.com/en-us/development-tool/pg164100>> fchk
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.
Florian schrieb:> wie gesagt der bootloader läuft los
Hast du das jetzt bestätigen können?
Florian schrieb:> 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
...
LG, Sebastian
Florian schrieb:> Florian schrieb:> 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.
Florian schrieb:> da der ISR gezogen wird
Das könnte der Casus Knaxus sein. Eine ISR braucht einen Vektor. Das
schaue ich mir später mal genauer an.
LG, Sebastian
Sebastian W. schrieb:> Florian schrieb:>> da der ISR gezogen wird>> 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.
Vielen dank an alle für Ihre Zeit und bemühungen.
Florian schrieb:> 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.
LG, Sebastian
Thread beobachten
Seitenaufteilung abschalten