Sida 1 av 4

"Target not auto-detected", fast det just fungerat

Postat: 24 juli 2007, 15:12:13
av marcusg
Laddade upp ett program till en 16f88 med xwisp2 via wisp628, fungerade utmärkt. Ändrade lite i programmet och skulle ladda upp det på nytt, men då fungerade det inte längre. xwisp2 säger "Target not auto-detected". Testade att flytta picen så att det enda som var kopplat till den var +5V, Jord och wisp628 - hjälpte inte. La in en annan 16f88 och laddade upp ett testprogram till den - fungerade. Laddade upp det första programmet (det som orsakat problemet), vilket fungerade. Men nu hände samma sak med denna pic, den går inte att programmera om efter att jag lagt in just det programmet. Vad kan orsaka detta fel?

Config för programmet ser ut så här:

__ config _CONFIG1, _CP_OFF & _DEBUG_OFF & _INTRC_IO & _LVP_OFF & _CCP_RB0 & _WDT_OFF & _PWRTE_ON

Någon som kan komma på vad det skulle kunna vara som orsakat detta? Om det behövs postar jag källkoden för programmet (som tyvärr ser fruktansvärd ut - har snabbt modifierat ett gammalt program för att göra några tester).

-- ändrade rubriken, den var visst för lång --

Postat: 24 juli 2007, 15:28:10
av v-g
Sist jag hade liknande problem så var det fel firmware i 628:an. Bytte även till nyaste xwisp.

Se till att du har rätt så bör det fungera. Rök många hårstrån från min skalle den gången :)

Postat: 24 juli 2007, 15:33:46
av marcusg
Jag har (enligt xwisp2 1.9.2) firmware 1.11 i min wisp628.

Postat: 24 juli 2007, 15:36:32
av bos
Antagligen helt irrelevant i sammanhanget: Jag har haft samma fel, fast inte med Wisp. Felet berodde på att includefilen (från Microchip) hade ombytta värden på CP_OFF samt CP_ON, vilket gjorde att när jag hade CP_OFF i min kod så blev kretsen låst efter programmering.

Postat: 24 juli 2007, 15:41:24
av v-g
http://www.jescab.se/Programvara.html Kolla där för mer info angående programvaran.

Ser inte MCRLE configbiten om den är satt så måste du köra en Vpp before Vdd för att komma igång igen.

Postat: 24 juli 2007, 15:42:54
av Icecap
Du kan få det fel om det är vald intern reset.

Postat: 24 juli 2007, 15:58:34
av marcusg
Jag kollade lite i ett gammalt program, och där har jag exakt samma __config som det jag nämnt ovan, men det programmet kunde jag skriva över utan problem.

Har aldrig angett MCRLE i __config (har bara hållit på med pic i några veckor), så det vore väl konstigt om den började spöka mitt i allt!

Postat: 24 juli 2007, 16:16:27
av sodjan
Du ska *ALLTID* ange *ALLA* __CONFIGx bitar !!

Dessutom, var är __CONFIG2 ????

Och kör *INTE* med "_MCLR_OFF", då får du detta fenomen.

Se även : http://www.jescab.se/InternMCLR.html

> Om det behövs postar jag källkoden för programmet

Det räcker med *alla* dina CONFIG inställningar (*både* __CONFIG1 och __CONFIG2)...

Postat: 24 juli 2007, 16:27:15
av marcusg
Lat som man är i början så har jag inte angett fler inställningar (just dessa fanns i ett programexempel jag testat, och då det fungerat har jag använt det själv). Så __config2 finns i detta fall inte angivet, och de __config1 jag angivit är alla som fanns angivna i nämnda program *duckar*.

MCLRE fanns inte angiven, så kan det vara så att det i detta program på något sätt blivit inställningen _MCLR_OFF, fast det aldrig blivit det förr?

Bara vi lyckats reda ut detta lovar jag att läsa igenom databladet för femti-elfte gången och denna gång se till att allt är angivet i config1/2 :-) Men alla har väl varit nya, ivriga och dumma...

Postat: 24 juli 2007, 16:31:26
av Icecap
Du är DEFINITIVT inte den enda som antar att de inställningar du INTE gör nog inte ställer till problem. När man sedan har ett antal år inom yrket suckar man tungt när man upptäckar att man glömde just denna grej som .... osv.

Utgå därför ALLTID ifrån att de inställningar du inte gör kommer att vara källa till alla problem, nu och i framtiden.

Postat: 24 juli 2007, 16:37:11
av marcusg
Jag har antagit att det finns standardvärden på alla __config, så man bara behöver ange de som avviker från standardvärdet, men detta är alltså fel?

Är problemet alltså att MCLR är avstängt, så jag måste använda en krets enligt http://www.jescab.se/InternMCLR.html?

Postat: 24 juli 2007, 17:05:41
av sodjan
Att *inte* förlita sig på "default" värden fungerar alltid.
Och ja, dongeln ska lösa detta.

Dock, *pesonligen* har jag bara sett problemet med 12F675/629,
jag har för mig att jag har programmerat om F88 även med int-mclr,
men å andra sidan så är det inte enligt spec, och det kan variera mellan
revisioner på chippet...

50:- inkl frakt för ett kit till donglen...

EDIT :
Se även slutet av INC filen för vilka CONFIG alternativ du har att välja på.
Välj bland dessa med hjälp av kapitlet om CONFIG i databladet där det
framgår vad de "gör"...

Postat: 24 juli 2007, 17:19:01
av marcusg
Ok. Har haft en del problem tidigare, men jag trodde att de berott på glappkontakt som jag numera åtgärdat. Kan hända att jag tidigare haft problemet, men att det efter en del trugande löst sig. Verkar inte vilja göra det i detta fall, dock.

Verkar som om det blir en ny Sodjan-beställning för mig. Såvida ingen annan kommer med någon snilleblixt så hoppas jag att den där grejen löser mina problem :)

Tack för alla snabba och bra svar! Återkommer så fort jag lärt mig något nytt. Skall ta och prova lite med en 16f688 (inkl. alla config-direktiv) och se om allt fungerar som det ska då. 16f688 borde räcka till för att göra mina tester, innan jag lyckats låsa upp mina två 16f88...

Postat: 24 juli 2007, 17:25:29
av sodjan
> inkl. alla config-direktiv

*Utom* _MCLR_OFF, om du inte måste p.g.a brist på pinnar... :-)

Postat: 24 juli 2007, 17:30:09
av marcusg
Ska väl köra med _MCLR_ON... Går det att se någonstans vilka config-direktiv som använts (t.ex. i hex-filen, eller så), så här i efterhand?