Hi, offenbar kann man sich auch beim PIC „aussperren“ so wie das bei ATMEL möglich ist. Sei einem halben Jahr verwende ich ein 16F819 basierendes, selbstgebautes Eval Board um Programmteile zu testen. Nie gab’s Probleme obwohl auch ich mit MCLR als IO Pin und internen Oszillator arbeite. MPLAB (Ver. 8.00) bzw. der ICD2 meckerte zwar – macht es aber doch. An den Programmierleitungen hängt sonst nichts weiter. Gestern erhielt ich nach dem progamieren dann plötzlich auch diese „invalid target device ID“ Meldung. Der Code (einschließlich des CONFIG Words) lief seit 2 Wochen problemlos. Und: Das Programm selbst läuft auch – ich sehe es da ich verschiedene Signale ausgebe. Ich habe dann den PIC gewechselt und neu programmiert: Das ging genau ein mal. Der Code läuft wieder aber nun komme ich wieder nicht mehr in den PIC – kann also auch das CONFIG Word nicht mehr rücksetzen. Bei manchen ATMEL Programmern gab es mal eine Funktion: „Ignore false device ID“, die finde ich aber im MPLAB nicht. Hat irgend jemand eine Idee (oder ein Tool) wie man den PIC wieder in den „Werkszustand“ bekommt ??? Vielen Dank, EXE
Mit einem High-Voltage-Programmierer kann man jeden gängigen PIC neu programmieren. Nur im Low-Voltage-Mode kann es Probleme geben. Wie ist das LowVoltage-Programming-Bit in der Config gesetzt ?
Beim PIC kann man sich nicht aussperren. evtl. hast Du den aber auch geschossen, die Meldung kenne ich, die liefen zwar noch aber liessen sich nicht mehr programmieren.
@ Bernd LVP (bit7) ist 0. Ich habe mit dem Oszi natürlich gleich als erstes direkt am Pin4 die 13V nachgemessen. Die kommen. (clk und data übrigens auch). In einem anderen Forum beschrieb jemand folgendes Szenario: Mit internen Oszillator und MCLR als IO Pin läuft der PIC sofort an wenn er mit dem ICD2 verbunden wird. MCLR (RA5) kann also via TRISA bereits auf Output gesetzt sein der auf L liegt. Kommt jetzt die 13V H Flanke muss diese gewissermaßen zunächst gegen das L Signal an Pin4 „ankämpfen“. Um den PIC in den Programmiermode zu bekommen wird hier aber eine sehr steile Flanke erwartet. Ohne die genaue Hardware hinter dem MCLR Pin zu kennen klingt diese Erklärung zumindest nicht ganz unlogisch. Auf alle Fälle scheint der Effekt kein Einzelfall zu sein. Die Leute hatten aber immer das gleich Problem wie ich: Wie kann ich das CONFIG word wieder auf Werkseinstellung (alles 1) setzen wenn ich erst gar nicht mehr ran komme? @ Christian Der PIC arbeitet stand alone. Alles was dran hängt ist die Betriebsspannung mit Abblock Kondensator und die Programmierbuchse. ICD2 übrigens ein Original (kein Nachbau) mit ca. 12cm langen Kabel. Sollte sich der PIC wirklich hardwaremäßig „zerprogrammieren“ lassen? Da hätten Microchip längst reagiert. Und würde die Kombination interner OSC und MCLR auf IO einen Flash PIC gewissermaßen in einen OTP (one time programmable) verwandeln dann würde da eine eindeutige Warnmeldung kommen.
Hallo, ich arbeite seit 12 jahren mit PIC und mit dem ICD0,1,2... ich habe mehrere PIC zerschossen und nie ergründen könenn warum. Mit dem ICD2 gab es immer Ärger in der Firma, da brauchen sich nur die Betriebsspannung gering zu unterscheiden. In die MCLR Leitung muss übrigens eine Diode nach Plus gelegt werden sonst kann die programmierspannung dort abfliessen.
>Die Leute hatten aber immer das gleich >Problem wie ich: Wie kann ich das CONFIG word wieder auf >Werkseinstellung (alles 1) setzen wenn ich erst gar nicht mehr ran >komme? Wenn man Vpp vor VDD hochfährt könnte man wohl wieder ran kommen. Vieleicht kann dein ICD2 das ja irgendwie.
@EXE Der MCLR/RA5-Anschluß kann nicht als Ausgang geschaltet bzw. verwendet werden. Er ist immer ein Eingang.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.