www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik security bits im PIC nicht zurücksetzbar


Autor: Daniel Re. (danielr)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

kennt jemand folgendes Problem?

Gestern habe ich die "Disable Code Protection" Sequenz (gemäss der 
Application Note "PIC16FF62X Eeprom Memory Programming Specification") 
mal mit knapp unter 12V ausgeführt und seitdem lassen sich im 
Configuration Word die Security Bits nicht mehr zurücksetzen - sprich 
Programmieren geht nimmer mehr.

Auch mit Vpp 13V an MCLR bleiben die Bits im Configuration Word auf 
0x02B9 stehen.

Ich bin ratlos - hat jemand eine Ahnung?

Gruß,

Daniel

Autor: Daniel Re. (danielr)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nachtrag:
Dass das Configuration Word 0x02B9 ist lag an einem Bug im 
Brennerprogramm, der statt 0x3Fxx eine 0x0 ins Configuration Word 
geflasht hat.

Hat jemand schon mal Probleme beim Zurücksetzen der Security Bits auf 1 
gehabt?

Autor: Michael L. (michaelx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Schritte unter "3.3 Disabling Code Protection" führst du doch nicht 
selbst aus, dass muss die Brenn-SW machen. - Oder schreibst du die grad 
selbst? Wenn nicht:
Es wäre ja möglich, dass deine Brenn-SW diese Sequenz überhaupt nicht 
beherrscht, sonder immer nur ein einfaches Bulk Erase durchführt. 
Probiere doch mal ein anderes Programm.

Autor: Daniel Re. (danielr)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Brennsoftware habe ich selbst geschrieben und führt die in der 
Spezifikation beschriebene Sequenz aus.

Was ich auch bemerkt habe:
Die Sequenz setzt das Configuration Word auf 0x0200 zurück.
Wenn man die Sequenz aber so abändert, dass das erste 
LoadConfigurationCommand statt 0x0 z.B. 0x3FB9 lädt, so ergibt ein 
Auslesen des Configuration Words nach der Sequenz 0x02B9 (d.h. alle Bits 
ausser die Codeprotection Bits werden gesetzt).
Weiterhin:
Die Bits in den ID Locations lassen sich von 1 auf 0 setzen (beim 
Versuch das Configuration Memory zu programmieren gemäss Figure 3-4 in 
der Spezifikation), aber ein Zurücksetzen der ID Locations auf 0x3FFF 
ist nicht mehr möglich mit der "Disable Code Protection" Sequenz.

So ganz verstehe ich das nicht, funktioniert hat das ganze ja schon 
vorher - bis zu dem Punkt wo das Configuration Word versehentlich auf 0 
programmiert wurde.
Das Zurücksetzen der Protection Bits auf 1 macht mir Probleme...

Viele Grüße,

Daniel

Autor: Michael L. (michaelx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hast du es mit einer anderen Brenner-SW probiert?

Ich verwende die hier, zusammen mit einem Eigenbau-Programmer.
http://people.freenet.de/dl4yhf/winpicpr.html
Sie ist per Config-File für beliebige Brenner (LPT und COM) anpassbar.

Und dann habe ich noch einen ICD2-Clone ähnlich dem hier:
http://stolz.de.be/

Autor: Daniel Re. (danielr)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das wird mit meinem Brenner leider nicht gehen, den habe ich auch selbst 
gebaut (serielle Schnittstelle -> MAX232 -> PIC16F628 -> TargetPic (hier 
auch PIC16F628).
Ich werde mir aber mal den Code von anderen DIY-Brennern mal anschauen, 
vielleicht gibt es ja doch einen undokumentierten Unterschied zur 
Spezifikation (den Abschnitt "Disable Code Protection" betreffend).

Autor: Daniel Re. (danielr)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Könnte mir ggf. jemand mit seinem Brenner bei meinem PIC16F628 die 
Security Bits zurücksetzen?
Damit könnte ich feststellen, ob's am PIC liegt (wenn's dann auch nicht 
funktioniert) oder mit meinem Brenner was nicht stimmt.
(Vorzugsweise im Raum München)

Viele Grüße,

Daniel

Autor: Daniel Re. (danielr)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Beim Vergleich mit den Sourcen der anderen Brenner ist mir aufgefallen, 
dass die Sequenz für "Disable Code Protection" oftmals voneinander 
abweicht.
Wie hat denn die richtige Sequenz für den PIC16F628 auszusehen?

Wenn man sich den DATA-pin anschaut müsste man ja laut Spezifikation 
folgendes sehen (abgesehen vom timing):

- 000000 (6 Bits für load configuration command)
- 0000000000000000 (16 Bits data für das load configuration command)
- 011000 ( 6 Bits für increment command)
- 011000 "
- 011000 "
- 011000 "
- 011000 "
- 011000 "
- 011000 "
- 100000 ( 6 Bits für bulk erase setup 1 command)
- 0111111111111110 (16 bits dummy data für bulk erase setup 1 command)
- 111000 ( 6 Bits für bulk erase setup 2 command)
- 0111111111111110 (16 bits dummy data für bulk erase setup 2 command)
- 000100 ( 6 Bits für begin erase/programming cycle command)
- 0111111111111110 (16 bits dummy data für begin erase/programming cycle 
command)
- 100000 ( 6 Bits für bulk erase setup 1 command)
- 0111111111111110 (16 bits dummy data für bulk erase setup 1 command)
- 111000 ( 6 Bits für bulk erase setup 2 command)
- 0111111111111110 (16 bits dummy data für bulk erase setup 2 command)

Bei so manch anderer Brennersoftware wird am Anfang statt 0x0000 eine 
0x3FFF für das load configuration command als data gesendet.
Und meist werden bei den bulk erase setup X commands die 16 bits dummy 
data auch weggelassen.

Hab auch schon diese Kombinationen leider erfolglos durchgetestet...

Autor: Michael L. (michaelx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Daniel Re. schrieb:
> Das wird mit meinem Brenner leider nicht gehen, den habe ich auch selbst
> gebaut (serielle Schnittstelle -> MAX232 -> PIC16F628 -> TargetPic (hier
> auch PIC16F628).

Nein, damit wird es wirklich nichts mit meinem Vorschlag.
Frage: Warum hast du dir das angetan, eigene Benner-HW und Brenn-SW 
abseits von allem, was gebräuchlich ist?

Autor: Daniel Re. (danielr)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Michael,

letztenendes wegen dem Lerneffekt (Preislich macht das mittlerweile auch 
keinen Sinn mehr). Den ersten PIC (der auf dem Brenner den MAX232 mit 
dem Target-Pic verbindet) musste ich über eine Zwischenlösung brennen 
(Beitrag "PIC16F628 kaputt?").

Für den PIC16F628 funktioniert das Brennen nun, bis auf das "Disable 
Code Protection", wo ich mir noch uneins mit dem Ablauf aus der 
Spezifikation bin.

Viele Grüße,

Daniel

Autor: Daniel Re. (danielr)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Von microhip habe ich leider nur folgende Antwort erhalten:
"Unfortunatley Microchip will not be able to assist you with the 
debugging of your hardware or software issues related to ICSP.  However, 
what I can tell you is that a bulk erase is needed to reset the code 
protection bits and this must be done at a programming voltage of 4.5V 
or greater.  As a sanity check you may want to connect a programmer to 
the device and test the ability to enable and disable the code 
protection bits via ICSP."

Hat jemand bei sich Erfolg mit dem Setzen und Zurücksetzen der Security 
Bits beim PIC16F628 per Do-It-Your-Self-Brenner?
Wenn ja, welchen Brenner und welche Software verwendet Ihr?

Autor: Michael L. (michaelx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Daniel,

ich kann dir da nicht weiterhelfen.
Mein Tipp: Besorge/baue dir einen einfachen Programmer für COM oder LPT 
und passende SW dazu. Dann kannst du leicht nachprüfen, was deine 
Prog-SW geschrieben hat, und solche Fehler wie hier angefragt leicht 
beheben.

Autor: Bernd Wiebus (berndwiebus) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Daniel.

>  However,
> what I can tell you is that a bulk erase is needed to reset the code
> protection bits and this must be done at a programming voltage of 4.5V
> or greater.

Das ist doch mal ne Aussage, oder? Macht ja auch einen gewissen 
Sinn.....
Wenn man nur das bit zurücksetzt, wäre der zu schützende Code ja nicht 
mehr geschützt.
Bei "bulk erase" kannst Du es wieder resetten, wobei der Code aber mit 
gelöscht wird. Somit ist er vor unbefugtem Auslesen und Kopieren 
gesichert.
Jede andere Funktionalität würde ich als Bug ansehen. ;-)

> Wenn ja, welchen Brenner und welche Software verwendet Ihr?

Ich persönlich habe das Sicherheitsbit nie verwendet.....

Mit freundlichem Gruß: Bernd Wiebus alias dl1eic

http://www.dl0dg.de

Selbsterkenntnis ist der erste Schritt zur Depression.
Jeder echte Wettbewerb ist ruinös. Darum beruht jede funktionierende
Wirtschaft auf Schiebung.

Autor: Daniel Re. (danielr)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

vielen Dank für Eure Antworten!!

@Bernd: Ja, das war mir bekannt. Aber bei meinem Brenner haut das leider 
auch nicht hin (bzw. vielleicht ist der PIC ja kaputt).

Ggf. kann ich irgendwann mal mit einem anderen Brenner den PIC wieder 
hinbiegen und vergleichen wo die Unterschiede zu meinem Brenner liegen.
Ich würde das Thema nun erst mal auf Eis legen.

Viele Grüße,

Daniel

Autor: Michael L. (michaelx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hier ist noch ein relativ einfacher Programmer für den langsam 
aussterbenden Parallelport.

http://www.rotgradpsi.de/mc/picprog/picprog.gif

Leider war die SW von Martin Claußen nur für DOS, aber ich konnte diese 
SW entsprechend konfigurieren:
http://freenet-homepage.de/dl4yhf/winpicpr.html

Wolfgang Büschner hat die INI-Datei mit in sein Archiv aufgenommen, 
einfach selbstdefiniertes Interface am LPT und dazu Clausen_PICProgOnLpt 
auswählen, dann sollte es funktionieren.

Auszuführen ist WinPIC mit:
runas /USER:Administrator /env WinPic.exe %1
wegen der nötigen Rechte für HW-Zugriff.

HTH

Autor: Daniel Re. (danielr)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

mittlerweile hab ich mir den Wisp648 zusammengebaut und damit hat das 
Löschen vom PIC16F628 Config Word nun funktioniert!
Es liegt also an meinem Brenner!

Durch Codereview und Vergleich hab ich zwar keinen signifikanten 
Unterschied zwischen den beiden Brennern feststellen können, allerdings 
taktet mein Brenner den Clock-Pin vom Target langsamer als der Wisp - 
also ggf. ein Timingproblem, das ich mir per Oszi anschauen könnte, 
aber, da ich jetzt einen Wisp habe, erübrigt sich die Problemsuche 
(DIY-Brenner in die Ecke bzw. als Backup für den Wisp-PIC16F648a falls 
der mal kaputt geht).

Danke nochmals für Eure Hilfe!

Viele Grüße,

Daniel

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.