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

[JimmyAndersson]

Jag lyckas inte bena ut detta.

En PIC18F1320 sitter på ett kretskort.
Den har suttit på det kretskortet och blivit programmerad över mitt kretskorts ICSP-kontakt tidigare
(det är flera månader sedan jag provade programmera just denna PIC-krets senast).

Men nu när jag återupptagit projektet så får jag:

"xwisp2 version 2.0.0 for Windows (May 5 2010, Open Watcom C/C++ 1.90)
File UV-box.hex loaded and is Intel Hex format conforming
Detected programmer: Wisp648, firmware version 1.29
Target not auto-detected, please specify on commandline!
xwisp2 failed after 1.41 seconds, rc 23"


Provade med Wisp628, men det var motsvarande felmeddelande där:

"xwisp2 version 1.9.6 for Windows (Dec 11 2008, Open Watcom C/C++ 1.70)
File UV-box.hex loaded and is Intel Hex format conforming
Detected programmer: Wisp628, firmware version 1.09
Recommendation: Upgrade your Wisp628 firmware to at least version 1.11
Target not auto-detected, please specify on commandline!
xwisp2 failed after 1.37 seconds, rc 23"

(Tyvärr har jag inte kvar den gamla versionen av Xwisp2w, därav meddelandet om att uppgradera firmwaren.)


Efter detta flyttade jag PIC-kretsen till en fräsch labplatta.
Matningspänning från ett Voltcraft labagg som ger stabil 5V.
100nF konding så nära PIC-kretsen det bara är möjligt.
Wisp'ens (har provat båda, en i taget förstås) matningssladdar i hålen efter kondingen.
Har kollat så jag satt rätt sladd till PGC och PGD *många* gånger och kontrollmätt.
10k ohm (kontrollmätt) mellan PIC-kretsens MCLR-pinne och Vdd.
That's it.

Men: Ingen skillnad i resultat.
Bytte till en ny PIC18F1320. Ingen skillnad.

Lusläste databladet och såg att pinnarna för PGD och PBC delas av in/ut för Timer1/3 oscillatorer.
Jodå, i koden har jag:

Kod: Markera allt

;	Timers
	bcf		T2CON,	TMR2ON	;Timer 2 - Off
	bcf		T3CON,	TMR3ON	;Timer 3 - Off
	bcf		T3CON,	TMR3CS	;Internal clock. <<<<<<<< T13CKI Används ej.

	bcf		T1CON,	T1RUN	;Timer1 används inte som "systemklocka".
	bsf		T1CON,	T1CKPS1	;Prescaler: 1:4
	bcf		T1CON,	T1CKPS0	;Prescaler: 1:4
	bcf		T1CON,	T1OSCEN	;Timer1 oscillator - Off <<<<< Använder ju interna klockan.
							;Skulle den varit On så hade Pin RB7/PGD/OSI och RB6/T1OSO/T13CKI varit inputs.
	bcf		T1CON,	TMR1CS	;Internal clock (Fosc/4) <<<<< T1OS0/T13CKI används ej-

Config-bitarna ser ut såhär:

Kod: Markera allt

	CONFIG OSC = HS
	CONFIG PWRT = ON, 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

Jag vet att det finns flera trådar om "Target not auto-detected",
men vad jag kan se så har jag undersökt alla orsaker som nämnts.

Så vad har jag missat?
Det enda jag vet att jag inte gjort är att uppgradera firmwaren i Wisp628 och Wisp648,
men jag har programmerat flera PIC18F1320 åtminstone 50-talet gånger sammanlagt med Wisp628 innan.
Enligt Xwisp2w så stödjer både Wisp628 och Wisp648 denna PIC-krets.

[sodjan]

Det vanligaste när man får "Target not auto-detected" är att programmeraren
inte har lyckats för över processorn i "programming mode".

Detta kan bero på flera olika saker, men vanligast är nog:

- Processorn är programmerad med internal-MCLR, och programmeraren stöder inte det.

- Matningen/avkopplingen/glättningen är dålig, vilker ger spännings-dipp när Vpp läggs på
och detta får processorn att inte gå över i "programming mode".

Det kan även vara så att man tänker programmera än så pass gammal processor så
att det inte finns något "ID" i den, men det är inte så i detta fall.

Vissa modeller har problem med Timer1-pinnarna, jag vet inte mer om det.

Jag har själv haft en del konstiga problem med den serie där PIC18F1320 ingår.
Jag fick bryta strömmen mellan varje programmering. Jag vet inte om det fortfarande
är så med senare XWisp22 eller Wisp648.

Meddelandet "please specify on commandline" är inte specielt bra, det hjälper normalt
inte om det inte är just en (väldigt) gammal PIC-modell utan inbyggt "ID".

Så, för att sammanfatta, så *borde* det fungera.
Men det var du väl inte speciellt hjälpt av...

Testa att koppla upp något annat, en 16F628A eller liknande och
se om det fungerar.

[JimmyAndersson]

"Så, för att sammanfatta, så *borde* det fungera.
Men det var du väl inte speciellt hjälpt av... "

Jodå, det visar att allt är som det ska: Udda fel trivs hos mig av någon märklig anledning.


Nu har jag testat att programmera 16F628A, 12F675 och 16F688 med Wisp648.
Det gick utmärkt, så då verkar det iallafall inte vara något i själva hårdvaran på Wisp'en.

Just nu kan jag bara komma på tre saker till att testa, i tur och ordning:
1) Sova på saken.
2) Leta upp den gamla versionen av XWisp2w som jag hade tidigare och testa den med Wisp628.
3) Göra en testkod för PIC18F1320 där allt är avstängt, förutom MCLR då.


Förresten: I databladet finns en ruta i avsnittet om Timer1:

"The Timer1 oscillator shares the T1OSI
and T1OSO pins with the PGD and PGC
pins used for programming and
debugging.
When using the Timer1 oscillator, In-Circuit
Serial Programming (ICSP) may not
function correctly (high voltage or low
voltage), or the In-Circuit Debugger (ICD)
may not communicate with the controller.
As a result of using either ICSP or ICD, the
Timer1 crystal may be damaged."

Men dels så har jag "stängt av" T1OSI och T1OSO (första kodrutan i mitt förra inlägg)
och dels så har jag provat med en ny PIC 18F1320 efter att jag stängt av detta.

[JimmyAndersson]

Ny dag, nya försök.

Med gamla versionen av XWisp2w, en version jag programmerat många PIC18F1320 med innan:

"XWisp2 version 1.6.01 (Aug 14 2005, Open Watcom C 1.30)
File UV-BOX.HEX loaded and is Intel Hex format conforming
Programmer Wisp628, firmware version 1.09
Target not found in configuration table
Target not auto-detected, please specify on commandline!
XWisp2 failed after 1.68 seconds, rc 23!"


Just "Target not found in configuration table" har jag nog inte sett innan.
Vet inte om det betyder att XWisp2w inte hittar mål-kretsen (PIC18F1320) i cfg-filen (Wisp2-katalogen),
men det finns där iallafall:

"Name = 18F1320
DeviceID = 07C0
ProgSize = 8K
DataSize = 256
ProtectMask = C00F
FuseFixedZero = 00CF0F1F0080850003C003E00340"


Jag provade även att stänga av allt som rör timers mm, men det blev samma sak ändå.

Vad ska man hitta på då..


Välja en annan PIC-modell och göra nytt kretskort?
Eller finns det någon (kanske från en annan serie) som är pinkompatibel med 18F1320 och har:
*Lika många i/o.
*2 timers (eller fler), varav 1st 16bit och 1st 8bit.
*(E)USART.
*Kan "köras" i 10MHz (med extern kristall).
*Gärna PIC18.

Men frågan är om det skulle hjälpa med en annan PIC-modell...
Jag menar, jag har använt 18F1320 många gånger tidigare (det är en favoritmodell)
och om ett sånt här fel kan dyka upp plötsligt med den modellen utan att man vet varför,
så kan det ju lika gärna dyka upp på vilken annan modell som helst.

[sodjan]

> Just "Target not found in configuration table" har jag nog inte sett innan.

Prova att bara köra Xwisp2 (för att få hjälp/konfig sidorna) och se om den finns med.

Aja, det hela är ju lite märkligt. Jag skulle kunna testa på kontoret, jag har
sannolikt någon 18F13xx liggandes. Sen så tycker jag att just hela denna
serie (18F12xx/18F13xx) har haft en del konstiga egenheter/fel. Jag har
som sagt varit tvungen att starta om hela uppsättningen (target samt
Wisp628) mellan varje programmering. Jag har dock för mig att det försvan
vid en firmware uppdatering någon gång (detta var flera år sedan).

En annan sak...

> Programmer Wisp628, firmware version 1.09

Jag ser att många PIC modeller i listan är markerade med ett "+" och
att det står "[+] Wisp6x8 firmware >= 1.10". I och för sig inte just vid
PIC18F1320 men i alla fall. Du kanske skulle uppgradera Wisp'en också...

[JimmyAndersson]

"Prova att bara köra Xwisp2 (för att få hjälp/konfig sidorna) och se om den finns med."

Jodå, den finns med där.


"Du kanske skulle uppgradera Wisp'en också..."

Tyvärr finns inte firmwaren för Wisp628 kvar hos www.voti.nl/wisp628 :
"the firmware is no longer available. You should use theWisp648 instead for a 20 MHz 16F628 (version 1.0)"


Du (eller någon annan) råkar inte ha en hex-fil med en firmware som är nyare än min 1.09 ?

[sodjan]

Om du tar den senaste från www.robh.nl och lägger den i en
16F648A så ska den fungera på både Wisp628 och Wisp648.

[JimmyAndersson]

Ah, just det ja. Wisp628 kan användas med en PIC16F648A.

Men.. om jag stoppar i en PIC16F648A uppgraderad till firmware 1.27 i Wisp628,
så hamnar jag väldigt nära firmware'n som jag redan har i Wisp648 (1.29, som är den senaste).

Har 1.27 något som 1.29 saknar och som eventuellt kan vara en bidragande orsak till problemet?
(Jag hittar tyvärr ingen versions-historik för de olika firmware-versionerna.)

Jag kan naturligtvis uppgradera och testa bara för sakens skull.

edit: Ajdå, jag har inga PIC16F648A. (Förutom den som sitter i Wisp648,
men för säkerhetskull vill jag behålla den som den är.)

[sodjan]

Ja just det, du hade provat med båda, eller hur ?
Om du är osäker på om själva hårdvaran i Wisp648 är OK
eller inte så kan du flytta 648A'n till Wisp628'an och prova.

> men för säkerhetskull vill jag behålla den som den är.

Det är ju bara att flytta tillbaka 628A'n så är den som den var...


Hur som helst, min gissning är att det är något helt annat.
Något med uppkopplingen som sådan, matningen, avkoppling o.s.v.

[JimmyAndersson]

"Ja just det, du hade provat med båda, eller hur ?"

Jodå. (Felmeddelanden från Wisp628 och Wisp648 finns i första inlägget.)


Nu har jag testat att flytta PIC16F648A (som satt i Wisp648) till Wisp628.
Samma fel ändå.
Testade även att programmera min PIC18F1320 med en hexfil som jag kunnat
överföra till 18F1320 förr, men det blev samma felmeddelande ändå.


"Det är ju bara att flytta tillbaka 628A'n så är den som den var..."

Så sant. Jag tänkte inte på det innan.


Jo, det verkar nästan vara något annat. Frågan är vad.
Uppkopplingen kan inte bli enklare, så det finns inte mycket att byta eller felsöka...

Jag har:
* Testat på tre olika labplattor (två från ny förpackning).
* Bytt sladdar, lött nya sladdar. (För matningspänning och till DSUB på Wisparna).
* Testat olika "mängd" avkoppling. (När jag inte testat olika så har jag kört med 100nF.)
* Mätt motståndet (för MCLR) till 9,61k ohm. Har även testat med 2st i serie (blev ca 19k ohm).
* Testat två olika PIC18F1320 och en PIC18LF1320.
* Provat att programmera andra PIC-kretsar än PIC18F1320 med Wisp628 och Wisp648. Det fungerar.
* Testat tre olika versioner av XWisp2w.
* Provat med både Wisp628 och Wisp648, samt med PIC-kretsen i Wisp648 monterad i Wisp628.


Vad finns det kvar att testa? Platinapläterat kretskort i fullmåne under hyllningsång till Rob och Wouter?


En bild på uppkopplingen:



Jag vet att sladdarna till matningspänningen är grön och vit.
Det är medvetet för att lättare skilja dem åt från övriga sladdar.
(Vid polvändning så hade jag fått lite andra fel...)

[sodjan]

> Jag har:

Bytt plats på PGD och PGC ?
Det brukar vara det första jag testar...
Jag sätter dom fel i hälften av fallen.
Och jag menar inte att verifiera mot datablad o.s.v,
utan att faktiskt byta plats på dom rent fysiskt.

Annars vet i fasen...

[Marta]

Har Du kontrollerat så Du verkligen har Vpp? Anslut annars ett scope och gör det.

Pinne 11 är LVP, eller PGM som den råkar kallas på denna krets. Den kan ställa till det ibland om detta är enabled i configregisters. Prova att ansluta denna till GND/Vss genom t.ex. ett 10k motstånd.

[sodjan]

Bra, LVP/PGM hade jag missat...

Notera att LVP *alltid* är enablat efter en "erase all" och innan
CONFIG bitarna är satta igen, så om programmeraren gör en
"erase all" i en Vpp-session (så att säga) och sedan försöker
starta en ny programmerings session (med Vpp bortkopplat i mellan)
så kan det uppstå problem. Enklast är att alltid ha PGM pinnen
antingen ansluten till VP/PGM utgången från Wisp628/648 eller
bara lägga den låg.

D.v.s LVP/PGM pinnen kan ställa till det även om man har
CONFIG LVP = OFF i koden...

[Andy]

Har du kollat att det inte är ”A case of a bad proto board”?

[JimmyAndersson]

Andy:
Vad är det och hur kollar jag det? Google ger inte en enda ledtråd.
Men som jag har skrivit så har jag testat tre labplattor (varav två nya) och ett kretskort där jag tidigare (i våras) framgångsrikt har programmerat en av de PIC18F1320 som jag nu inte lyckas med.


Sodjan:
"Bytt plats på PGD och PGC ?
Det brukar vara det första jag testar... "

Aha.
Tyvärr blev det ingen skillnad, men det var intressant att veta att man kan testa det utan att det händer något.
(Jag har inte 100% koll på vad som händer på PGD och PGC vid en programmering.)

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.)


Marta:
"Har Du kontrollerat så Du verkligen har Vpp?"

Såhär ser det ut:
När jag ansluter matningspänningen är det +5V på MCLR-pinnen, tack vare motståndet till Vdd.
När jag kör igång "xwisp2w go uv-box.hex" så sticker spänningen iväg till 12V. (Utan motståndet så får jag 14V.)
Spänningen dyker snabbt (jag har analogt oscilloskop, så jag hinner inte se exakt, men jag tycker det dyker till 8V och 0V eller nåt sånt) och går sedan upp till 12V respektive 14V igen.

Sedan ligger spänningen där (12V respektive 14V beroende på om jag har motståndet eller inte) tills jag bryter matningspänningen.