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?
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.
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
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.
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
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.