Lock bits vs. Clock source auf 8-Bit AVRs

[Stefan (Gast)]

Ist es richtig, das ich die Taktquellen Fuses (CKSELX) nicht mehr 
programmieren kann, wenn ich die Lockbits (LBX) programmiert habe?

Oder kann ich doch einerseits durch die Lockbits das neu-programmieren 
und auslesen des Prozessors verhindern, aber gleichzeitig das 
neu-Programmieren der Bits für die Taktquelle erlauben? Vielleicht auf 
einem unkomentierten weg, oder aus dem Bootloader heraus?

[Stefan (Gast)]

Ich meine die AVR 8-Bit RISCs, also z.B. ATMEGA. (Nix 8051 oder so).

[Benedikt K. (benedikt)]

Stefan wrote:
> Ist es richtig, das ich die Taktquellen Fuses (CKSELX) nicht mehr
> programmieren kann, wenn ich die Lockbits (LBX) programmiert habe?

Ja. Aber was spricht dagegen, die Fusebits vor den Lockbits zu 
programmieren ?

[Stefan (Gast)]

>Aber was spricht dagegen, die Fusebits vor den Lockbits zu programmieren ?

Es wäre nützlich gewesen die Fusebits nach den Lockbits zu 
programmieren. So wäre es möglich einen beim Kunden befindlichen 
Prozessor, dessen Lockbits programmiert sind, etwa auf eine andere 
Taktquelle umzustellen. .Z.B. wenn der interne RC-Oszillator so 
abweicht, das die Baudrate nicht stimmt, andererseits aber von ext. 
Quarz auf int. RC-Osz. umschalten, wenn er (der Kunde) es möchte. 
Dennoch wäre es dem Kunden nicht möglich das Programm wieder auszulesen.

Es gibt da so eine ungenutzte Kombination der LBX bits.
LB2 = 0 und LB1 = 1. Wenn man der Beschreibung folgt, dann könnte es 
sein, das man damit zwar das auslesen, aber nicht das programmieren 
verhindert.
Hat das schon mal jemand ausprobiert?

[Benedikt K. (benedikt)]

Dann hast du aber auch die Software dabei. Also machst du ein Chiperase, 
setzt die Fusebits, flashst die Software rein und setzt wieder die Lock 
Bits.

[Stefan (Gast)]

>Dann hast du aber auch die Software dabei.

Moment. Ist das ein Missverständnis? Ich habe die SW. Aber nicht 
dabei. Ich bin ja nicht bei dem Kunden. Und er hat die SW nicht. Die 
wird auf dem Prozessor ausgeliefert.

[Benedikt K. (benedikt)]

OK, dann bist du aber ganzschön leichtsinnig:
- Einen Kunden nie etwas selbst programmieren lassen (außer das Ding hat 
einen Idiotensicheren Bootloader)
- Nie den internen Oszillator für den UART verwenden (außer vielleicht 
zum Debuggen)

[Stefan (Gast)]

>Einen Kunden nie etwas selbst programmieren lassen (außer das Ding hat
>einen Idiotensicheren Bootloader)
Lasse ich ihn ja nicht. Er bekommt einen fertig programmierten Prozessor 
dessen Lock-Bits gesetzt sind.

>Nie den internen Oszillator für den UART verwenden.
Schnief. Heul. ;-) Darauf läuft es dann hinaus. Muss wohl den externen 
verwenden.

Wie gross ist eigentlich ungefähr so ein entschlüsselnder Bootloader 
(AES oder sowas)?

[Stefan (Gast)]

Ich schrieb:

>Wie gross ist eigentlich ungefähr so ein entschlüsselnder Bootloader
(AES oder sowas)?

Aber das nützt mir ja nichts. Die Fuses für die Taktquelle kann er dann 
ja trotzdem nicht selbst programmieren, wegen der Lock-Bits.
Mist.

[Knut B. (Firma: TravelRec.) (travelrec)]

Ein Kunde sollte den Takt des Controllers nicht ändern müssen / können. 
Das ist eine zusätzliche und unkalkulierbare Fehlerquelle. Stell Dir 
vor, der Kunde fust dummerweise auf externen R/C-Oszillator und da ist 
weit und breit kein R und kein C dran. Und tschüß! Generell sollte ein 
Kunde überhaupt nichts an der ISP-Schnittstelle zu suchen haben. 
Bootloader drauf, alle Fuses so setzen, wie sie müssen, Lockbits setzen 
und fertich! Updates werden über externe Schnittstellen (UART/RS232, 
Ethernetcontroller, Funk-Modul etc.) erledigt. Die Verschlüsselung muß 
nicht unbedingt AES sein, Du kannst Dir auch selber etwas ausdenken.

[Sven P. (Gast)]

Hatten wir nicht mal Programmer-Dongles diskutiert? Also: In der 
Anwendung wird der Controller verbaut und mit einem Bootloader 
ausgestattet. Nach außen hin dann eine gescheite Schnittstelle.

Muss der Kunde nun das Dingchen neuprogrammieren, bekommt er einen 
Dongle geschickt: Der besteht aus Batterie, Schnittstelle und ebenfalls 
einem Controller und dient quasi als Programmträger. Der flasht dann den 
Controller in der Anwendung und wird dann dem Hersteller 
zurückgeschickt.

Quasi eine Diskette, die mitdenkt.