movwf - osccal opcode

[dave.t]

Hi all

I am using the 12f629 and 12f675 chips and am going to use the directive:

# rom 0x000 = {opcode for movwf to osccal}

to calibrate the internal osc. What is the opcode for movwf to osccal and how is this opcode calculated\derived?
Thanks for all your help.

Dave
___________________________
This message was ported from CCS's old forum
Original Post ID: 13247

[R.J.Hamlett]

:=Hi all
:=
:=I am using the 12f629 and 12f675 chips and am going to use the directive:
:=
:= # rom 0x000 = {opcode for movwf to osccal}
:=
:=to calibrate the internal osc. What is the opcode for movwf to osccal and how is this opcode calculated\derived?
:=Thanks for all your help.
:=
:=Dave
On the 12F675, and most of the other chips like this, the calibration value is _not_ stored at address 0.
Instead it is stored at the very last address in the ROM (in the case of the 12F675, 0x3FF. The instruction takes the form of a RETLW xx code.
The opcode changes for each chip, and if you want the factory value, must be saved from the chip, before you erase it. You can empirically generate a new value, by writing a program, to output a clock, and change the value in response to an input pin, stepping through the 64 possible values (on the 675, the value is a 6 bit value using the high bits of the OSCCAL register, and recording which value is best.
Have a look at the application note:
<a href="http://www.microchip.com/download/lit/suppdoc/refernce/midrange/midsect/31002a.pdf" TARGET="_blank">http://www.microchip.com/download/lit/suppdoc/refernce/midrange/midsect/31002a.pdf</a>

Which gives details of how the OSCCAL register changes frequency.
At the end of the day, you cannot write this value into your code, except for one chip. If you are using reprogrammable parts (as in these examples), then you can read the value with your programmer, when you first get the chip, and put this value into the #ROM statement.

Best Wishes
___________________________
This message was ported from CCS's old forum
Original Post ID: 13249

[dave.t]

:=:=Hi all
:=:=
:=:=I am using the 12f629 and 12f675 chips and am going to use the directive:
:=:=
:=:= # rom 0x000 = {opcode for movwf to osccal}
:=:=
:=:=to calibrate the internal osc. What is the opcode for movwf to osccal and how is this opcode calculated\derived?
:=:=Thanks for all your help.
:=:=
:=:=Dave
:=On the 12F675, and most of the other chips like this, the calibration value is _not_ stored at address 0.
:=Instead it is stored at the very last address in the ROM (in the case of the 12F675, 0x3FF. The instruction takes the form of a RETLW xx code.
:=The opcode changes for each chip, and if you want the factory value, must be saved from the chip, before you erase it. You can empirically generate a new value, by writing a program, to output a clock, and change the value in response to an input pin, stepping through the 64 possible values (on the 675, the value is a 6 bit value using the high bits of the OSCCAL register, and recording which value is best.
:=Have a look at the application note:
:= <a href="http://www.microchip.com/download/lit/suppdoc/refernce/midrange/midsect/31002a.pdf" TARGET="_blank"> <a href="http://www.microchip.com/download/lit/suppdoc/refernce/midrange/midsect/31002a.pdf" TARGET="_blank">http://www.microchip.com/download/lit/suppdoc/refernce/midrange/midsect/31002a.pdf</a></a>
:=
:=Which gives details of how the OSCCAL register changes frequency.
:=At the end of the day, you cannot write this value into your code, except for one chip. If you are using reprogrammable parts (as in these examples), then you can read the value with your programmer, when you first get the chip, and put this value into the #ROM statement.
:=
:=Best Wishes

Thanks R.J.
Does the 12f675 start on reset at location 0x3ff where the calibration value is stored, and also has the instruction to load that value into the working register then roles over to 0x000?. So if I force the opcode to move the calibration value from 'w' to osccal to be at 0x000 by the instruction:

#rom 0x000={opcode movwf oscal}

The internal osc will have the calibration value? And all will be well? If this is right what is the the hex value for the opcode 'movwf to osccal' for the 12f675 and how do you derive the hex value for the opcodes - I hope this makes sense!

#rom 0x000={0x00xx} where xx is the instruction
movwf osccall
Kind regards
Dave
___________________________
This message was ported from CCS's old forum
Original Post ID: 13253

[R.J.Hamlett]

:=:=:=Hi all
:=:=:=
:=:=:=I am using the 12f629 and 12f675 chips and am going to use the directive:
:=:=:=
:=:=:= # rom 0x000 = {opcode for movwf to osccal}
:=:=:=
:=:=:=to calibrate the internal osc. What is the opcode for movwf to osccal and how is this opcode calculated\derived?
:=:=:=Thanks for all your help.
:=:=:=
:=:=:=Dave
:=:=On the 12F675, and most of the other chips like this, the calibration value is _not_ stored at address 0.
:=:=Instead it is stored at the very last address in the ROM (in the case of the 12F675, 0x3FF. The instruction takes the form of a RETLW xx code.
:=:=The opcode changes for each chip, and if you want the factory value, must be saved from the chip, before you erase it. You can empirically generate a new value, by writing a program, to output a clock, and change the value in response to an input pin, stepping through the 64 possible values (on the 675, the value is a 6 bit value using the high bits of the OSCCAL register, and recording which value is best.
:=:=Have a look at the application note:
:=:= <a href="http://www.microchip.com/download/lit/suppdoc/refernce/midrange/midsect/31002a.pdf" TARGET="_blank"> <a href="http://www.microchip.com/download/lit/suppdoc/refernce/midrange/midsect/31002a.pdf" TARGET="_blank"> <a href="http://www.microchip.com/download/lit/suppdoc/refernce/midrange/midsect/31002a.pdf" TARGET="_blank">http://www.microchip.com/download/lit/suppdoc/refernce/midrange/midsect/31002a.pdf</a></a></a>
:=:=
:=:=Which gives details of how the OSCCAL register changes frequency.
:=:=At the end of the day, you cannot write this value into your code, except for one chip. If you are using reprogrammable parts (as in these examples), then you can read the value with your programmer, when you first get the chip, and put this value into the #ROM statement.
:=:=
:=:=Best Wishes
:=
:=Thanks R.J.
:=Does the 12f675 start on reset at location 0x3ff where the calibration value is stored, and also has the instruction to load that value into the working register then roles over to 0x000?. So if I force the opcode to move the calibration value from 'w' to osccal to be at 0x000 by the instruction:
:=
:= #rom 0x000={opcode movwf oscal}
:=
:=The internal osc will have the calibration value? And all will be well? If this is right what is the the hex value for the opcode 'movwf to osccal' for the 12f675 and how do you derive the hex value for the opcodes - I hope this makes sense!
:=
:= #rom 0x000={0x00xx} where xx is the instruction
:= movwf osccall
:=Kind regards
The 'downside' of doing this, is that you will run out of space between the start of memory, and the location for the interrupt vector. If you want to use interrupts, avoid this design...
There is no 'default' transfer. The chip wakes up with 128 in the OSCCAL register, and the program has to transfer the required data into the register. CCS does this automatically at the start of the main code, if the internal oscillator is selected, by doing a call to 0x3FF, and then transferring the byte returned into the OSCCAL register. This would override the value you are setting at address 0.
Hence if you know what value you need to return, code it as RETLW xx, at address 0x3FF, which will then be compatible with the standard code.
The chips you mention, do not automatically load the calibration value into the W reg. The 12C508, and it's relatives do (on these the calibration is stored as a MOVLW xx instruction, at the top of memory), but on the latter chips, the seperate call is used.

Best Wishes
___________________________
This message was ported from CCS's old forum
Original Post ID: 13256

[johnpcunningham@hotmail.c]

This info is for the 674s but should apply:

If you have used the PIC Wizard in CCS, the commands for retrieving the stored value are created for you. I've done this a couple ways. If you are using windowed devices you should always read the new-unprogrammed device to determine the calibration value and write it on the bottom of the chip. After erasing the part, you can restore the calibration value with the #ROM command. Assume you have read the device and your calibration value is 0x9C, then you should put the following line in you code:
//0x34 is RETLW op code and 0x9C is calibration value
#ROM 0x3ff = {0x349C}

change the calibration value each time you use a different part (if the cal value is different) but make use the 0x34 reamins the same and in the correct location (i.e 0x349C or 0x349A or......)

**********************************
If you did not use the PIC wizard to setup your project and you are testing code and programming over and over with a windowed part, a simple way would be to write the OSCAL value directly with the known calibration value. If your calibration value was 0x9C then:

#byte OSCAL 0x8F //address of OSCAL register
#define CALVALUE 0x9C //calibration value

void main()
{
OSCAL = CALVALUE;

//other code...
}

You need to set the fuses setting in CCS to use the internal oscillator for this approach to work. When you program the part, change the settings in the programmer (not CCS) to use the internal oscillator. This way, the CCS code generated does nto do a fetch to 0x3ff and the OSCAL register gets loaded with the correct value.
----------------
Another way would be to use inline assembly to retreive the value from ROM. I haven't tested the code below but it should be correct or close. Using 0x9C as the calibration value:

-------------------
If you are in production, simply skip the #ROM statement since they are all fresh chips and the RETLW instruction and the calibration value are already there.

JC
___________________________
This message was ported from CCS's old forum
Original Post ID: 13265