Invalid OSCCAL Value detected PICKIT3 PIC10F200

Discussion in 'Embedded Systems and Microcontrollers' started by RodneyB, Aug 23, 2015.

  1. RodneyB

    Thread Starter Well-Known Member

    Apr 28, 2012
    I have been trying to load code into my PIC10F200. I however keep getting the above error.
    I am not sure what causes it or how to fix it. I have attached a screen shot of the problem.
    I change the PIC10F200 and still had the problem
    I have searched the Web unsuccessfully and tried the microchip forum and had no answers.

    Any advice will be greatly appreciated

    Thank you in advance
  2. JohnInTX


    Jun 26, 2012
    Its hard to read your screen shot but usually this error occurs when your programmer clobbers the factory oscillator calibration. This calibration value is stored as a MOVLW xx instruction at 0xFF - the reset vector. On reset, this value will be loaded into W, the PC will roll over to 000h and your program is supposed to MOVWF OSCCAL to calibrate the oscillator.

    The chip programmer must save this value then restore it when programming or you'll get an error - check its settings. A backup value is stored at 104h (in the config memory) that is not normally erased during programming. You can restore the factory value manually by poking MOVLW xx into program memory at 0FFh. See the 10F200 Programming Spec for more info.

    Good luck
  3. RodneyB

    Thread Starter Well-Known Member

    Apr 28, 2012
    Thanks very much, as a beginner what most of you have written I cant follow.

    Code (C):
    2. #include <xc.h>
    4. // PIC10F200 Configuration Bit Settings
    5. #pragma config WDTE = OFF  // Watchdog Timer (WDT disabled)
    6. #pragma config CP = OFF  // Code Protect (Code protection off)
    7. #pragma config MCLRE = ON  // Master Clear Enable (GP3/MCLR pin function  is MCLR)
    8.   // Because PIC10F200 doesn't have configurable POR or BOR,
    9.   // I advise an external RC reset on /MCLR.
    12. #define  _XTAL_FREQ  4000000  //4Mhz INTOSC
    13. #define RUN_TIME  (60*1)
    14. #define START_TIME  (30*1)
    16. // Hardware Support
    18. #define SW  GPIObits.GP0
    19. #define LED1 sGPIObits.GP1
    20. #define LED2 sGPIObits.GP2
    22.   //  6543210
    23. #define myTRIS 0b1001  // sets input output bits.
    25. // Port Shadowing
    26. volatile unsigned char sGPIO=0; // Port shadow register (global)
    27. #define sGPIObits (*(GPIObits_t * volatile) &sGPIO)
    28. #define updGPIO()  (GPIO = sGPIO)
    30. // Time to Ticks scaling for Timer 0 half period
    31. #define Time2Ticks(t) ((unsigned int)((t)*(float)_XTAL_FREQ/(4.0*256*128)))
    33. unsigned int ticks;
    35. void main (void) {
    37.   GPIO = 0;
    38.   OPTION = 0xC7; // /GPWO off, /GPPU off, T0CS internal, -, PSA TMR0, PS 1:256
    39.   TRISGPIO = myTRIS;
    41.   ticks = Time2Ticks(START_TIME);
    43. while(1) { // loop forever
    45.   //Handle timer
    47.   if (TMR0&0x80){ //check the high bit
    49.   TMR0&=0x7F; //clear it
    51.   if(ticks) --ticks; //decrement tick count
    52.   }
    54.   //Handle Switch
    56.   if(SW==1 && ticks==0){
    58.   ticks =Time2Ticks(RUN_TIME);
    59.   }
    60.   //Handle LED
    62.   if(ticks) {
    64.   LED1 =1;
    66.   }
    67.   else {
    69.   LED1 = 0;
    71.   }
    73.   updGPIO();  // Actual update the GPIO port from the shadow register
    74.   __delay_ms(10); //*MUST* maintain loop rate >30Hz to avoid missing Timer 0 half periods
    75.   // Caution: using the compiler generated delays costs two bytes of RAM
    76. }
    77. }
    I am not sure in this code where the OSCCAL is set
    Last edited: Aug 23, 2015
  4. JohnInTX


    Jun 26, 2012
    OK. Since you are programming in C, you don't have to worry about moving W to OSCCAL when starting, the C startup code does that for you.

    You probably should:
    Configure the PK3 to preserve memory locations 0xfe through 0xff when programming - I tried mine and it doesn't seem to preserve this important location automatically. Do it in MPLABX->project properties->PK3->Memory Ranges. Uncheck the 'Let Tool Decide Ranges' and tell it to preserve 0xFE-oxFF.
    PICkit2 had an ability to recover the calibration value - I don't know if PK3 does.
    If you use the IPE (Integrated Programming Environment) you can poke 0C00 into the last word of program memory after loading your hex file. Then set the ranges there to preserve 0xfe-0xff and it should work.

    I don't use these much so that's about all I know about it. You can wait for someone else here or submit a ticket to Microchip Support and ask them how to restore / preserve the calibration value.

    Good luck!
    RodneyB likes this.
  5. RodneyB

    Thread Starter Well-Known Member

    Apr 28, 2012
    Thank you

    In MPLAB v8.9 I cant find project properties->PK3->Memory Ranges.
  6. JohnInTX


    Jun 26, 2012
    That's for MPLABX. Its always good to post what you are using..

    For MPLAB 8.x, try Programmer->Select Programmer-> PICkit3 then:
    Select Allow PICkit3 to select memories and ranges then..
    Check Preserve Program Memory Range and specify FE through FF.

    That's a guess - I'm working on getting something out BUT, the last time I messed with the 10F I also clobbered the factory config for the oscillator. I'll shoot them a ticket and see what they say. Meanwhile, try this.

    Build your project. DON'T check Preserve Program Memory Range in PK3 Settings in the programmer setup.
    Click View->Program Memory. The last location (FF) should be Cxx. It probably won't be. Click the program memory location and enter C00 ( which is MOVLW 00 ; the default OSCCAL value). Program the chip. That will at least suppress the error and set the oscillator to some default value.
    After that, try the Check Preserve Program Memory Range and specify FE through FF procedure to preserve the value.

    When (If!) that works, the NEXT chip you program should be OK. I don't know if all of this will work but that's what I would do.

    I don't know why all of this shouldn't be taken care of in default configurations but I will ask uCHIP and see. I played around with 10F awhile back and got the same problem but never resolved it.

    Time to do that. Give it a try and see if you at least can suppress the error...

    Have fun.

    EDIT: I opened a ticket with uCHIP, we'll see what they say.
    Last edited: Aug 23, 2015
    RodneyB likes this.
  7. JohnInTX


    Jun 26, 2012
    @RodneyB uCHIP says that a Microchip programmer will save/restore the value. Hmmm... I lost my cal values and only use uCHIP stuff. I'll drag some of it out in the next couple of days and see what's what.
  8. JohnInTX


    Jun 26, 2012
    So.. its unclear how these things happen and uCHIP says that it shouldn't but I was able to restore my blown value and suppress the Invalid Calibration message like this:

    MPLAB 8.63 (probably good for all 8.x).
    PK3 selected as Programmer then:
    Programmer->Reconnect - that should find your chip and complain about the Invalid Calibration.
    Load your code if you want, its not necessary for this.

    On the Program Memory tab: ensure that Allow PICkit3 to select memories and ranges and Erase all before Program are checked.
    On the Calibration Memory tab: Check the Allow PICkit3 to program calibration memory and enter 00 in the movlw box. Click OK.
    Click Programmer->Program or the icon on the toolbar.
    Click Programmer->Read or the icon on the toolbar to load the image.

    Click View->Program Memory and click the Symbolic tab. Scroll to the bottom. At Address FF, you should see MOVLW 0x00. This is your restored calibration constant.
    Be sure to visit Programmer->Settings and uncheck Allow PICkit3 to program calibration memory to avoid clobbering it again.

    So far all this does is put something into the cal constant to suppress the error and set the oscillator to the center frequency. You'll have to check the timing and adjust the cal constant for now. Microchip says that none of their programmers will read the backup value.... Pic

    Until you get a handle on what went wrong, I would suggest that you immediately read any new chips and log the cal value in case you have to restore it.

    If I hear anything more on the ticket, I'll let you know.

    Good luck.

    BTW: PICkit2 with the standalone programming software has an auto-recover function for the calibration value..
    RodneyB likes this.
  9. RodneyB

    Thread Starter Well-Known Member

    Apr 28, 2012
    I have been away will do this tomorrow and report back to you.