Vägrar fungera med PIC16F676

[sheazar]

Så hittade ÄNTLIGEN vad problemet var . Varför det fungerade med asm vet jag inte men jag upptäckte att OSCCAL-värdet var inkorrekt och då jag satte detta fungerade det aldeles utmärkt

Tack så mycket för den hjälp som jag fått.

[sodjan]

Det där låter väldigt märkligt !
Kan du visa vad du gjorde ?

[Icecap]

Just OSCCAL har jag aldrig ställd i något projekt och de har fungerat ändå så för mig låter det extremt osannolikt att det är orsaken till felet, jag skulle närmre tro att instruktionen i sig har flyttat det egentliga felet på ett sätt som gör att programmet nu fungerar.

[vfr]

jag skulle närmre tro att instruktionen i sig har flyttat det egentliga felet på ett sätt som gör att programmet nu fungerar

Ja, det låter betydligt mera sannolikt. Och isåfall har du egentligen inte löst (eller ens hittat) det riktiga problemet, bara dolt det. Det brukar inte vara speciellt bra. Förr eller senare slår det alltid tillbaka. Du kanske får tillbaka felet senare när du har mycket mera saker att leta fel i. Det är alltid bättre att försöka gå till botten med dom fel som man har aktuella, istället för att ta det senare. Om det finns möjlighet.

[sheazar]

Det var när jag testade att använda pickit 2 för att ladda över hex-filen som jag upptäckte att OSCCAL hade ett ogiltigt värde. Jag har inte satt detta i koden utan jag lät bara pickit 2 ändra värdet och nu kan jag programmera PIC:en som vanligt från MPLAB. Så jag har inte ändrat någonting i min kod utan bara programmerat in ett nytt OSCCAL-värde en gång.

Problemet var ju inte att jag inte fick ett program att köra utan att jag inte fick något program skrivet i C att köra.

[sodjan]

> utan att jag inte fick något program skrivet i C att köra.

Fortfarande lite konstigt...
Gick det överhuvudtaget *in* i processorn ?
Gav PICkit2 något fel under programmeringen ?

Vänta lite här nu...
Detta är en processormodell med en RETLW instruktion inlagd från
fabrik på den sista platsen i programminnet ! Och du hade alltså
lyckats "pilla bort" den så när C-programmet sedan försökte anropa
den med ett CALL h'3FF' (vilket sannolikt läggs dit automatiskt av
kompilatorn) så gick det naturligstvis snett. Ja, så måste det vara.

En lite konstig sak är att PICkit2 borde ta hand om detta. Alla vettiga
programmerare känner till att detta ligger i minnet och ser till att läsa ut
det först (innan Erase All) för att sedan automatiskt skriva tillbaka det igen.
D.v.s utan att man gör något själv. Sannolikt finns det något sätt att
kringgå automatiken (t.ex genom att mauellt köra en separat Erase All
operation), men då ställer man till det lite för sig...

Att ditt ASM program fungerade beror på att du struntade i anropet för att
kalibrera processorn. Och nu har du en okalibrerad processor eftersom
du har tappat bort original värdet (antar jag)...

Verkar detta vara det som har hänt hos dig ?

[sheazar]

Låter väldigt rimligt hur det försvann från början har jag ingen aning om då jag endast genomförde en programmering följt av en en "erase the target device" i MPLAB. Någonting måste dock gått fel där, och jo det stämmer att jag nu dessvärre sitter på en okalibrerad processor

Tackar för förklaringen, då klarnade det ytterliggare lite

[sodjan]

> ...följt av en en "erase the target device" i MPLAB.

Ja men då så... Du har alltså raderat kalibreringen själv...

> ...Någonting måste dock gått fel där...

Inte alls! MPLAB och PICkit2 gjorde precis som du begärde.

Notera att nyare processorer inte har denna information lagrad så här.
De är fabrikskalibrerade på ett sätt som inte går att att redera efteråt...

[sheazar]

Ahh... ok då är jag med på det också trodde faktiskt att MPLAB och PICKIT sparade undan kalibreringsinformationen när man använde denna funktion.

[sodjan]

Normalt gör programmerare det när man gör en om-programmering.
D.v.s den sparar kalibreringsinfo tillfälligt under erase och skriver tillbaka
det vid programmeringen. När du bara gör en Erase All, så finns det ju
ingenstans att göra av det...