ATmega // PIC

[Softboy1]

Hallo
Das heißt wenn der Lockmittel gesetzt wurde, kann er nie mehr gelöscht und neu programmiert werden?
Oder ist er dann nicht mehr aus zu lesen?

Gr.
Softboy1

[PICture]

Ein Programm aus einem gelockten PIC Mikrocontroller (µC) ist nur nicht mehr lesbar. Der µC kann aber gelöscht und neu programmiert werden.

[021aet04]

Du musst im Datenblatt des jeweiligen uC schauen. Z.B. beim Atmega48/88/168 gibt es 2 Lockbits mit denen du 3 Modes wählen kannst. Standartmäßig sind beide 1, kein Lock ist aktiv. Dann gibt es noch eine Sperre gegen das Programmieren von Flash, EEPROM und Fuses mit serieller und paralleler Programmierung. Der 3 Mode ist gleich wie der 2te nur das auch noch die Überprüfung gesperrt ist.

MfG Hannes

[RoboHolIC]

Exkurs bzw. Ergänzung zur Programmierbarkeit:

Bei PIC-Controllern (und meines Wissens nicht dort) kann man sich aber auch komplett aussperren, indem man den Resetpin zum I/O-Pin macht.
In diesem Zustand kann der Chip (mangels Reset-Pin ) regulär weder gelesen noch gelöscht noch (um)programmiert werden.
Eine Entsperrung von PICs ist dann nur noch mit Tricksereien jenseits der Spezifikation möglich und kann zur Zerstörung des Chips führen.

[Ceos]

beim ATMega wird der Reset Pin einfach mit 10V angesteuert um den Reset auszulösen wennd er Pin abgeschalten ist und ich meine auch beim PIC gibt es einen Programmiermodus dem der gesperrte Reset Pin ziemlich egal ist.

[Klebwax]

In diesem Zustand kann der Chip (mangels Reset-Pin ) regulär weder gelesen noch gelöscht noch (um)programmiert werden.
Eine Entsperrung von PICs ist dann nur noch mit Tricksereien jenseits der Spezifikation möglich und kann zur Zerstörung des Chips führen.

Quatsch. Jeder anständige Programmer kann das ohne irgendwelche Specs zu verletzen.

MfG Klebwax

[PICture]

Bei PIC-Controllern (und meines Wissens nicht dort) kann man sich aber auch komplett aussperren, indem man den Resetpin zum I/O-Pin macht.

Ich kann nur bestätigen, dass es passieren kann, wenn der Resetpin zum Ausgang programmiert wird.

[Klebwax]

Ich kann nur bestätigen, dass es passieren kann, wenn der Resetpin zum Ausgang programmiert wird.

Das ist nicht so.

beim ATMega wird der Reset Pin einfach mit 10V angesteuert um den Reset auszulösen wennd er Pin abgeschalten ist und ich meine auch beim PIC gibt es einen Programmiermodus dem der gesperrte Reset Pin ziemlich egal ist.

Richtig, man muß MCLR auf Vpp bringen, dann kann man den Chip löschen und neu programmieren. Und das ist auch nicht jenseits der Specs.


Ich zeig jetzt nicht Ausschnitte aus allen PIC-Datenblättern, aber entsprechendes findet sich auch dort.

MfG Klebwax

[PICture]

In Datenblätter von PICs steht nix über Programmierung. Nur die neuere PICs lassen sich mit Vpp = 5V Programmieren. Die älteren benötigen dafür höhere Spannung Vpp.

Another issue with MCLR/VPP is that when the PICmicro device is programmed, this pin is driven to approximately 13V and also to ground.

[RoboHolIC]

Richtig, man muß MCLR auf Vpp bringen, dann kann man den Chip löschen und neu programmieren. Und das ist auch nicht jenseits der Specs.


Ich zeig jetzt nicht Ausschnitte aus allen PIC-Datenblättern, aber entsprechendes findet sich auch dort.

Ist auch nicht nötig, denn das dürfte ein Ausschnitt aus den Maximum Ratings sein - das sagt in diesem Zusammenhang alles und nichts aus.

Aber gut, ich beuge mich ohne Ironie dem geballten Fachwissen. Dann ist das wohl auch ein Missverstehen aus meiner Anfangszeit.

Sprut.de schreibt zwar über eine Falle, wenn MCLR als I/O in Verbindung mit dem Internen Oszillator konfiguriert wird. Er erklärt dabei, dass der fehlende externe Reset beim Programmieren das Stoppen des Oszillators und damit ein Hochzählen des Program Counters nicht verhindern kann.
Und dass dadurch der Programmiervorgang in Unordnung gerät.

Vielleicht gilt das aber nur für die einfachsten Programmer-Hard- und Softwares und kommt mit Geräten a la PICkit2/3 und MPLAB(X) gar nicht zum tragen.
(Die Spec-Verletzung, derer ich mich erinnere, betraf im Übrigen das Timimg zwischen PowerUp- und /MCLR-Vpp, aber was soll's, ich finde nichts davon wieder).

Danke Euch, damit hätte sich ja eine gefürchtete Fehlerquelle in Luft aufgelöst.