Ich will an einem Atmel 368 mit Bootloader spielen. Das Prinzip habe ich schon verstanden, denke ich.
Wenn ich in Micrchop Studio ein LED-Blinkprogramm ablege, dann läuft das auch (Bootsize 2048 words). Dazu in der Toolchain des Projekts bei Linker/Memory den Eintrag ".text=0x3800" hinzugefügt. Der Code liegt dann auch in der Hex-Datei ab Adresse 0x7000. Zudem die Option "Erase entire chip" beim Programmiertool (Snap) gesetzt.
Fuses sind IMHO korrekt:
1
BODLEVEL = DISABLED:
2
RSTDISBL = [ ]
3
DWEN = [ ]
4
SPIEN = [X]
5
WDTON = [ ]
6
EESAVE = [X]
7
BOOTSZ = 2048W_3800
8
BOOTRST = [X]
9
CKDIV8 = [X]
10
CKOUT = [ ]
11
SUT_CKSEL = INTRCOSC_8MHZ_6CK_14CK_65MS
12
13
EXTENDED = 0xFF (valid)
14
HIGH = 0xD0 (valid)
15
LOW = 0x62 (valid)
1
#define F_CPU 1000000UL
2
#include<avr/io.h>
3
#include<util/delay.h>
4
5
intmain(void){
6
void(*start)(void)=0x0000;
7
DDRC=(1<<DDC5);
8
9
for(uint8_ti=0;i<10;i++){
10
PORTC^=(1<<PORTC5);// toggle pin
11
_delay_ms(200);
12
}
13
start();
14
}
So weit.
Dann ein Hauptprogramm. Macht das gleiche, nur anderer Ausgang
1
#define F_CPU 1000000UL
2
#include<avr/io.h>
3
#include<util/delay.h>
4
5
intmain(void){
6
DDRC=(1<<DDC4);
7
8
for(uint8_ti=0;i<30;i++){
9
PORTC^=(1<<PORTC4);
10
_delay_ms(50);
11
}
12
}
Hier keine Ergänzung für Linker und kein "erase", sondern "manged by script"
So weit klappt das auch beim ersten mal. Ändere ich jetzt aber einen Wert im Hauptprogramm (delay oder i), dann funktioniert der Bootloader weiterhin aber das Hauptprogramm "spinnt". Also die LED am Ausgang blinkt nicht oder nur einmal.
Nein, nicht alle mit USB!
z.B. der 32U4 kommt ab Werk mit einem Bootloader und dem schon angesprochenen HWB Pin und Fuse.
Dieser Bootloader ist aber entfernbar.
Die Atmel mit CAN (alle?) haben auch ab Werk einen Bootloader, dann eben über CAN und nicht über USB
Darum sagte ich ja:
Arduino F. schrieb im Beitrag #7858012:
Untersuche mal Atmel Flip
Tue das, lese die Dokus, dann machst du dich selber schlau.
Die Intention und das Vorgehen ist mir noch immer nicht ganz klar, aber ich arbeite dran (am Verständnis):
Sinn eines Bootloaders ist es, ihn mit dem Hex-File (typisch, kann aber auch eine andere Form sein) des Anwenderprogrammes zu füttern (z.B. per UART oder SDCard), und er schreibt das dann in das Flash. Der entsprechende Flash-Bereich muss gelöscht werden, dazu gibt es den intern ausführbaren Befehl 'Page Erase' (per SPMCSR).
Einen solchen (von außen ausführbaren) Befehl finde ich aber nicht in der Liste 'Serial Programming Instruction set', dort gibt es nur 'Chip Erase' - wie also (für Ihr 'Hauptprogramm')
Hier keine Ergänzung für Linker und kein "erase",
sondern "manged by script"
in diesem 'snap' funktionieren soll, verstehe ich nicht. Meine Vermutung ist, dass dort einfach 'drübergeschrieben' wird, was physikalisch einer VerUNDung gleichkommt und somit unsinnige Maschinenbefehle produziert - eigentlich müsste das Verify meckern.
Aber, wie schon angedeutet, ist Ihr Vorgehen an dieser Stelle wenig sinnvoll, was soll ein Anwenderprogramm nützen ohne komplett funktionierenden Bootloader?
eine Vermutung
ist, dass dort einfach 'drübergeschrieben' wird, was physikalisch einer
VerUNDung gleichkommt und somit unsinnige Maschinenbefehle produziert -
eigentlich müsste das Verify meckern.
Beim normalen Programmierablauf (codieren und dann Start Without Debugging) wodurch auch der Code an die beim Linker angegebene Adresse geschrieben wird, kommt es zu keiner Fehlermeldung.
Beim ersten Mal nach dem Übertragen der Bootloader-Sektion klappt's ja auch. Was passiert falsches beim zweiten Versuch das Hauptprogramm (mit leichten Änderungen) anderes?
Übertrage ich das .hex aber manuell, meckert verify. Was ich aber nicht verstehe, denn wieso soll das eine verUNDung sein? Wenn der Bootloader tatsächlich den Code ab 0x0000 schreibt, passiert doch eigentlich nichts anderes.
Der
entsprechende Flash-Bereich muss gelöscht werden, dazu gibt es den
intern ausführbaren Befehl 'Page Erase' (per SPMCSR).
Einen solchen (von außen ausführbaren) Befehl finde ich aber nicht in
der Liste 'Serial Programming Instruction set', dort gibt es nur 'Chip
Erase' - wie also (für Ihr 'Hauptprogramm')
Verstehe ich das dann richtig, daß ab 0x0000 erst einmal der Speicher gelöscht (0xff) werden müßte?
Was passiert falsches beim zweiten Versuch das Hauptprogramm
(mit leichten Änderungen) anderes?
Ablauf: der Bootloader wird 'geflashed', das beinhaltet ein 'Chip Erase'; damit ist auch der Bereich des Hauptprogrammes (ab 0x0000) gelöscht, d.h. mit 0xFF beschrieben. Wird nun das Hauptprogramm ohne /erase/ geflashed, dann ist das noch in Ordnung; nun aber stehen dort (ab 0x0000) Werte (die Maschinenbefehle) ungleich 0xFF, wird nun nachfolgend erneut dorthin geschrieben ohne /erase/, dann entsteht Unsinn: z.B. 0xAB UND 0xFF ergibt wieder 0xAB, aber 0xAB UND 0xIrgendetwas ergibt keineswegs 0xAB.
Wenn der Bootloader tatsächlich den Code ab 0x0000
schreibt, passiert doch eigentlich nichts anderes.
Oh doch, der Bootloader nutzt den internen Befehl 'Page Erase', diese Möglichkeit gibt es extern nicht, da gibt es nur 'Chip Erase'.
Verstehe ich das dann richtig, daß ab 0x0000 erst einmal
der Speicher gelöscht (0xff) werden müßte?
OK. Mir war nicht klar, daß beim programmieren quasi kein löschen der Bytes erfolgt. Steht das irgendwo? Oder ist das Wissen um Flash? Auf jeden Fall erklärt das meine Frage.
Nur aus Spaß/Verständnis: würde ich eine .hex-Datei erzeugen, die in den ersten 0x7000 0xFF beinhaltet und diese manuell übertragen, würde ich den Flash bis zum Bootloaderbereich "löschen" und könnte dann immer wieder neue Programme in den vorderen Bereich übertragen?
würde ich eine .hex-Datei erzeugen, die in den ersten 0x7000 0xFF
beinhaltet und diese manuell übertragen, würde ich den Flash bis zum
Bootloaderbereich "löschen
Nein. Ganz elementar: ein Bit im Flash kann nur mit einem speziellen Befehl auf 1 gesetzt werden, also intern per 'Page Erase' oder extern per 'Chip Erase'.
Dagegen ist nichts einzuwenden und wurde ja auch nichts eingewandt.
Aber das Manipulieren des unteren Flash-Bereichs, während oben der Bootloader völlig unbeteiligt sitzt, führt, wie gesehen, bestenfalls zu Missverständnissen und Problemen.
Dagegen ist nichts einzuwenden und wurde ja auch nichts eingewandt.
Aber das Manipulieren des unteren Flash-Bereichs, während oben der
Bootloader völlig unbeteiligt sitzt, führt, wie gesehen, bestenfalls zu
Missverständnissen und Problemen.
Naja. Die obigen Beiträge waren wie hier üblich sehr überheblich.
Was ist bei Dir "oben". Ich schrieb, daß das Bootloader-Blink-Teil im Bootloaderbereich liegt. Das ist für mich unten.
Nun ja, unter diesem Begriff steht es sicher irgendwo bei Wikipedia.
Und im Datenblatt des ATmega328 steht unter 'Self-Programming the Flash' "Before programming a page with the data stored in the temporary page buffer, the page must be erased". Womit sich mehr oder weniger direkt durchaus folgern lässt, dass ein einfaches Schreiben ins Flash nicht reicht.
Und im übrigen sitzen wir hier ja beisammen, um solche Fragen zu klären. Manchmal ist es etwas holprig, zugegeben.
Nun ja, unter diesem Begriff steht es sicher irgendwo bei Wikipedia.
Und im Datenblatt des ATmega328 steht unter 'Self-Programming the Flash'
"Before programming a page with the data stored in the temporary page
buffer, the page must be erased". Womit sich mehr oder weniger direkt
durchaus folgern lässt, dass ein einfaches Schreiben ins Flash nicht
reicht.
Also ich kann nicht aus einer allgemeinen Löschanweisung ablesen, daß diese notwendig ist, weil beim Beschreiben von Flash das Byte nicht als solches im Speicher landet.
Entspricht ja auch nicht gerade der Lebenserfahrung. Immerhin formatiere ich meine Festplatte (und selbst SSDs) nicht erst, bevor ich eine geänderte Datei speicher.
Und zu sagen "ließ 100 Dokumentationen, irgendwo wird's da schon stehen" empfinde ich als überheblich.
Also ich kann nicht aus einer allgemeinen Löschanweisung ablesen, daß
diese notwendig ist, weil beim Beschreiben von Flash das Byte nicht als
solches im Speicher landet.
Schreiben ins Flash erfolgt eben immer pro Seite. Die Seite muss erst gelöscht werden, dann kann die KOMPLETTE SEITE neu geschrieben werden.
Deshalb gibts den Page Buffer.
Was verstehst du daran nicht? Byteweises schreiben direkt ins Flash geht nicht.
Ich möchte an das Sprichwort erinnern, wonach es aus dem Wald herausklingt wie man hineinruft - schauen wir uns den Eröffnungsbeitrag an:
Mit etwas Glück wird Wilhelm Hauffs Märchenfigur noch mit einem gewissen Wohlwollen gesehen, mit etwas Pech aber murmelt der neutrale Beobachter vor sich hin
1
Bei euch, ihr Herrn, kann man das Wesen
2
Gewöhnlich aus dem Namen lesen
was dann durch den allerersten Satz bestätigt wird:
Ich will an einem Atmel 368 mit Bootloader spielen.
Pardon, aber mit dieser 'locker vom Hocker'-Attitüde sind schon 90 % des Kredits verspielt - also ich meine, Sie haben doch ein Anliegen und erwarten Hilfe, d.h. eine Leistung, geben sich aber nicht einmal das bisschen Mühe, die Controllerbezeichnung korrekt anzugeben: 'ATmega328'. Eine solche Selbstverständlichkeit ist keineswegs auf
hochtechnisch Intelektuelle
beschränkt.
Mit dem allgemeinen Umgangston hier im Forum bin auch ich alles andere als einverstanden, aber Sie provozieren ihn geradezu. Was nach zwei Jahren Mitgliedschaft auch bekannt sein müsste.
Letztlich aber wurde die Frage
Wo ist mein Denkfehler?
doch zufriedenstellend beantwortet, nicht wahr? Es haben mehrere Leute teilweise einige Zeit investiert.
Dann möchte ich abschließend, ebenfalls aus der Märchen/Fabel-Welt, zitieren: "... und den Dank such ich vergebens ...".
Und ja, es ist dein Problem, wenn du zu faul bist dir da die richtigen rauszusuchen.
Zu erwarten, dass ich das für dich tue ist, irrational überzogen.
Ein Verhalten, wie ein verwöhntes trotziges Kleinkind.
Entspricht ja auch nicht gerade der Lebenserfahrung. Immerhin formatiere
ich meine Festplatte (und selbst SSDs) nicht erst, bevor ich eine
geänderte Datei speicher.
Dann kann ein Teil deiner Lebenserfahrung in die Tonne.
Denn eine SSD macht intern nix anderes.
So so...
Überheblich!
Mir scheint es eher so zu sein, dass ich dir in Sachen AVR Kompetenz deutlich überlegen bin.
Bedenke:
Überhebliche Leute (wie z.B. du) neigen dazu, ganz dämlich auf die Fresse zu fallen. Sich zu blamieren. Irgendwann. Wenn das dumme Getue die Kompetenzschwächen nicht mehr überdecken kann.
Zum Glück kann mir das kaum passieren, da erstens meine AVR Kompetenz schon ein ordentliches Level erreicht hat und ich zweitens keine Scheu habe weitere Dokus zu lesen, wenn mir da ein Mangel auffällt.
Tipp:
Es gibt einen Unterschied zwischen Überlegen und überheblich.
Also ich kann nicht aus einer allgemeinen Löschanweisung ablesen, daß
diese notwendig ist, weil beim Beschreiben von Flash das Byte nicht als
solches im Speicher landet.
Das ist Grundlagenwissen zum Flashspeicher. Aber auch da gibt es Unterschiede zu NAND-Flash und NOR-Flash. Löschen muss man beide vor dem Beschreiben. Das Wissen sollte man sich angeeignet haben wenn man mit dem Themen wie hier zu tun hat.
Immerhin formatiere ich meine Festplatte (und selbst SSDs) nicht erst,
bevor ich eine geänderte Datei speicher.
Klar, in einer SSD ist auch Flashspeicher. Aber du hast keinen direkten Zugriff. Dort ist ein SSD-Controller verbaut, der den Flash-Block(!), in dem sich die Page befindet, erst einmal löscht. Das bekommst du garnicht mit. Ja, Flash löschen arbeitet in einer SSD Block basiert. Ein Block enthält dabei mehrere Pages. Es wird also zuviel gelöscht. Damit deine Daten dabei nicht verloren gehen, werden sie vorher woanders hin kopiert. Das bekommst du auch nicht mit. Das macht der Controller alles in seinem "Flash Management". Stichworte wie Bad Block Management oder auch Wear Leveling sind da wichtig. Aber das zur SSD beschriebene findet alles nicht in dem Flash deines AVRs statt. Der ist etwas einfacher gestrickt, nur Löschen muss man eine Page (keinen Block!), bevor man diese richtig beschreiben kann.
Die Welt um Flash-Speicher ist deutlich komplizierter, als du vermutlich gerade ahnst.
Edit: Das Bad Block Management und Wear Leveling ist reichlich komplex. Deshalb haben große Hersteller Patente auf ihre Verfahren.
Naja. Die obigen Beiträge waren wie hier üblich sehr überheblich.
Was ist bei Dir "oben". Ich schrieb, daß das Bootloader-Blink-Teil im
Bootloaderbereich liegt. Das ist für mich unten.
Für dich mag das so sein. Es gibt Controller, da liegt der Bootloader im oberen Adressbereich und andere, da liegt er am Anfang (bei 0x0).
Um keine Verwirrung aufkommen zu lassen ist es wichtig, sich präzise(!) auszudrücken. Diese Forderung hat nichts mit Überheblich zu tun.
