Konstig frekvens på OSC2 pinnen. PIC16F690. Hilfe!

[ElectricNooB]

Exakt, det är ytterst märkligt... Men det är en µC som har blivit omprogrammerat många gånger så kanske den har skrivit fel värde någon gång och sedan fortsatt med det. Hur det har kunnat bli så på två µC´n kan jag dock inte svara på. Min kunskap på ämnet är tyvärr mycket begränsad.

[ghu]

Det skulle vara intressant att få veta om det är Pickit 2 , Pickit 3 eller någon annan programmerare som förstört oscillatorkalibreringen.

Om det är Pickit 2 eller Pickit 3. Vilken programvara har du använt vid programmeringen, MPLAB eller fristående Pickit program?

[Icecap]

"Using a PIC16F690 programmed with an ICD2 with MPLAB 8.63 and Hitech compiler 9.60 or using MPLAB 8.66 with PicKit3 and Hitech compiler version 9.80. Within 60 micros we found 5-6 devices with high error on the oscillator frequency (higher than 5%)."

Jag skulle tro att PICKit2 bara gör som den är tillsagt medan Hitech kompilern kan ha fuffens för sig...

[ElectricNooB]

Jag använder MPLAB v8.84 med HI-TECH 9.83 (Lite Mode) compiler. Programmeraren är en Pic kit 3.

Men det vekar vara fler som har problem med att OSCCON blir korrupt. Vissa råder en tom. att skriva ned det innan man programmerar

[sodjan]

Det vore intressant att se HEX filen från en sådan kombination.
Det måste finnas något i den som strular till programmeringen.

Det är ju i ingen konst att skapa en section med ORG eller CODE
på rätt adress (0x2008), och det är möjligt att någon bugg eller
liknande i kompilatorn skapar data till den adressen...

Och det går ju bra att flasha utan en erase, men det blir en
OR med det som redan ligger där.

[xxargs]

en check

hur mättes frekvensen, om det var på oscilloskop - var alla knappar i kalibreringsläget (nu tänker jag på svepet) - frekvens kollad mot känd kristall som svänger etc.

Nu vet jag att detta är basic-grejor rent mättekniskt - men jag nämner det i allafall, alla har gjort miss på det här någon gång och man håller på att leta ihjäl sig på helt andra saker som i slutändan beror på mätfel i början... och ju mer generande det är, desto mindre risk är att man gör om felet någonsin mer

[sodjan]

Det är ju nu ganska uppenbart att det var problem med
kalibreringsinformation i den ena processorn.

[blueint]

Fast det skadar ju inte att dubbelkolla ..

Kanske man kan använda oscilloskopet för att kalibrera in kretsen igen?
Hur många bitar består kalibreringskoden av? och kan man lätt ändra den?

[sodjan]

OK, här är jag inte med...
Vad är det för information som du söker?
Som alltså inte redan finns i tråden?

> Det ska vara bit 12-6 som är kalibreringen.
> Alltså : "21FA" = "10 0001 1111 1010"
> så kalibreringen skulle i mitt fall vara "0000111"

> Det är ju i ingen konst att skapa en section med ORG eller CODE
> på rätt adress (0x2008), och det är möjligt att någon bugg eller
> liknande i kompilatorn skapar data till den adressen...

LKR filen har färdig section för cal-data :

Kod: Markera allt

CODEPAGE   NAME=.idlocs    START=0x2000            END=0x2003         PROTECTED 
CODEPAGE   NAME=devid      START=0x2006            END=0x2006         PROTECTED 
CODEPAGE   NAME=.config    START=0x2007            END=0x2007         PROTECTED 
CODEPAGE   NAME=.calib     START=0x2008            END=0x2008         PROTECTED 
CODEPAGE   NAME=eedata     START=0x2100            END=0x21FF         PROTECTED 
...
...
SECTION    NAME=PROG0      ROM=page0           // ROM code space - page0
SECTION    NAME=PROG1      ROM=page1           // ROM code space - page1
SECTION    NAME=IDLOCS     ROM=.idlocs         // ID locations
SECTION    NAME=CALIBR     ROM=.calib          // Calibration bits location
SECTION    NAME=DEEPROM    ROM=eedata          // Data EEPROM
...

Det som saknas är att testa det...