Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

Know about OSCCAL and solve my Hex file flashing problem

Status
Not open for further replies.

Arya Kumar

Member level 4
Joined
Aug 25, 2013
Messages
73
Helped
11
Reputation
22
Reaction score
11
Trophy points
8
Activity points
713
Controller- PIC16f676
Debugger - PICKIT2
Generated hex file via Mikroc compiler

During code flash via PICKIT2 it says Invalid OSCCAL value.
What i learnt about OSCCAL value is:

internal RC oscillator is not as accurate as crystal. To compensate for the inherent inaccuracy, microchip uses a calibration scheme. The speed of the internal RC oscillator can be varied over a small range by changing the value of the OSCCAL register

So i feel i should not have changed my OSCCAL value.
I need following clarification:
OSCCAL value comes with the hex file i genearate , so to not change OSCCAL value should i alter hex file everytime at the last last address?
how to get back old OSCCAL value?
 

Pickit2 will generate a new OSCCAL value for the device if you tell it to. Look under the 'Tools' in the Pickit window. It calibrates the internal 4MHz oscillator, not the RC one.

The error message is generated when the 'RETLW xx' instruction at address 0x3FFF is overwritten by your own program or is erased. That address is reserved for holding the instruction to load W with the factory calibration value. Pickit2 checks the instruction is there and warns you if it isn't. If you are not using the internal 'INTOSC' oscillator or if the application is not speed critical, you can ignore the warning.

Brian.
 

Actually i was unable to program the controller. And i was getting error of wrong OSCCAl value.
Later at end of the day i realized the problem was due to long USB cable.
I interchanged with short usb cable that works good now.
I thought OSCCAL is the culprit.
Still confused how longer USb cable can create problem? When noise handling is there in USB

Thanks.
 

Status
Not open for further replies.

Similar threads

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top