MPLAB X und PICkit 3 - Plötzlich "failed to program device"

PICkit 3 ist sehr empfindlich auf jegliche parasitäre Kapazitäten, 
Interferenzen usw. Bei mir auf jeden Fall.
D.h. versuch die Leitungen möglichst kurz zu halten und möglichst nahe 
am Pic anzubringen. Hatte immer das Problem mit "Failed to program 
device". Einmal gings und dann doch nicht. Dann stellte ich fest dass es 
eine Rolle spielt wo ich die Leitungen auf dem Steckboard drauf steckte. 
Paar Reihen weiter von Pic weg und Verbindung war nicht möglich.

Ein PIC ist sehr robust und geht nicht so einfach kaputt. Es wird am 
Kabel bzw. der Verbindung liegen. Ich weiß nicht wie dein Aufbau genau 
ausschaut, aber hier wird beschrieben auf was zu achten ist:
http://www.sprut.de/electronic/pic/icsp/icsp.htm#kabel

Karsten schrieb:
> Ansonsten bin ich froh, dass meine PICs anscheinend nicht defekt sind.
> Auch wenn es mich immer noch iritiert, dass mein Programmieradapter so
> lange einwandfrei funktioniert hat, dann plötzlich der Fehler kam und
> sich seitdem nicht mehr zur Mitarbeit zu bewegen lässt.

Zeig mal Schema, und Code. Klingt ev auch nach einem anderen Problem mit 
den Configs


Die Firmware kannst du manuell auswählen:
Project options->Pickit 3-> Firmware -> Häckchen raus und unten Pfad 
angeben.

Dem Vorschlag mit 0.1uF direkt am PIC schließe ich mich an. Kannst auch 
noch einen zweiten größeren (1-10uF) parallel dazu setzen.

Am einfachsten könntest du einmal die Kabel für Clock und Data stark 
kürzen und deren Anschlüsse auf dem Steckbrett so dicht wie möglich an 
den Pin des PICs legen.
ggf. auch einfach mal den PIC an eine andere Stelle im Steckbrett 
platzieren, vielleicht sind die Kontakte nicht mehr ideal.

Idealerweise verwendest du ein Flachbandkabel (bspw. ein altes HDD Kabel 
vom PC), wie eben im Link auch bei Beispielaufbauten abgebildet:
http://www.sprut.de/electronic/pic/icsp/icsp877.jpg

Dort kannst du dann jedes zweite Kabel mit Masse verbinden, sodass du 
mit einem 7-8 adrigem Kabel auskommen kannst. Erst kurz am PIC splittest 
du das Kabel dann auf.

Also bei mir war ICSP noch nie so "zickig". Das, was er bisher als 
einziges nicht möchte, ist dass man Data und Clock vertauscht.
Ich habe einen Logicanalyzer, der mit 2 der abgebildeten Probes kommt:
http://dangerousprototypes.com/2010/04/17/logic-sniffer-probes-available-next-week/

Davon nehme ich einen, stecke es mit 2 gegeneinandergelöteten 
Steckleisten an das PICKIT3 und klemme die anderen Enden an die Pins. 
Nichts mit Masse zwischen drin, möglichst kurz usw. Hat immer alles 
geklappt.

Karsten schrieb:
> Hier erstmal der Code, was du mit Schema meintest, weiß ich leider
> nicht:

Schema ist Schematic -> Schaltplan. An dem Code sollte es eigentlich 
nicht liegen. Zumal es ja zuerst ging.

Ich könnte mir vorstellen, dass es an der Firmware liegt oder ggf an 
einer Kontaktunterbrechung (also andere Kabel nehmen und PIC woanders 
reinstecken).

Das täuscht bestimmt nur, aber es sieht so aus, als wäre der PIC 1 
Raster zuweit links.

Also wie gesagt, ich nutze den Stand-Alone-Programmer:
http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en538340&redirects=pickit3
unten unter "PICkit3 Programmer Application and Scripting Tool v3.10" zu 
finden.

Dort gibt es einmal die Installation des Teils und auch eine Firmware 
für das PICKIT. Wenn du die Software installiert hast, müsste es da 
unter dem Menü Tools sowas wie "Download OS" "Download Firmware" oder 
sowas stehen. Damit kannst du eine neue Firmware aufs PICKIT bringen. 
Dies, soweit notwendig, macht das Programm aber auch von alleine, wenn 
man versucht zu flashen. Auch wenn es nicht schadet, die Firmware 
aktuell zu halten, bezweifle ich, dass es daran liegt. Du hast nicht 
zufällig noch einen 2. oder einen anderen PIC, mit dem man einfach mal 
das PICKIT testen kann?

Karsten schrieb:
> Gibt es eigentlich einen Weg zweifelsfrei festzustellen, ob der PIC
> kaputt ist, ohne das Kit zu nutzen?
Man kann ein anderes PICKIT3, PICKIT2, ...., Selbstbaubrenner usw 
benutzen. Dieser Prüft aber nur, ob der Speicher so aussieht, wie er 
soll. Wenn ein funktionierendes Programm auf dem PIC ist, kann man 
gucken, ob das funktioniert. Aber das testet eben nur das, was genutzt 
wird. Wenn ein 8-LED Lauflicht als Programm drauf ist mit internem 
Oscillator und nichts weiter, weiß man nur dass die 8 AUSGÄNGE und der 
interne Oscillator funktioniert und dass der Speicherbereich, der 
genutzt wird, in Ordnung ist. Es kann trotzdem ein anderer Pin den Geist 
aufgegeben haben, die Pins, wo die LEDs dran hängen, könnten evtl als 
Ausgang gehen, als Eingang aber nicht mehr (hatte ich schonmal, wohl 
Eingangsstufe verbrutzelt), der ADC könnte durch kleine Überspannung 
schaden nehmen, ....
Also eine Methode, um ZWEIFELSFREI und ALLES zu testen, ist mir nicht 
bekannt. Höchstens ein Programm schreiben, dass den kompletten ROM und 
RAM (und ggf EEPROM), sowie alle Peripherie vollständig benutzt..

Du kannst zum Programmieren auch den 10k Widerstand rausnehmen. Den 
brauchst du da nicht. Ich hatte dadurch schon den Fehler (PIC war 
allerdings schon in der Schaltung) das das PicKit3 den MCLR nicht 
schnell genug in den Programmiermodus gezogen hat und der Pic vorher 
schon anfing sein Programm abzuarbeiten. Dadurch kam es zu solchen 
komischen Fehlern. Ich habe dann den Widerstand auf 20k vergrößert 
(irgendwo im Netz gefunden) und seit dem läuft alles prima.

Torsten

ich kann leider nicht alles durchlesen. ich hatte mit dem ICD3 auch 
pobleme bei den PIC24 und PIC32, die beim brennen schneller getaktet 
werden. bei meinen programmierleitungen (ca. 40cm!) war folgendes 
problem: ich hatte zu jeder leitung parallel eine GND-leitung, die ich 
beim ICD als auch auf dem demoboard mit GND verbindete. die Lösung lag 
darin, dass ich diese GND-leitungen nur(!) beim ICD3 anschloss und auf 
dem demoboard, nicht anschloss (ausser natürlich der "offiziellen" 
GND-leitung)