Hallo Leute, ich nutze ein PICkit3 zum Programmieren meines PIC16F627A. Ich programmiere den PIC mit einem selbstgebauten Adapter: http://www.jb-electronics.de/html/elektronik/digital/d_artikel06_pickit3_und_icsp.htm Funktionierte früher problemlos, und auch immer noch mit diversen PIC16F716. Wenn ich aber nun versuche, PIC16F627A zu beschreiben, meldet der mir "Device ID 0000000". Also wahrscheinlich ein Kommunikationsproblem. Das Kuriose ist: Einer der PIC16F627A war frisch bestellt. Ausgepackt, beschrieben, alles kein Problem. Beim zweiten Mal dann auf einmal diese Meldung. Das PICkit3 weigert sich offenbar, den PIC des Typs 16F627A mehrfach zu beschreiben. Ich habe das mit insgesamt sieben PICs (16F627A) ausprobiert, mittlerweile lassen sie sich alle nicht mehr beschreiben. Die 16F716 allerdings schon. Irgendwelche Ideen? Beste Grüße Jens
Nein, LVP ist disabled. Gruß Jens
am RA5 das MCLR weggeschaltet in den Configuration Bits? Dann kannst du nicht mehr an den Controller ran. Torsten
Nö, ist auch korrekt gesetzt:
1 | __CONFIG(FOSC_INTOSCIO & WDTE_OFF & PWRTE_ON & MCLRE_ON & BOREN_ON & LVP_OFF & CPD_OFF & CP_OFF); |
Gruß Jens
Hast du ein Oszilloskop? Mess doch mal die Spannung am MCLR, wenn du versuchst zu flashen. Sollten ja dann so um die 9-12V sein.
Nimm mal den 4,7k Widerstand aus dem Adapter raus. Der ist dort unnötig. In MPLAB ist der Haken das er die Konfigurationsdaten aus dem Programm und nicht aus dem Menü nimmt gesetzt? Ansonsten probiere mal die Konfiguration mit MPLAB zu machen und nicht per Software. Torsten
Torsten Schwalm schrieb: > Nimm mal den 4,7k Widerstand aus dem Adapter raus. Der ist dort unnötig. Probiere ich gleich aus. Torsten Schwalm schrieb: > In MPLAB ist der Haken das er die Konfigurationsdaten aus dem Programm > und > nicht aus dem Menü nimmt gesetzt? Ja. Torsten Schwalm schrieb: > Ansonsten probiere mal die Konfiguration mit MPLAB zu machen und nicht > per Software. Eine Überlegung wert, aber das kann nicht die Ursache des Problems sein. Ich habe ja weder meinen Compiler geupdatet noch meine Firmware. Gruß Jens
Ich hatte es allerdings schon, dass die Kürzel für z.B. MCLRE_ON in der Config für einen einzelnen Prozessor falsch waren, und damit ein falsches Config-Bit gesetzt wurde. War wahrscheinlich nur ein Schreibfehler, hat mich aber ewigkeiten gekostet das rauszufinden. Läuft den das Program auf dem µC wenigstens? Wenn ja kannst du ja mal testen, ob du es mit einem Reset an MCLR anhalten kannst. Da kannst du dann ein falsch beschalteten MCLR Pin mit Sicherheit ausschließen. Wenn du ein Oszi hast, schau dir mal die Flanke von VPP an. Wenn die zu langsam ist, startet der µC mit dem internen Oszillator das Programm, aber du kommst nicht in den Programmiermodus! Ist mir mal mit einem 635 passiert.
Sowas ähnliches hatte ich auch kürzlich. Bei mir waren es PIC16F872, die man nur genau ein mal mit dem PICKit2 progammieren konnte. Danach wurden sie nicht mehr erkannt. Auch nicht mehr mit dem PICKit3. Wenn ich sie aber mit dem Galep4 gelöscht habe, gingen sie wieder - wieder genau ein mal. Also defekt sind die PICs sicher nicht, aber Microchip ist auch nicht mehr das, was es mal war.... Wenn man die PICs nur mit dem PICKit3 programmiert hat, gabs keine Probleme. Also hab ich das Problem erst mal nicht weiter verfolgt.
Du hast vermutlich nur das PICKIT. Die Brenner von sprut.de erkennen auch PICs, die mit PICKIT nicht merh asnsprechbar sind.
Torsten Schwalm schrieb: > Läuft den das Program auf dem µC wenigstens? Wenn ja kannst du ja mal > testen, ob du es mit einem Reset an MCLR anhalten kannst. Da kannst > du dann ein falsch beschalteten MCLR Pin mit Sicherheit ausschließen. Werde ich gleich machen - das Programm läuft allerdings, nur lässt sich der uC nicht mehr programmieren. Torsten Schwalm schrieb: > Wenn du ein Oszi hast, schau dir mal die Flanke von VPP an. Wenn die > zu langsam ist, startet der µC mit dem internen Oszillator das > Programm, aber du kommst nicht in den Programmiermodus! Welche Größenordnung bedeutet zu langsam? Ich hatte gestern noch so ein seltsames Erlebnis. Ich hatte mittags kurz Zeit und habe ein paar der vorher nicht beschreibbaren PIC16F627A ausprobiert, und auf einmal ließen sich zwei wieder beschreiben, und das Programm lief auch stabil. Danach war auf einmal wieder Schluss. Ich lade gleich mal meine Schaltung sowie meinen C-Quellcode hoch, dann müssen wir nicht so im Dunkeln stochern. Vorher checke ich noch die Config-Bits aus dem Header-File. Gruß Jens
Ich hatte mal ein ähnliches Problem. Die Lösung war es, die Firmware des PicKit neu zu programmieren. Danach ging alles wieder. Probier das mal.
Wo bekomme ich denn manuell die neueste Firmware her? Gruß Jens
Ich habe das Problem mittlerweile teilweise behoben: Ich habe ein neues Programm beschrieben, dass nur das Config-Word 0x3fff enthält. Nun habe ich dieses mit der niedrigsten VDD (3.000V) mit dem PICkit3 an den PIC gesendet, und dann schrittweise die Spannung erhöht (über MPLAB -> Programmer -> Settings). Was soll ich sagen? Drei meiner fünf PICs sind nun wieder ansprechbar, irgendwann kamen dann Signale zurück. In meinem neuen Programm habe ich zudem zu Beginn (direkt nach dem Präprozessor-Befehl für das Config-Word, aber vor den Definitionen der Steuerregister) eine Warteschleife eingebaut. Das scheint einiges auszumachen, der PIC lässt sich nun problemlos flashen. Woran das liegt ist mir nicht so ganz klar, habe aber im englischen MicroChip-Forum den obigen Tipp genannt bekommen. Dort wurde zudem geäußert, dass dieses Problem oft mit 18-poligen 16F-PICs auftritt, die im INTOSC-Modus arbeiten. Gibt es diese Probleme auch bei AVRs? Gruß Jens
Firmware updaten: In MPLAB -> Menü "Programmer" -> Settings Es geht ein Fenster auf "PicKit3 Settings" -> Reiter "Configuration" -> Button "Manual Download" Ich brauchte keine neue Firmware, es hat gereicht, die vorhandene nochmal neu ins PicKit zu programmieren.
Was soll sich denn bitte schön ändern, wenn du die vorhandene Firmware noch einmal neu installierst? Ich kenne den von dir angesprochenen Dialog, aber ich brauche ja auch noch die aktuelle .JAM-Datei, und ich weiß nicht, wo ich die herbekomme. Gruß Jens
Es koennte auch helfen den CLKIN auf Vss (aka GND) zu ziehen.
Ich hoffe er hat das Problem in den letzten 3 Jahren schon gelöst...
> Ich hoffe er hat das Problem in den letzten 3 Jahren schon gelöst...
Selbst Microchip hat Jahre gebraucht, die Taktversorgung als
die Quelle des Uepels zu erkennen.
ICSP braucht gar keinen (CPU-)Takt um zu funktionieren.
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.