Wisp628 och 648: Target not auto-detected *Löst*

[Marta]

Då har Du korrekt Vpp.

Är Du helt säker på att kablarna till PGC/PGD inte är brutna någonstans och gjort tillfällig kontakt inne i isoleringeshöljet när Du provade en annan kretstyp? Det är ju EK och sådan är lätt att utmatta så den går av.

Mäter Du PGC/PGD så skall det finnas pulser på dessa. Det är helt enkelt data som klockas in i ett shiftregister. PGC är klocksignalen och alltid en ingång. PGD växlar beroende på om data skall läsas eller skickas. Vid identifieringen sker bådadera.

[JimmyAndersson]

Nu har jag mätt och det dyker upp pulser på 5V under ett kort ögonblick (precis så man hinner se det) på PGC och PGD.
Likadant på både Wisp628 och Wisp648.

[sodjan]

OK, det är ju bra...

Tja, det hela är lite märkligt.
Om jag hinner (och kommer ihåg det) så kan jag koppla
upp en PIC18F12xx/13xx (vilken som helst av de 4 olika
i serien är nog OK att testa) på kontoret och prova.

Det var länge sedan jag körde dessa men, som sagt, jag minns
att jag var tvungen att bryta matningen (till både "target" och
Wisp'en) mellan varje körning, annars fick jag inte kontakt. Det
verkar vara något med denna serie som är lite "speciellt"...

[JimmyAndersson]

Mjo, det verkar vara något udda. Jag får ju problem redan första gången
som jag ansluter matningspänningen och försöker programmera.
Det här med att Timer1 oscillator in/ut delas av PGC och PGD-pinnarna är lite intressant.
Jag har ju stängt av den funktionen, men jag vet inte vad som händer vid t.ex "erase all"
och 'resten' av programmeringen.


Nu hittade jag en PIC18F1230 nu och har lyckats programmerat den flera gånger utan problem.
(På den delas bara PGC och PGD av digital i/o och PWM output.)

Jag har tittat igenom databladet lite och har inte hittat något
som hindrar att jag använder den till det här projektet.

Men det är lite "småläskigt" att 18F1320 har fungerat att programmera tidigare och nu totalstrejkar.
Eftersom vi (än så länge iallafall) inte vet vad det beror på så kan ju samma sak hända med 18F1230.
Jag får väl göra klart koden fort som 17 och hoppas på det bästa..


Du får hemskt gärna testa ändå. Det vore speciellt intressant om du hittar en 18F1320 eller 1220 att testa.
edit: Eller förresten. Allt är av intresse. Vi kanske har olika versioner av XWisp2w och firmware i Wisp'en.

[JimmyAndersson]

För ett par veckor sedan så löste jag det här mysteriet, så jag drar upp tråden igen.


Tidigare skrev jag:
"Det här med LVP var också en lärdom.
Tyvärr blev det ingen skillnad att ansluta den till Wisp'en eller GND.
(Oavsett om jag hade motstånd eller inte mellan LVP-pinnen och GND.)"

Det visade sig att just LVP är en lösning för detta problem,
men testet ovan visade inget tecken på det.





Nedanstående är testat med en PIC18F1320 med 1st hex-fil där config är gjord såhär:

Kod: Markera allt

	CONFIG OSC = HSPLL, IESO = OFF, FSCM = OFF
	CONFIG PWRT = OFF, BOR = OFF, WDT = OFF, MCLRE = ON
	CONFIG STVR = OFF, LVP = OFF, DEBUG = OFF, CP0 = OFF
	CONFIG CP1 = OFF, CPB =OFF, CPD = OFF, WRT0 = OFF
	CONFIG WRT1 = OFF, WRTB = OFF, WRTC = OFF, WRTD = OFF
	CONFIG EBTR0 = OFF, EBTR1 = OFF, EBTRB = OFF

Såhär är det, visade det sig:


Om man programmerar en PIC18F1320 utan att ha LVP ansluten
så kan man råka ut för problemet i tråden.
Att då ansluta LVP och programmera PIC-kretsen hjälper inte.

Men:
Om man tar en oanvänd PIC18F1320 och ansluter LVP innan man programmerar den för första gången
så uppstår inte det här problemet.
Jag har även testat att därefter koppla loss LVP och programmera PIC-kretsen, utan att problemet har uppstått.



Det är min julklapp till de som av en händelse råkar använda PIC18F1320.

[vfr]

Underbart att du återkopplar och ger ledtrådar till andra efter så lång tid! My credits!