Problem med PIC, tappar ID *LÖST*

[Stewal]

Har en PIC 16f886 SO28, som tappar ID efter programmering.
Helt plötsligt tappade PIC´n ID efter ett antal lyckade programmeringar.
Trodde den hade pajat så jag byte ut den mot en ny.
Programmerade den nya, men den tappade id´t efter första programmeringen.
Använder mig av en Elnec Smart Prog 2, här är fel medelandet.

Kod: Markera allt

Reading device: Microchip PIC16F886 (ISP).
Checking device ID ...
Device ID Word: 3FFFh
Manufacturer / device ID check error!
ID expected=2060h, ID read=3FFFh

Pin 1 är kopplad till MCLR och till ett 47k motstånd till +5V
RB6 och RB7 är kopplade till varsin ingång på en 74:a krets.

Allt fungerar efter första programmeringen men det går som sagt inte att programmera om det ingen.
Vill inte testa byta till en ny innan jag hittat felet.
Någon som kan ha en aning om vad som kan ha hänt?

[danwi]

Nu var det ganska länge sen jag micklade med PICar, men det låter som att du lyckats ställa om fusarna så att programmering blir omöjlig... Brukar vanligtvis vara att man råkar ställa in t.ex. extern kristall när man egentligen ska köra på intern RC-oscillator. ID:t 3FFF är bara ettor ut från PICen vilket nog är samma sak som att den inte har förstått att programmeraren försöker prata med den!

[sodjan]

> Brukar vanligtvis vara att man råkar ställa in t.ex. extern kristall när man egentligen ska köra på intern RC-oscillator.

Helt fel. Det kan man inte göra med en PIC (däremot med en annan populär mikrokontroller).

Hur är "internal-MCLR" satt/konfigurerat ?
Kan en "Elnec Smart Prog 2" hantera att man stänger av MCLR ?

[Stewal]

>Hur är "internal-MCLR" satt/konfigurerat ?
MCLR är satt på normal funtion, finns förljande att välja på.
MCLR: Normal funtion eller Alternate funtion.

[sodjan]

Vad betyder "normal" resp "alternate" i detta fall ?

En annan sak...

> Har en PIC 16f886 SO28, som tappar ID efter programmering.

Det tror jag inte. Har aldrig sett en PIC som "tappar ID".
Däremot kan det *se ut* så t.ex om programmeraren inte lyckas
få över processorn i "programming mode". Och den vanligaste orsaken
till det är att man har valt "internal-MCLR" och programmeraren
fixar inte att hantera det korrekt.

Kolla dokumentationen för din programmerare för att ta reda på hur
den hanterar "internal-MCLR".

Om du vill ha andra/bättre svar så får du se till att beskriva
vad du gär bättre. Hela kopplingen. Kör du ZIP eller ISP. O.s.v...

[danwi]

Som sagt, det var länge sen jag hackade PIC...

[Glenn]

Eller så har du lyckats lasta ner nån pinne, då kan man få sådana felmeddelanden också..

låter inte så troligt med bara 74xx kanske men..

[sodjan]

danwi> Som sagt, det var länge sen jag hackade PIC...

Ja, din beskrivning stämmer däremot bra in på vad som kallas "bricked AVR".
Så det är ju uppenbart vad du har kört istället under tiden...

En PIC kan *aldrig* "brickas" så att den inte kan programmeras om via ICSP.
Förrutom om man har en programmerare som inte klarar "internal-MCLR" (kallas
även "Vpp-before-Vdd"). Men få programmerare har problem med det i dag.

Jag kollade första inlägget igen. Först står det :

> ...efter ett antal lyckade programmeringar.

Alltså mer än *1* programmering med samma processor ?

Sen lite längre ner i samma inlägg står det :

> Programmerade den nya, men den tappade id´t efter första programmeringen.
> Allt fungerar efter första programmeringen men det går som sagt inte att programmera om det ingen.

Här skiljer sig ju felsymptomen lite. Vad var det som ändrades direkt innan den första "la av" ?
Det måste vara något i koden, inställningarna i programmeringsprogramvaran eller i hårdvaran.

[Stewal]

>Vad betyder "normal" resp "alternate" i detta fall ?
Hittar inget om det in F1 manualen, men det fungerar inte oavsett vilket.

>Om du vill ha andra/bättre svar så får du se till att beskriva
vad du gär bättre. Hela kopplingen. Kör du ZIP eller ISP. O.s.v...

Kompliterar lite till.
Som man kan se i felmedelandet så är det ISP och det är en SOIC monterat på kretskort.
ISP via en RJ12 kontakt och till Pic´n
Description of ISP connector pins:
1 - VDD power supply to programmed device
2 - PGM - Low Voltage Programming pin (ej inkopplad)
3 - Don't connect!
4 - Don't connect!
5 - Don't connect!
6 - Serial Data In/Out (RB7)
7 - GND (VSS)
8 - Serial Data Clock (RB6)
9 - GND (VSS)
10 - MCLR/VPP to programmed device

Hittade följande som kan vara som kan vara förklaringen till varför det inte fungerar.

Kod: Markera allt

WARNING: 
You have selected Internal MCLR and Internal Oscillator in your configuration settings. If your code makes use of port pins that correspond to Clock and Data pins in programming mode, you may not be able to reprogram your device. 
 
When Internal MCLR is used for programming, both Vpp and Vdd are powered together, and then Vpp is pulled high to Vihh to enter programming mode. This means that your code will be running before Vpp goes to Vihh. If that code makes use of port pins that correspond to Clock and Data pins in programming mode, there is a chance their values may not be 0, as necessary to enter programming mode. Therefore, the device could not be reprogrammed. 
 
ID Locations: 
A user may store identification information (ID) in four ID locations. It is recommended that the user use only the seven Least Significant bits (LSb) of each ID location. Locations read out normally, even after code protection. It is recommended that ID location is written as 'xx xxxx xbbb bbbb' where 'bbb bbbb' is ID information. 
 
Data for Data EEPROM have to be in the file from address 4200h. You can use also file, where data for Data EEPROM are located from address 0000h, in this case, in procedure load file, set Buffer offset for loading, option Positive offset, to 2100h (2100h is half of 4200h because buffer is organized in x16 mode, but file in x8 mode).

Då jag använder mig av både RB6 och RB7 i koden, så kan det vara anledningen till att det inte fungerar.

Lite lustigt att det fungerat tidigare och helt plötsligt inte fungerar.

[sodjan]

OK, ja det meddelandet var ju tydligt nog.
Jag misstänkte att det var just det.

Var "hittade" du det meddelandet ?
Är det något som kommer upp vid programmeringen i just ditt fall ?
Fick du i så fall detta även innan (när du programmerade om den första
processorn flera gånger) ?

Det står ju "You have selected..." vilket låter som att den kommenterar ett
faktiskt förhållande och inte bara ett generellt fall !?

Det är just detta som är problemet :

"When Internal MCLR is used for programming, both Vpp and Vdd are powered together,
and then Vpp is pulled high to Vihh to enter programming mode."

Vpp (alltså MCLR) måste dras till Vihh antingen precis *innan* Vdd kopplas in,
eller i alla fall inom en väldigt liten tidsrymd. Annars så är det precis som de säger,
programmet kommer att gå igång och eventuellt ställa om clock och data
pinnarna så att det inte går att "komma åt" processorn längre. Exakt vad som
gäller framgår av "Memory/Flash Programming Reference" för just din processor.

Nu så kan det ju vara lite problem med detta beroende på hur den krets ser ut
som man kör ICSP mot. Programmeraren måste alltså kunna styra Vdd för
processorn, och det brukar finnas begränsningar i hur många uF man får ha
i mål-kretsen ("target circuit") o.s.v...

Det är ju lite märkligt att de bara beskriver problemet utan att också ange
en lösning på det...

[Stewal]

Hittade följande text under Device Info för PIC16F886 (ISP), så det är ingen info som har poppat upp.
Har inte ändrat någon inställning i programmet, så det är samma inställningar som med den tidigare processorn.

Har märkt att en annan setup hinner processorn bota upp innan programmeringen, genom att text skrivs ut på en display och ligger kvar på den under programmeringen.
I den setupen använde jag inte RB6 och RB7 i koden. Så där funka det utan problem.

Kan lösningen vara att man lägga in en Delay i koden på någon sekund innan den hinner skriva något till RB6 och RB7.

[sodjan]

Ja, det skulle kunna fungera.
Eller att ha "power-up-timer" påslaget (minns inte namnet riktigt).
Bäst är att programmeraren själv supportar olika config fullt ut, så klart.

När jag funderar på det så blir det nog (med ledning av vad de skrev) problem
oavsett internal-MCLR eller inte eftersom de inte drar MCLR direkt från 0V till Vpp
utan låter det "mellanlanda" på Vdd (och då går applikationen igång i alla fall).
Det var ju tydligt att din kod han gå igång även tidigare (med ledning av LCD'n).

Är detta enbart för hobby ?
Är det för prof. användning så tycker jag att du ska skaffa en annan programmerare.
Det "räcker" med en enkel/billig PICkit2...

Eller ge fanken i RB6 och RB7...

[Stewal]

>Eller att ha "power-up-timer" påslaget (minns inte namnet riktigt).
Den är påslagen. Vad den nu har för funktion, har inte tittat på det närmare eftersom det tidigare fungerat.

Testade att köra med ID check "disabled" och lyckades enligt programmeraren radera PIC´n. Det går även att skriva, men när den verifierar så stämmer inte koden överens med varandra.

>Är detta enbart för hobby?
Nej
Finns det någon på forumet som säljer t.ex. en PICkit2.

Låter som man skall prova med en annan programmerare som klarar av att dra MCLR direkt från 0V till Vpp.

[Icecap]

73-344-18 hos ELFA kostar 299:- + moms.

[sodjan]

> Testade att köra med ID check "disabled" och lyckades enligt programmeraren radera PIC´n.

Ja, programmeraren tror det ja. Den försöker göra rätt sekvenser mot processorn,
men utan att kontrollera/verifera så vet den ju inte vad som faktiskt har hänt.

> Det går även att skriva,...

Och igen, det är vad programmeraren *TROR* !
Det är precis som när man sitter och pratar med någon som i alla fall inte lyssnar.
När man sedan frågar vad det var man sa (verifierar) så har de inte an aning...

> men när den verifierar så stämmer inte koden överens med varandra.

Ja, då upptäcks det ju att de tidigare stegen inte fungerade...

Det kommer aldrig att fungera om inte programmeraren helt ändrar metod
för att hantera MCLR/Vpp/Vihh/Vdd, d.v.s så att programmet i proccessorn
aldrig får en chans att starta.

> >Är detta enbart för hobby?
> Nej

Ja men då så, se till att skaffa verktyg som fungerar. Eller hjälp.