ATmega Bootloader Lock Bits

[hahgeh (Gast)]

Hallo,

ist es eigentlich möglich die Lock Bits so einzustellen, dass ein 
erneutes Programmieren und Verifizierung über den Bootloader möglich 
ist, ohne dass der Code nachher ausgelesen werden kann?

Die normalen Lockbits müssen ja sowieso beide gesetzt sein, damit ein 
Auslesen über SPI verhindert wird.

Zu den BootLockBits:
Wenn ich alles sperre, außer das Schreiben in die Application Section 
von der Bootloader Section aus, dann kann ich zwar das Auslesen 
verhindern und das Programmieren ermöglichen, ich kann aber nicht mehr 
verifizieren, ob der Code richtig aufgespielt wurde. (höchstens noch 
beim ersten Mal, wenn ich die BootLockBits nach dem verifizieren setze)
Theoretisch müßte man die BootLockBits zusammen mit dem Code löschen 
können, um sie nach dem verifizieren wieder zu setzen.

Aber so viel ich weiß, kann das dazu erforderliche ChipErase Kommando 
nur über SPI ausgeführt werden.

Gibt es überhaupt eine Lösung für mein Problem?

[TravelRec. (Gast)]

Solange Du das LPM in der Applikationssektion nicht sperrst, kann Dein 
Bootloader diese lesen und ausgeben. Der Chip ansich ist über SPI dann 
nicht auslesbar. Deinen Bootloader kannst Du mittels Passwort zum 
Auslesen bewegen. Bootlockbits umschreiben geht immer nur im 
Zusammenhang mit ChipErase.

[Martin Thomas (Gast)]

Habe bei einer ähnlichen Aufgabe das Problem per "Verschlüsselung" 
gelöst:
- SPM/LPM Bootsection gesperrt
- SPM/LPM Applicationsection freigegeben
- "further" Programming gesperrt
- Hex-Datei wird mit einem PC-Programm verschlüsselt (hat aber weiterhin 
Hex-Format)
- Bootloader nutzt AVR109-Protokoll
- Daten aus verschlüsselter Hex-Datei werden per AVRProg oder AVRDude 
zum Bootloader übertragen
- Bootloader entschlüsselt und schreibt Inhalt ins Flash
- beim Verify verschlüsselt der Bootloader die Daten aus dem Flash 
wieder bevor sie gesendet werden
- Programmiersoftware vergleicht die verschlüsselten Daten vom 
Bootloader  mit den Daten im verschlüsselten Hex-File

Vorteile:
- Standard-Programmiersoftware nutzbar - man muss nichts extra schreiben 
(z.B. für Passwort), Kunde kann gewohntes Tool nutzen
- Bereits vorhanden Bootloadercode genutzt, nur Verschlüsselungs- und 
Entschlüsselungsfunktion ergänzt - hat Arbeit gespart
- Programmcode ist nie in Klarschrift sichtbar (Datei per e-mail zum 
Kunden, Kopierschutz)
- Verify mit der verschlüsselten hex-Datei jederzeit möglich
- erneutes Programmieren jederzeit möglich
- "Fremde" unverschlüsselte Software kann zwar auf den Controller 
übertragen werden, funktioniert aber nicht, da sie nicht zu "sinnvollem" 
Maschinencode entschlüsselt wird.

Nachteil:
- Bootloadercode wird größer
- Unterschied "verschlüsselt-unverschlüsselt" nicht direkt 
offensichtlich (beides hex-Dateien, Vorgehensweise auf Kundenseite wie 
bei unverschlüsselten Dateien)

Atmel hat auch einige AppNotes betr. Verschlüsselung und Bootloader, 
grade aber nicht erinnerlich, wie die das "Verify-Problem" gelöst haben

Nun denn, viel Prosa. Vielleicht dennoch als Hinweis nützlich.
Martin Thomas

[hahgeh (Gast)]

Das mit der Verschlüsselung hört sich sicher an. Da wird dann aber wohl 
nicht mehr 1 kByte für den Bootloader reichen. Aber es ist wohl die 
einzige Möglichkeit.
Wirklich schade, dass man nicht so ein "Application-Section-Chip-Erase" 
hat.

[Irosenhagen (Gast)]

Hey,

welche Lock-Bits genau muss ich denn setzen, damit das Auslesen des 
Programmes  verhindert wird?

Beim Atmega 2561 würd ich jetzt nach Datenblatt LB-Mode 3 setzen.
"Further programming and verification is disabled...."

Bei den Bits des BLB Modes bin ich mir unsicher, was die Auswirkungen 
auf Interrupts betrifft.

mfg