hallo allerseits
habe eine applikation auf einem ATmega88 welche wunderbar läuft, solange
die BLB's nicht aktiviert werden. nach dessen aktivierung lässt sich das
programm nicht mehr starten. die applikation verwendet keinen
bootloader, die entsprechenden fuses sind auf standard. applikation
benötigt 6710 bytes im flash (kommt also knapp in die default
bootloader-section rein).
die analyse des lss-files zeigt 0 spm befehle, allerdings aber ein lpm
auf adresse 0x4c (gehört zu do_copy_data).
developpement-umgebung ist:
- winxp sp3
- eclipse 3.3.1.1
- cdt 4.02
- WinAVR-20080430
fragen:
1. verhindert diese lpm instruktion die verwendung der BLB's?
2. was ist das do_copy_data? brauch ich das? (kann keinen rjmp oder
rcall darauf finden, ist allerdings etwas schwierig, da alles relativ
adressiert)
3. wie kann ich das problem umgehen?
4. sehe ich das richtig, dass die bootloader-section nicht auf 0 bytes
(also keine) gesetzt werden kann?
danke im voraus und gruss
alex
alex wrote:
> habe eine applikation auf einem ATmega88 welche wunderbar läuft, solange> die BLB's nicht aktiviert werden. nach dessen aktivierung lässt sich das> programm nicht mehr starten.
Welchen Sinn soll es haben, die BLBs zu setzen, wenn Du garkeinen
Bootloader benutzt?
Du verwendest wohl Interrupts und laut Datenblatt sind dann die
Interrupts gesperrt bei Ausführung im Bootbereich.
> 3. wie kann ich das problem umgehen?
Bits, die Du nicht brauchst, einfach in Ruhe lassen.
Peter
alex wrote:
> habe eine applikation auf einem ATmega88 welche wunderbar läuft, solange> die BLB's nicht aktiviert werden. nach dessen aktivierung lässt sich das> programm nicht mehr starten.
Durcheinander: "die BLB's ... dessen". Wie ist die Einstellung der
einzelnen Lock- und Boot-Lock-Bits? Welche BLB0 und BLB1 Modi sind
angestrebt? Und wie schon gefragt - warum?
Nehme an, es wurden einfach mal nach dem Moto "mein Programm ist so
geheim/einzigartig, alles was lock im Namen hat muss aktiviert sein"
alle BLB-Bits programmed wurden, ohne Beschreibung der BLB-Modi 3
nachzuvollziehen.
> die applikation verwendet keinen> bootloader, die entsprechenden fuses sind auf standard.
BOOTRST sicher unprogrammed?
> applikation> benötigt 6710 bytes im flash (kommt also knapp in die default> bootloader-section rein).
Erstmal ausschließen, dass Ursache unnötige/unbrauchbare BLB0/1-Modi
und/oder Einstellung für Interrupt-Vector sind. Dann kann man
weitersuchen.
> die analyse des lss-files zeigt 0 spm befehle, allerdings aber ein lpm> auf adresse 0x4c (gehört zu do_copy_data).>> developpement-umgebung ist:> - winxp sp3> - eclipse 3.3.1.1> - cdt 4.02> - WinAVR-20080430>> fragen:> 1. verhindert diese lpm instruktion die Verwendung der BLB's?
"Der BLB's" ist zu pauschal. Mir fällt dazu auch nur das von Peter
Dannegger schon geschriebene betr. (wahrscheinlich ohnehin unnützem)
BLB0/1-Modes >=3 und Interrupt-Vector-Placement ein.
> 2. was ist das do_copy_data?
Kopiert die Anfangswerte der initialisierten Variablen aus dem Flash ins
RAM, also zwangsläufig (E)LPM darin enthalten.
> brauch ich das?
Wenn man nicht weiß, was das ist: wahrscheinlich ja. Ansonsten:
__data_end-__data_start > 0 -> wird gebraucht
> (kann keinen rjmp oder> rcall darauf finden, ist allerdings etwas schwierig, da alles relativ> adressiert)
Ist im startup, vgl.
http://cvs.savannah.gnu.org/viewvc/avr-libc/crt1/gcrt1.S?revision=1.12.2.1&root=avr-libc&view=markup> 3. wie kann ich das problem umgehen?
Zu wenig Information - zumindest für mich. Evtl. einfach die Finger von
Boot-Lock-Bit lassen und einfach die LB-Bits verwenden.
> 4. sehe ich das richtig, dass die bootloader-section nicht auf 0 bytes> (also keine) gesetzt werden kann?
Ja.
> Nehme an, es wurden einfach mal nach dem Moto "mein Programm ist so> geheim/einzigartig, alles was lock im Namen hat muss aktiviert sein"
es werden immerhin pro jahr ein paar tausend stk. davon verkauft. es
macht schon einen gewissen sinn, auf schutz zu achten, sonst geht es ein
halbes jahr und die chinesen werfen das selbe produkt zu einem viertel
des preises auf den markt, womit wir hier nicht mehr marktfähig wären.
> alle BLB-Bits programmed wurden, ohne Beschreibung der BLB-Modi 3> nachzuvollziehen.
stimmt teilweise, habs schon nachgelesen, aber evtl. zu wenig genau.
> BOOTRST sicher unprogrammed?
ja, klar. so doof bin ich nun doch wieder nicht.
die vektortabelle ist auf adresse 0, LB mode = 3, BLB0&1 mode hab ich
auch 3 angestrebt.
im datenblatt steht:
"If Interrupt Vectors are placed in the Application section, interrupts
are disabled while executing from the Boot Loader section."
sehe ich das richtig, dass wenn programm-code aus der BL-section
ausgeführt wird, die interrupts deaktiviert sind? da meine applikation
in die BL-section reinkommt, würden damit zu gewissen zeiten die
interrupts nicht ausgeführt, das ist natürlich nicht gewünscht.
macht es null sinn die BLB's zu programmen wenn der bootloader NICHT
verwendet wird? eine bootloader-section existiert ja sowieso, ob ich den
nun brauche oder nicht.
meine letzte frage (ACHTUNG!!!: es macht evtl. keinen sinn, würde es
aber der verständnis halber trotzdem gerne wissen):
angenommen meine applikation befindet sich nur in der application
section (bootloader-section ist leer, unused), es gibt keine spm's und
nur ein lpm um die daten zu initialisieren, könnten dann die BLBx modes
auf 3 gesetzt werden, ohne die funktion zu beeinträchtigen?
gruss
alex
alex wrote:
> macht es null sinn die BLB's zu programmen wenn der bootloader NICHT> verwendet wird?
Ja.
Lt. Datasheet beeinflusssen sie in keinster Weise das SPI- oder Parallel
Programming und damit verbundene Angriffsversuche.
Sie beeinflussen allein die interne Ausführung von SPM, LPM und
Interrupts.
Ohne Bootloader bewirken sie also nur eine Störung des internen Ablaufs.
Ihre Aufgabe ist z.B. eine versehentliche Selbstzerstörung des
Bootloaders zu verhindern oder nur wenige Updates per Bootloader
zuzulassen.
Peter
P.S.:
Lt. einem AVRfreaks-Post gibt es Dienstleister, die zu moderaten Kosten
(dreistellig) jeden AVR auslesen.
Eine eigene Frage?
Dieser Thread ist über 18 Jahre alt.
Stell sie in einem eigenen Thread – dort lesen mehr Leute mit, und sie wird öfter und schneller beantwortet.