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
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?
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.
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
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/
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).
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
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...
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?
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
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?
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.
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.
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
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:
1 | runas /USER:Administrator /env WinPic.exe %1 |
wegen der nötigen Rechte für HW-Zugriff. HTH
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
Thread beobachten
Seitenaufteilung abschalten
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.