CCPR1L:CCP1CON<5:4> = ???

[Erik M]

Om vi nu börjar med att tänka det otroliga att det är som jag säger - att build går genom och samma, fungerande, kod fastnar, eller inte fastnar, då kan vi komma framåt.

Men eftersom det är denna visa hela tiden känns det fullständigt meningslöst be om hjälp.

Som exempelvis att det separata programmet för programmering, visat för PICkit 3 ovan, inte kommer igång.
Med felmeddelandet att DAT-filen inte finns i samma folder som EXE-filen, trots att de ligger där, båda två.
Samma sak på två olika datorer och oavsett om installerad från installationsskivan eller nedladdat från MC.
Och utan några varianter på installation annat än vad installationen själv gör.

[TomasL]

Så länge du inte får några felmeddelanden vid programmering, så är processorn korrekt programmerad, alltid.

[sodjan]

> Om vi nu börjar med att tänka det otroliga att det är som jag säger...

Jag brukar aldrig lita blint på vad någon säger här, oavsett vem det det är.
Vad som har betydelse är vad som visas. Kod, felmeddelanden, skärmkopior o.s.v.
Du är lite dålig på att visa "bevis" på att det som du påstår faktiskt stämmer.

När någon påstår något som låter underligt så är självklart den första
tanken misstag eller andra skitfel. Ingen underligt eller personligt. Om du
bara kan skärpa till dina beskrivningar med bättre information så får vi
något mer konkret att gå på.

> att build går genom...

Inklusive själva (om-) programmeringen av processorn?

> och samma, fungerande,...

Som ser ut hur då? Kan du fixa en liten "reproducer" som visar fenomenet?
En kort kodsnutt, minsta möjliga för att visa det.

> kod fastnar eller inte fastnar...

Vad betyder "fastnar" mer konkret? Startar processorn? Startar koden innan
den "fastnar"? Går koden fel efter att den har startat? Något annat?

> då kan vi komma framåt.

Vi kan komma framåt när du visar något konkret. Kod, felmeddelanden, skärmkopior o.s.v.
Det är självklart helt omöjligt att säga något utifrån vaga beskrivningar, gissningar och
egna tolkningar.

[Erik M]

På de punkter som är enkelt och direkt synliga, nej.
Build anges som genomgången till success - BUILD SUCCEDED
Program the target device ger sådant som -
Programming Target
Erasing Target
Programming Program Memory (0x0 - 0x8F)
Verifying Program Memory (0x0 - 0x8F)
Programming Configuration Memory
Verifying Configuration Memory
PICkit 2 Ready

Target lyser när PICkit2 står med drivspänning.
Busy lyser under programmeringen.

På LPC'n är både SW1 och RP1 bortkopplade (klippta).

Vad gäller ändring i koden ändras endast sådant som BTFSS och BTFSC.
Givetvis - annars är det meningslöst göra felsökning, det vet var och en med grundläggande förståelse för felsökning och problemlösning. Annat är ren felökning och problemsölning, inkluderande att.... Skitak samma, skulle vilja ha en bättre förståelse av ex funktionerna runt pin tre, NOT_MCLR, men det får anstå.
Liksom varför kravet på att avsluta labels med kolon tagits bort, det ställer till det vid felsökning.
Hur man kopplar in och använder debug vore oxå bra få hjälp med att komma över de initiala trösklarna, att använda Debug i ett läge som detta vore ju himla käckt. Exempelvis.

Nå, jag tackar för den hjälp jag erhållit, den har varit till stor hjälp.

Å hittar jag något lurigt MC hittat på och inte förklarat, som hur de "avrundar" vid minskad upplösning och liknande, så återkommer jag.

[TomasL]

Jättebra, att det skall ta så förbaskat många inlägg innan du poster nödvändig information.
Då återstår endast ett par saker:
Programmerar du innifrån MPLAB eller använder du det separata programmet?
Vad är LPC?

Beträffande debug, så väljer du "Debug Build" i MPLAB, finns en ruta för detta i verktygslisten.
Sedan går du in under menyn "Debug" och väljer PICKIT2 som debugverktyg, eventuellt kan du få gå in och avmarkera PICKIT2 i menyn "Programmer"
Därefter kör du en BuildAll och därefter en programmering innifrån MPLAB.
När det är klart, helt utan felmeddelanden eller varningar så kan du köra programmet innifrån MPLAB och singelstega dig fram instruktion för instruktion, naturligtvis måste din PICKIT vara inkopplad hela tiden.

Beträffande RESET-pinnen (den du kallar NOT_RESET) så används den dels för att resetta processorn, när den hålls låg och när den är hög så kan processorn köra.
Den används också för att försätta processorn i programmeringsläge.
Så, den skall pullas upp med 100k mot VDD, för att fungera riktigt.

Eftersom du inte får några felmeddelanden vid proggrammeringen, tvärtom, så är processorn programmerad med den kod du senast byggde, om du programmerar innifrån MPLAB, och använder du det externa programmet så är det den hex-fil som du valt.
Eventuella konstigheter beror i så fall på antingen din elektriska inkoppling av processorn eller att du gjort fel i koden.

[sodjan]

För att köra hårdvaru debug direkt i processorn med en 12F683 så
krävs en speciell "header" med en debug version av processorn (har
fler pinnar än en standard 12F683). Det du kan göra är att köra
simulering med MPSIM direkt i MPLAB.

För övrigt håller jag med om Tomas analys. Om build (inkl programmering)
går bra, så är det antingen hårdvaran eller något logiskt fel koden. Vi vet
inte varken hur hårdvaran eller koden ser ut, så vi är lite "lost" där...

"LPC" antar jag är "Low Pin Count" kortet till PICkit2 (?). Det kommer (kom)
som standard tillsammans med "PICkit2 Starter Kit" med en 16F690, men
det stöder även 8-pinnars modellerna som t.ex 12F863.

SW1 är reset-switchen. Den behöver inte tas bort, det är bara att låta bli
att trycka på den.

RP1 är potten som går till RA0. Den kan tas bort (eller lyfta en änden på
R7 så är den också i praktiken bortkopplad).

http://ww1.microchip.com/downloads/en/D ... 51556a.pdf

Kör du alltid LPC kortet anslutet (och matat) från PICkit2'an?
Eller kör du det separat med egen matning?

Du skrev även:

> ...även om jag flyttar PIC'n i sig mellan programmeraren och applikationen.

De fenomen som du har beskrivit, uppträder de alltså i någon annan
hårdvarumiljö än på LPC kortet? Eller på/i båda miljöerna?

[TomasL]

Då är det uppenbarligen inte så lätt att debugga den processorn.
Förslagsvis så letar du reda på en liknande prolle, men en som du kan debugga utan adapterkort för att testa din kod på.

[sodjan]

Sen så är ju hårdvarudebuggning bara *en* metod för felsökning.
Man kommer långt med traditionella metoder också, "code review",
simuleringar, olika testkörningar, översyn av kopplingen o.s.v.

[Erik M]

Angående MCLR och MC's sätt beskriva saker hittade jag denna pärla åt er...

[Note] 3: The GP3 pull-up is enabled when configured as MCLR and disabled as an I/O in the Configuration Word.

Ordet "and" gör hela denna Note/instruktion omöjlig att uppfylla - genom att det är sagt att man ska göra samma sak två gånger... Var hittar man det andra man ska göra?

I normal konversation är detta inget problem, talad kontext hoppar helt enkelt över ordet och hur man gör är klart och tydligt - man gör något med Configuration Word.

I text som denna ska man dock då alltså hitta först "GP3 pull-up is enabled when configured as MCLR" och därefter "disabled as an I/O in the Configuration Word"... Dvs hitta hur man disable GP3(!) som I/O i Configuration Word.


Pinnen heter inte RESET, den heter MCLR, läs innantill...
...om du vill kalla den för RESET så får du ducka för Janne.


Men du Janne, om detta inträffar när inga (Inga!) ändringar skett - då blir det jobbigt.

[sodjan]

Alla kallar den för "reset pinnen" eller helt enkelt MCLR.
Att den är "aktivt låg" är en annan sak och inget man i dagligt tal (eller i skrift) bryr sig om.
Att hålla på med överstrykning ser mest fånigt ut.

> The GP3 pull-up is enabled when configured as MCLR and disabled as an I/O in the Configuration Word.

Ja visst, det finns alltid flera olika sätt att skriva i princip samma sak.

The GP3 pull-up is enabled when configured as MCLR in the Configuration Word.
The GP3 pull-up is enabled when configured as MCLR, and then disabled as an I/O, in the Configuration Word.

Har detta ställt till något faktiskt problem eller är det bara ordvrängeri?

> Men du Janne, om detta inträffar när inga (Inga!) ändringar skett - då blir det jobbigt.

Ja. Lycka till med felsökningen. Jag har inte mer att gå på.

[bearing]

För att veta när programmet "går", föreslår jag att lägga in kod som gör att en lysdiod blinkar i 1Hz eller liknande, samtidigt som resten av programmet körs. Förhoppningsvis går det att "låna" en pinne till detta.

Om lysdioden blinkar, vet du att programmet körs, d.v.s alla problem måste bero på missar i koden, och inte att kretsen är i reset eller liknande. Om du vill verifiera att programmeringen verkligen fungerar, kan du ändra blinkfrekvensen och överföra igen.

Det bästa är att använda en timer med interrupt (alternativ koll av flagga i main-loopen) för att få lysdioden att blinka. Om alla timers skulle vara upptagna går det att använda t.ex. PWM-timern med postscaler.

[sodjan]

Jag tror att det nämndes att det fanns/finns tillgång till oscilloskop så
frekvensen är inte kritisk, bara att toggla en pinne var som helst i koden.

Man kan även använda en större processor i samma generation (för
att inte få så stora skillnader) för utveckling eller bara för felsökning
av specifika delar av applikationen eller av processorn som krånglar.

[SeniorLemuren]

Som exempelvis att det separata programmet för programmering, visat för PICkit 3 ovan, inte kommer igång.
Med felmeddelandet att DAT-filen inte finns i samma folder som EXE-filen, trots att de ligger där, båda två.
Samma sak på två olika datorer och oavsett om installerad från installationsskivan eller nedladdat från MC.
Och utan några varianter på installation annat än vad installationen själv gör.

Jag använder PICkit3 så därför blev det en bild på den, men PICkit2 ser exakt likadan ut. Att du inte kan få den att fungera på 2 olika datorer verkar väldigt underlig. Jag har aldrig hitintills hör talats om att det har varit sådana problem.

Vad kör du för operativsystem, kan ju vara det som ställer till det. Jag tycker du ska lägga lite mer krut på att få igång det externa programmet. Fungerar inte det så kan det ju vara något gemensamt fel som även den interna programmeringsrutinen råkar ut för. Jag vet inte om MPLAB har en egen devicefil eller om samma fil (PK2DeviceFile.dat) används även av MPLAB. Det är ju den filen som det tydligen är något strul med.

Programet för PICkit 2 har 4 filer

PK2V023200.hex
PK2DeviceFile.dat
PICkit2V2.exe
PICkit2.ini

Jag hat testat att kopiera dessa filer till olika diskar/mappar i datorn och det funkar bara alla 4 filerna ligger i samma mapp någonstans. Svårare än så är et inte. Åtminstonde inte i XP som jag använder..

[SeniorLemuren]

I mitt föregående inlägg fanns ett citat av TS där han beskrev att det fristående PIC-programmet inte fungerade . Den texten är borttagen från TS inlägg. Det konstiga är att citatrutan i mitt inlägg från det inlägget nu är helt blankt.

Snälla, ta inte bort hela textblock det blir jävligt konstiga inlägg då.

TS uppgav att PIC-programmet klagade på att det inte fans någon DAT-fil fastän TS sade att den låg i samma mapp som EXE-filen och att programmet var testat i 2 olika datorer utan att fungera. Var det lögn och var det därför texten togs bort. Veligt som faan detta. Liknar mer och mer rent trolleri eller för mycket Jäger. Inte stor ide att försöka hjälpa till.

[sodjan]

> Det konstiga är att citatrutan i mitt inlägg från det inlägget nu är helt blankt.

Det syns i alla fall fortfarande för mig...

Håller med om att det inte är direkt enkelt at hjälpa till...