Forum: Compiler & IDEs Problem mit do_copy_data, bootloader und lockbits


von alex (Gast)


Lesenswert?

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

von Peter D. (peda)


Lesenswert?

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

von Martin T. (mthomas) (Moderator) Benutzerseite


Lesenswert?

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.

von alex (Gast)


Lesenswert?

> 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

von Peter D. (peda)


Lesenswert?

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.

von alex (Gast)


Lesenswert?

Ich danke für die Infos, hab alles kapiert. Werde nun die BLB's nicht 
programmieren.

Alex

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
Noch kein Account? Hier anmelden.