Forum: Mikrocontroller und Digitale Elektronik Bootloader für ATmega 2560 wird immer überschrieben


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Jürgen G. (Firma: brisco) (brisco)


Bewertung
0 lesenswert
nicht lesenswert
Hallo

habe ein custom Atmega2560 board und muss den Bootloader drauf haben 
damit ich mit stk500 über USB->RS232 die CPU programmieren kann.

Ich habe es mit einem UNO Board geschafft den Bootloader zu brennen. 
Habe dazu dies verwendet http://www.gammon.com.au/bootloader.

Es funktioniert tatsächlich, so dass ich über stk500 ein mal den 2560'er 
flashen kann aber nur ein mal. Es scheint als ob der bootsektor 
überschrieben wird.

Kennt jemand eine Lösung?
Danke

von S. R. (svenska)


Bewertung
-1 lesenswert
nicht lesenswert
Du musst deinem ISP-Programmer (also dem STK500) auch sagen, dass es 
beim Chip-Erase den Bootloader nicht löschen soll. Sonst überschreibst 
du den nämlich tatsächlich.

von TestX (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Das STK500 ist normalerweise ein ISP Programmer, der keinen Bootloader 
benötigt und somit den gesamten Flash neu beschreibt. Bist du dir 
sicher, dass du den richtigen COM Port am STK verwendest und die RX/TX 
Pins entsprechend verbunden hast ?

von Arduino Fanboy D. (ufuf)


Bewertung
0 lesenswert
nicht lesenswert
Jürgen G. schrieb:
> Es funktioniert tatsächlich, so dass ich über stk500 ein mal den 2560'er
> flashen kann aber nur ein mal. Es scheint als ob der bootsektor
> überschrieben wird.
>
> Kennt jemand eine Lösung?

Ja!
Den stk500, nach dem Bootloader schreiben, in die Schublade legen!
Danach einen seriell Adapter verwenden.

(natürlich nicht vergessen, die Bootloaderfuses zu setzen.)

von brisco (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Vielen Dank für die schnellen Antworten!

Ich muss mich korrigieren.
Ich verwende einen USB to Serial Adapter. 
https://shop.openenergymonitor.com/programmer-usb-to-serial-uart/
Ich bin mir nicht sicher ob die Bezeichung STK500 stimmt. sorry.

Ich verwende u.a. auch die arduino IDE. In der IDE kann ich nicht 
angeben den Bootloader nicht zu überschreiben.
Oder wenn ich direkt über avrdude downloade "z.B. avrdude –c stk500v1 
–P\\.\COM4 –p m2560 –U flash:w:filename.hex" dann sollte ja auch nichts 
passieren mit dem Bootloader.

Es müsste doch aber auch möglich sein mit den lock bits den Bootloader 
resistent im Chip zu belassen, oder?

Der Grund: Das 2560'er Board ist über eine serielle Schnittstelle mit 
einem Rasperry PI verbunden und auf diesem kann ich avrdude remote 
ausführen. Schlussendlich gehts um remote firmware update.

von Jürgen G. (Firma: brisco) (brisco)


Angehängte Dateien:
  • preview image for bl.png
    bl.png
    185 KB, 381 Downloads

Bewertung
0 lesenswert
nicht lesenswert
welche Lockbits muss ich setzten damit der Bootloader drin bleibt?

von Peter D. (peda)


Bewertung
0 lesenswert
nicht lesenswert
Jürgen G. schrieb:
> Es funktioniert tatsächlich, so dass ich über stk500 ein mal den 2560'er
> flashen kann aber nur ein mal. Es scheint als ob der bootsektor
> überschrieben wird.

Es scheint nur so.
Du hast vergessen, in den Fusebits das Bootloaderreset zu aktivieren.
Solange die Applikation noch leer ist, merkst Du das nur nicht.

von Jürgen G. (Firma: brisco) (brisco)


Bewertung
0 lesenswert
nicht lesenswert
aha..
d.h. ich muss ich aktivieren:
Fusebit BOOTRST=0
->Was macht das genau?


und welche(s) Lock Fusebit muss ich setzen??

Bootloader protection mode 1,2,3 oder 4?

von Jürgen G. (Firma: brisco) (brisco)


Bewertung
0 lesenswert
nicht lesenswert
Ich habe es ausgetestet mit BOOTRST aktivieren und dann lock bits auf 
0x2F zu stellen. Leider immer noch das Geiche. Der Bootloader wird 
überschrieben nach dem ersten Mal App schreiben.

Hier der Output von Avrdude beim schreiben der fuses:
1
c:\Program Files (x86)\Arduino\hardware\tools\avr\bin>avrdude -p m2560 -c  usbtiny  -U hfuse:w:0xd0:m -U lock:w:0x2f:m
2
3
avrdude: AVR device initialized and ready to accept instructions
4
5
Reading | ################################################## | 100% 0.01s
6
7
avrdude: Device signature = 0x1e9801 (probably m2560)
8
avrdude: reading input file "0xd0"
9
avrdude: writing hfuse (1 bytes):
10
11
Writing | ################################################## | 100% 0.01s
12
13
avrdude: 1 bytes of hfuse written
14
avrdude: verifying hfuse memory against 0xd0:
15
avrdude: load data hfuse data from input file 0xd0:
16
avrdude: input file 0xd0 contains 1 bytes
17
avrdude: reading on-chip hfuse data:
18
19
Reading | ################################################## | 100% 0.02s
20
21
avrdude: verifying ...
22
avrdude: 1 bytes of hfuse verified
23
avrdude: reading input file "0x2f"
24
avrdude: writing lock (1 bytes):
25
26
Writing | ################################################## | 100% -0.00s
27
28
avrdude: 1 bytes of lock written
29
avrdude: verifying lock memory against 0x2f:
30
avrdude: load data lock data from input file 0x2f:
31
avrdude: input file 0x2f contains 1 bytes
32
avrdude: reading on-chip lock data:
33
34
Reading | ################################################## | 100% 0.02s
35
36
avrdude: verifying ...
37
avrdude: 1 bytes of lock verified
38
39
avrdude: safemode: Fuses OK (E:FD, H:D0, L:FF)
40
41
avrdude done.  Thank you.

von Pandur S. (jetztnicht)


Bewertung
0 lesenswert
nicht lesenswert
So ganz nebenbei... ein Bootloader kann sich in einem flashbasierten 
system nicht selbst ueberschreiben. Das geht nur in einem Systeme, wo 
der Code in RAM ausgefuehrt werden kann.

von Philipp K. (philipp_k59)


Bewertung
0 lesenswert
nicht lesenswert
Richtige Fuse Bootloadergröße?

wenn der Bootloader 2KB hat und nur 1KB eingestellt ist könnte der beim 
flashen des programms überschrieben werden.

von Werner (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Jürgen G. schrieb:
> avrdude -p m2560 -c  usbtiny  -U hfuse:w:0xd0:m -U lock:w:0x2f:m

Seit wann kann man denn über den Bootlader die Lockbits und Fusebits 
schreiben?

Ich würde ja mal behaupten, dass Du den Bootloader immernoch nicht 
nutzt.
Was du da machst ist ISP, das hat nichts mit dem Bootloader zu tun.

Nutze den doch mal und dann sagst du uns, ob der Bootloader dann 
immernoch überschrieben wurde.

Wie schon geschrieben:

Arduino F. schrieb:
> Den stk500, nach dem Bootloader schreiben, in die Schublade legen!
> Danach einen seriell Adapter verwenden.

Du müsstest nun im Prinzip nur noch soetwas:
https://www.intos.de/media/image/thumbnail/0_444_0_720x600.jpg
oder so etwas:
http://www.ftdichip.com/Images/TTL-232R1.jpg
verwenden.

Werner

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
Flashen über ISP beginnt immer mit einem vollständigen Löschen des Flash 
Speichers. Damit ist der Bootloader dann weg. Geht bei AVR's nicht 
anders.

von Jürgen G. (Firma: brisco) (brisco)


Bewertung
0 lesenswert
nicht lesenswert
Vielen Dank für all Eure Informationen.

Ihr habt mit aber jetzt etwas abgehängt...
Kurz nochmals damit ich Euch richtig verstehe:

Bootloader ist die Software über welche ich einfach über TX und RX Pins 
des Atmega2560 neue App FW flashen kann.

Mit dem USB zu Serial converter kann ich z.B. mit arduino oder avrdude 
direkt FW auf die CPU laden.

ISP ist die Schnittstelle (SPI) wo ich den Bootloader Code in den CPU 
Flash schreiben kann.

Die Fuse Bits kann ich mit avrdude über ISP programmieren

--------------

Ich kann den Bootloader auf die CPU brennen, das funktioniert sehr gut.
Die Fuse bits habe ich dann so gesetzt, dass die Bootloader Sektion 
gesperrt ist (Applications FW kann Bootloader nicht überschreiben), die 
Bootloadergrösse auf Maximum 4096 gesetzt ist, und BOOTRST aktiviert 
ist.

Danach kann ich über die serielle Schnittstelle meine Applikation auf 
die CPU brennen. Soweit so gut. Aber ich kann nur einmal dies machen.

Habe ich einen Überlegungsfehler?
Vielen Dank!

von Arduino Fanboy D. (ufuf)


Bewertung
0 lesenswert
nicht lesenswert
Jürgen G. schrieb:
> Aber ich kann nur einmal dies machen.

Wenn du soweit alles richtig gemacht hast, und danach sieht es aus.
(kann ich leider nicht überprüfen)


Dann fehlt bestimmt nur noch die richtige Reset Beschaltung.

Der Reset deines µC braucht dafür einen Pullup, ca 10K sollten ok sein.
Und einen 100nF Kondensator zwischen DTR deines Adapters und Reset des 
µC

Alternativ:
Im richtigen Moment Reset drücken, wenn Reset Taster vorhanden.

: Bearbeitet durch User
von Jürgen G. (Firma: brisco) (brisco)


Bewertung
0 lesenswert
nicht lesenswert
Vielen Dank.

Nein Reset funktioniert tadellos. Ich kann ja die App FW auf die CPU 
brennen. Wenn ein Reset vorhanden wäre würde avrdude nicht brennen 
können.

von Arduino Fanboy D. (ufuf)


Bewertung
0 lesenswert
nicht lesenswert
Jürgen G. schrieb:
> Wenn ein Reset vorhanden wäre würde avrdude nicht brennen
> können.

Das ist ein Irrtum!

Bedenke:
Ohne Reset kommt der Bootloader gar nicht ins Spiel.


Das erste Mal klappts nur, weil noch keine Anwendung auf dem µC ist.



Die Eingangsfrage
> Bootloader für ATmega 2560 wird immer überschrieben
ist also falsch

Sie müsste lauten:
> Warum kommt mein Bootloader nicht ins Spiel?

Antwort:
Es wird vor dem Upload kein Reset ausgeführt.

: Bearbeitet durch User
von Sven K. (svenk)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe kurz die Webseite überflogen - da steht was von 8192byte für 
den Bootloader

Wie groß ist der Bootloader denn?

Gruß Sven

von Jürgen G. (Firma: brisco) (brisco)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Danke das macht Sinn aber ich habe eine saubere Reset-Schaltung.
Gem. Anhang

von S. R. (svenska)


Bewertung
0 lesenswert
nicht lesenswert
Du verstehst miss.

Folgendes: Der Chip wird eingeschaltet und springt in den Bootloader. 
Der Bootloader wartet N ms auf ein Update und springt dann in die 
eigentliche Firmware. Wenn keine Firmware vorhanden ist, wartet er ewig.

Wie bekommst du den Chip wieder dazu, auf Updates zu warten? Indem du 
ihn manuell resettest!

von Arduino Fanboy D. (ufuf)


Bewertung
0 lesenswert
nicht lesenswert
Jürgen G. schrieb:
> aber ich habe eine saubere Reset-Schaltung.
> Gem. Anhang

Hast du nicht!
Der Kondensator an GND ist falsch, wenn du den Bootloader nutzen willst.
Dann muss der Kondensator zwischen Reset und DTR deines USB Seriell 
Adapters.

Wenn du den Kondensator "so" behalten willst, wirst du den Reset mit 
einem Transistor, oder zufuß, betätigen müssen.

Glaube mir!
Glaube mir!
Glaube mir!

Und wenn nicht, dann möchte ich gerne Gegenanzeigen sehen/lesen/hören.

: Bearbeitet durch User
von Jürgen G (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ja du hast recht!!! Ich sehe den Wald lauter Bäume nicht mehr.morgen 
teste ich das aus

von Jürgen G. (Firma: brisco) (brisco)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Moment.. habe ich selber übersehen. Ich habe ja ein C zw. DTR und Reset. 
Mein FTDI USB-Serial Adater würde ja sonst nocht funktionieren.

Das RC Glied ist nur für den Startup des Boards damit zuerst die 
Speisespannung hochkommen kann und dann der Reset.

von Arduino Fanboy D. (ufuf)


Bewertung
0 lesenswert
nicht lesenswert
2 gleiche Kondensatoren gegeneinander.
Das heißt, der Reset Pegel sinkt nur auf 50%.
Oder noch etwas weniger, wegen dem Pullup.

Sagen wir mal 60% ...
Ich glaube nicht, dass ein 5V ATMega bei 3V in den Reset geht.
Habe aber jetzt auch nicht das Datenblatt daraufhin überprüft, das 
überlasse ich dir.

Nachtrag:
Habe gerade den Schaltplan des Arduino Mega überprüft. Da ist es wie in 
deinem Plan.
Und das tuts schließlich...

Nunja...
So kanns kommen.

: Bearbeitet durch User
von Philipp K. (philipp_k59)


Bewertung
0 lesenswert
nicht lesenswert
Stefan U. schrieb:
> Flashen über ISP beginnt immer mit einem vollständigen Löschen des Flash
> Speichers. Damit ist der Bootloader dann weg. Geht bei AVR's nicht
> anders.

in den Compiling Options der Arduino-IDE ist dann sowas wie "LDFLAGS += 
-Wl,--section-start=.text=$(BOOTLOADER_ADDRESS)" mit drin.

Das könnte das doch umgehen?

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
Nein, ich denke das hat nichts mit den Sektionen zu tun. Vor dem Flashen 
des Programms wird immer ein Löschbefehl abgesetzt. Und der löscht den 
ganzen Speicher.

man hat nur die Wahl, ob auch das EEprom gelöscht werden soll, oder 
nicht.

von Philipp_K59 (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hmmm okay, muss zugeben das ist mir nur so neu, das mir das entweder nie 
aufgefallen ist oder die Arduino IDE da sie alle Bootloader dabei hat 
den gleich in eins mitschreibt.. Da gibt es die Option "upload using 
Programmer".. ISP benutze ich bis auf wenige Ausnahmen nur zum 
Bootloader Flaschen.

von Hubert G. (hubertg)


Bewertung
0 lesenswert
nicht lesenswert
Arduino F. schrieb:
> Habe gerade den Schaltplan des Arduino Mega überprüft. Da ist es wie in
> deinem Plan.
> Und das tuts schließlich...

In meinem Schaltplan hat der Kondensator nach GND aber nur 22p.

von Arduino Fanboy D. (ufuf)


Bewertung
0 lesenswert
nicht lesenswert
Hubert G. schrieb:
> In meinem Schaltplan hat der Kondensator nach GND aber nur 22p.
Viel plausibler!

https://www.arduino.cc/en/uploads/Main/arduino-mega-schematic.pdf 100nF
https://www.arduino.cc/en/uploads/Main/arduino-mega2560_R3-sch.pdf 22pF

:) So kann Fortschritt auch aussehen :)

Und ich dachte schon ich spinne...
(wobei, das würde mich auch nicht sehr wundern)

von Jürgen G. (Firma: brisco) (brisco)


Bewertung
0 lesenswert
nicht lesenswert
Ich habe die Reset Schaltung temporär so verändert, dass ich nur ein 
0.1u C zwischen DTR des FTDI Programmers und dem Reset Pin habe. C18 
gegen GND ist jetzt komplett weg. Klar, power up Reset funktioniert zZ 
nur manuell. Aber so kann ausgeschlossen werden, dass das Problem beim 
Reset liegt.

Ich bin mir ziemlich sicher, dass es an den Fuse Bits liegt. Den 
Bootloader flashe ich mit Gammon's Sketch auf die CPU- siehe Output 
unten. Nur einmal aber kann ich danach über FTDI meine Applikation 
hochladen. Eine logische Erklärung wäre also dass der Bootloader 
überschrieben wird.

Gemäss Output von Gammon's Sketch hat der Bootloader eine Grösse von 
8192Bytes. Fie Fuse bits werden wie folgt gesetzt (gem. Output Gammon 
Sketch):
- "Boot Sector Flash Size" = 4096 Words. Wenn 1 Word = 2 Bytes dann 
passts
- Start Adresse ist dann bei 1F000.
- Lock bits: "Boot Loader Protection Mode2: SPM prohibited in Boot 
Loader Section" -> SPM heisst Storage Programm Memory, Einstellung 
scheint ok
- Fuse Bit "BOOTRST" ist aktiviert, das passt auch soweit.

Output von Gammons Sketch mit welchem ich den BL flashe:
1
Erasing chip ...
2
Writing bootloader ...
3
Committing page starting at 0x3E000
4
Committing page starting at 0x3E100
5
Committing page starting at 0x3E200
6
Committing page starting at 0x3E300
7
Committing page starting at 0x3E400
8
Committing page starting at 0x3E500
9
Committing page starting at 0x3E600
10
Committing page starting at 0x3E700
11
Committing page starting at 0x3E800
12
Committing page starting at 0x3E900
13
Committing page starting at 0x3EA00
14
Committing page starting at 0x3EB00
15
Committing page starting at 0x3EC00
16
Committing page starting at 0x3ED00
17
Committing page starting at 0x3EE00
18
Committing page starting at 0x3EF00
19
Committing page starting at 0x3F000
20
Committing page starting at 0x3F100
21
Committing page starting at 0x3F200
22
Committing page starting at 0x3F300
23
Committing page starting at 0x3F400
24
Committing page starting at 0x3F500
25
Committing page starting at 0x3F600
26
Committing page starting at 0x3F700
27
Committing page starting at 0x3F800
28
Committing page starting at 0x3F900
29
Committing page starting at 0x3FA00
30
Committing page starting at 0x3FB00
31
Committing page starting at 0x3FC00
32
Committing page starting at 0x3FD00
33
Written.
34
Verifying ...
35
No errors found.
36
Writing fuses ...
37
LFuse = 0xFF 
38
HFuse = 0xD8 
39
EFuse = 0xFD 
40
Lock byte = 0xEF 
41
Clock calibration = 0x9E 
42
Done.
43
Programming mode off.
44
Type 'C' when ready to continue with another chip ...

Was mir aber auffällt ist der Beginn wo geschrieben wir bei 0x3E00. 
Müsste das nicht 1F000 (gemäss Fuse bits) sein?

von Walter S. (avatar)


Bewertung
0 lesenswert
nicht lesenswert
Jürgen G. schrieb:
> Was mir aber auffällt ist der Beginn wo geschrieben wir bei 0x3E00.
> Müsste das nicht 1F000 (gemäss Fuse bits) sein?

1f000*2 == 3e000

von Sven K. (svenk)


Bewertung
0 lesenswert
nicht lesenswert
Ich denke da steht doch die Ursache:

Hfuse muss doch mal 0xD0 sein damit der Bootloader laufen kann. Hast Du 
auch oben mit avrdude gefused.

Aber die Bootloader Ausgabe sagt jetzt auf einmal 0xD8 ????

Gruß Sven

Ps: Was gibt denn avrdude nach dem Upload mit dem Bootloader über die 
Fuses aus??? (Nur Auslesen )

: Bearbeitet durch User
von Jürgen G. (Firma: brisco) (brisco)


Bewertung
0 lesenswert
nicht lesenswert
Danke Sven aber der Unterschied 0xD0 zu 0xD8 im hfuse byte ist nur 
"Preserve EEPROM memory through the Chip Erase cycle". Das kann es nicht 
sein. Das ist nicht der Flash speicher.

von spess53 (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hi

Wenn du über ISP programmieren kannst, wozu brauchst du eigentlich 
dieses Bottloadergedödel?

MfG Spess

von Jürgen G. (Firma: brisco) (brisco)


Bewertung
0 lesenswert
nicht lesenswert
remote Firmware upgrade über Serial If

von S. R. (svenska)


Bewertung
0 lesenswert
nicht lesenswert
Und warum machst du dann nicht "jedes" Update remote?

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
Der Flash Speicher ist 16 bit breit.

Manche Programme zählen die Adressen wie der AVR selbst so:

Adr      Wert
0x0000 = 0xBBAA
0x0001 = 0xDDCC
0x0002 = 0xFFEE

Deswegen kann der AVR mit seinem 16bit Programmzähler 128kB Programme 
ausführen.
Nur der ATmega2560 hat einen ungewöhnlich großen Programmzähler mit 17 
Bits, was bei der Programmierung mitunter besonder berücksichtigt werden 
muss.

Manche Programme zählen jedoch stattdessen die Bytes:

0x0000 = 0xAA
0x0001 = 0xBB
0x0002 = 0xCC
0x0003 = 0xDD
0x0004 = 0xEE
0x0005 = 0xFF

von Sven K. (svenk)


Bewertung
0 lesenswert
nicht lesenswert
Jürgen G. schrieb:
> Danke Sven aber der Unterschied 0xD0 zu 0xD8 im hfuse byte ist nur
> "Preserve EEPROM memory through the Chip Erase cycle". Das kann es nicht
> sein. Das ist nicht der Flash speicher.

Entschuldigung, da hast Du natürlich vollkommen recht. Damit sind die 
Fuse Einstellungen also als Fehler erstmal ausgeschlossen.

Gruß Sven

von Arduino Fanboy D. (ufuf)


Bewertung
0 lesenswert
nicht lesenswert
Dann bleibt die Frage:
Wird beim öffnen der seriellen Schnittstelle ein Reset ausgelöst?

Wenn nein: Dann kommt der Bootloader auch nicht an die Reihe.
Wenn ja: Woanders suchen.

: Bearbeitet durch User
von Jürgen G (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ja der reset wird ausgeführt. Erst deswegen kann ich mit dem ftdi 
adapter die app laden.

von Arduino Fanboy D. (ufuf)


Bewertung
0 lesenswert
nicht lesenswert
Jürgen G schrieb:
> Erst deswegen kann ich mit dem ftdi
> adapter die app laden.

Ich dachte das funktioniert nicht...
Beim 2ten mal...

Warum es beim ersten mal, auch ohne Reset, funktioniert, habe ich doch 
schon erklärt, oder?

: Bearbeitet durch User
von Jürgen G (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Reset funktioniert perfekt! Geprüft mit Oszi. Habe sogar das C grösser 
gemacht, so dass das reset Signal noch länger ansteht (C zwischen FTDi 
und Reset). Aber das macht keinen Unterschied.

Mein FTDI Programmier funktioniert an einem Arduino UNO perfekt.

von c-hater (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Sapperlot W. schrieb:

> So ganz nebenbei... ein Bootloader kann sich in einem flashbasierten
> system nicht selbst ueberschreiben. Das geht nur in einem Systeme, wo
> der Code in RAM ausgefuehrt werden kann.

Unsinn. Natürlich kann sich ein Bootloader bei den AVR8 auch selbst 
überschreiben. Und wenn er kleiner als eine Flashpage ist, braucht er 
nichtmal für die Daten (also den Code des neuen Bootloaders) 
Zwischenspeicher.

Ansonsten allerdings schon, dann braucht er Zwischenspeicher im Umfang 
des Bootloadercodes abzüglich einer Flash-Page. Das muss aber nicht 
unbedingt RAM sein, man kann auch EEPROM oder freie Bereiche des Flash 
im Applikationsbereich dafür verwenden.

Allerdings muss der Bootloader, um sich selber "unfallfrei" 
überschreiben zu können, auch speziell für diesen Zweck designed sein. 
Das ist kinderleicht umzusetzen, jedenfalls in Assembler, wo man die 
volle Kontrolle über den Code hat...

von das kenn ich (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Arduino IDE genommen,
mit Fischl-USB-Isp Programmer den Bootlader(für Nano-Board) in Mega328 
gebrannt.
Dann nur einmal ist der Bootloader nutzbar, dann ist er weg ??????

Dann habe ich mir doch ein UNO Board gekauft, den ISP-Programmer Sketch 
eingeladen, per ISP auf einem Breadboard in einen Mega328 den Bootlaoder 
gebrannt ...
und nun alles paletti, hä wie das ??? Bisher keine Antwort gefunden.

von S. R. (svenska)


Bewertung
0 lesenswert
nicht lesenswert
c-hater schrieb:
> Allerdings muss der Bootloader, um sich selber "unfallfrei"
> überschreiben zu können, auch speziell für diesen Zweck designed sein.

Das heißt, er muss mindestens zwei Eraseblöcke belegen und 
sicherstellen, dass er aus dem gerade nicht gelöschten Eraseblock 
ausgeführt wird.

Widerspricht deinem "wenn er nur einen Eraseblock groß ist" ein 
bisschen...

von c-hater (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
S. R. schrieb:

> Das heißt, er muss mindestens zwei Eraseblöcke belegen und
> sicherstellen, dass er aus dem gerade nicht gelöschten Eraseblock
> ausgeführt wird.

Natürlich benötigt er einige wenige Instruktionen an zwei Stellen im 
Flash, die nicht in der gleichen Erasepage liegen dürfen. Das macht halt 
genau das "spezielle Design" aus.

> Widerspricht deinem "wenn er nur einen Eraseblock groß ist" ein
> bisschen...

Nein. Wenn eine Page z.B. 128 Bytes groß ist, dann kann ich die acht 
Bytes Instruktionen, die in zwei unterschiedlichen Pages liegen müssen, 
logischerweise bereits bereitstellen, wenn mein Bootloader 16 Bytes groß 
ist. Das ist sogar deutlich weniger als eine Page...

Und ich brauche keinen Pufferspeicher dafür und kann trotzdem alles an 
Flashinhalt erhalten, was in diesen beiden Pages außer diesen 16 Byte 
Bootloadercode existiert. Denn man kann zwar nur komplette Pages 
löschen, aber niemand hält einen davon ab, hinterher gleich wieder 
(größtenteils) den ursprünglichen Inhalt da rein zu schreiben. Und der 
interne Flash-Buffer macht es sogar möglich, dies ohne weiteren 
Bufferspeicher zu realisieren.

Natürlich kann man mit 16 Bytes noch keinen vollständigen Bootloader 
bauen, aber das Beispiel dient ja auch nur dazu, dir den Unterschied 
zwischen Größe und Alignment zu veranschaulichen. Die sind eben nicht 
zwingend miteinander verknüpft. Nämlich genau dann nicht, wenn man das 
Alignment einfach nur für die Teile des Codes beachtet, für die es 
tatsächlich eine Rolle spielt.

Im Falle eines Bootloaders sind das halt die Vektortabelle im 
Bootloaderbereich, die absolut fix (durch Fuses bestimmt ist) und diese 
zwei mal acht Bytes für den Kern des Bootloadercodes, die halt auf eine 
beliebige Pagegrenze -8 aligned sein müssen. Der ganze Rest kann liegen, 
wo er will.

von S. R. (svenska)


Bewertung
0 lesenswert
nicht lesenswert
Zusammengefasst: Der Bootloader muss zwei Pages überspannen, aber nicht 
unbedingt beide voll ausfüllen. Das ist klar. :-)

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.