www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Lock bits vs. Clock source auf 8-Bit AVRs


Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Stefan (Gast)
Datum:

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

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ?

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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?

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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)

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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)?

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.