Hallo Zusammen! was mache ich denn nun wieder falsch: der Aufruf #include <avr/io.h> #include <avr/ina90.h> #include <avr/interrupt.h> #include <avr/signal.h> #include <avr/pgmspace.h> #include <avr/boot.h> #include <avr/eeprom.h> char bits; bits =....; boot_lock_bits_set(bits); resultiert in wüsten Beschimpfungen des Compilers an meine Code: 'BLB01' undeclared (first use in this function) 'BLB02' undeclared (first use in this function) 'BLB11' undeclared (first use in this function) 'BLB12' undeclared (first use in this function) muss ich denn noch mehr AVR-Header einbinden oder mache ich nur den Aufruf falsch?? Gruß Martin
Die hat Eric B. Weddington im boot.h verwendet, aber vergessen zu definieren. Peter
was muss ich denn da machen? selber etwas definieren, und wenn ja was?? Gruß Martin
Genau. Datenblatt zur Hand nehmen und selber definieren. Wenn ich das richtig verstanden habe, lassen die sich aber nicht wieder löschen. Ist also eine Einbahnstraße. Peter
Vermutlich hat Eric erwartet, daß die jeweiligen <avr/ioXXX.h> Files diese Bits definieren. Martin, schreib mal einen Bugreport auf savannah.nongnu.org dafür.
Hallo Jörg, ich habe leider keine Zeit, mich durch die savannah.nongnu.org zu wühlen, um einen Bug-Report abzusetzen. Deshalb meine Bitte an Dich: Copy and paste mit folgemdem Text: Bug Report: "Problem" by using the library function "boot_lock_bits_set" ATmega64, maybe more cpu's, too GCC-Compiler, version 3.3.1 #include <avr/io.h> #include <avr/ina90.h> #include <avr/interrupt.h> #include <avr/signal.h> #include <avr/pgmspace.h> #include <avr/boot.h> #include <avr/eeprom.h> char bits; bits =....; boot_lock_bits_set(bits); results in some error code: 'BLB01' undeclared (first use in this function) 'BLB02' undeclared (first use in this function) 'BLB11' undeclared (first use in this function) 'BLB12' undeclared (first use in this function) it looks like a missing define for BLBxy. Greetings from Germany Martin Gruß Martin
Mal rein theoretisch: Es gibt ja von Atmel diesen DES-Bootloader. Damit soll man ja updaten können, ohne dass jemand an den Quellcode kommen kann. Welchen Sinn macht das aber, wenn die Lockbits deaktiviert sein müssen, damit der Loader schreiben kann? Oder kann der Bootloader sogar schreiben, wenn der Schreibschutz aktiviert ist (wohl kaum)? Sonst könnte man den Bootloader ja updaten lassen und dann den dechiffrierten Code aus dem Speicher holen. Oder schmeiss ich da ein paar Sachen durcheinander? Henrik
tja, ich bin gerade dabei, diesen Bootloader auf GNU zu portieren, aber kämpfe noch mit allerlei inkompatibiläten. Auf dem IAR-Compiler habe ich ihn auch noch nicht zum laufen bekommen. Deine Fragen werde ich daher erst in kürze beantworten können. Z.Z. ich vermute, man kan die Lockbits schon irgend wie so setzen, dass man das Ding nachflashen kann, ohne aber das Flash auslesen zu können. Am besten hilfst du mir bei der Entwicklung, umso schneller kann ich deine Fragen beantworten :-) Gruß Martin
"Oder schmeiss ich da ein paar Sachen durcheinander?" Ja. Es gibt die Hardwarelockbits und nur die haben Einfluß auf Programmierung per High-Voltage, SPI oder JTAG. Die müssen also immer nach dem Brennen eines sicheren Bootloaders gesetzt werden. Dann gibt es die Softwarelockbits und nur die haben Einfluß auf den SPM-Befehl. Die sind dann allerdings für die Ewigkeit, also fürs Updaten völlig witzlos. Peter
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.