12F508 - True reset vector location

[eblc1388]

The datasheet does not make it clear the actual reset vector location. From the code attached, it could mean it is the top memory location as 'W' in 12F508 already contains the OSCCAL value after power ON reset.

Either the reset vector is located at 0x000 and the OSCCAL value is loaded in 'W' via hardware or the reset vector is at 0x1FF instead.

Any comment?

    ;------------  for 12F508  ------------------------------------
0000  ORG 0
0000  Start
0000  0025 movwf OSCCAL ; calibrate
0001  0A7A goto Main
    ;---------------------------------------------------------

 

[Nigel Goodwin]

From the data sheet:

Note 1: Address 0000h becomes the
effective Reset vector. Location
03FFh contains the MOVLW XX
internal oscillator calibration value.

Pretty obviously the physical reset vector is the very top of program memory, and then immediately loops to 0x0000 - but does it reall matter?.

 

[ericgibbs]

The datasheet does not make it clear the actual reset vector location. From the code attached, it could mean it is the top memory location as 'W' in 12F508 already contains the OSCCAL value after power ON reset.

Either the reset vector is located at 0x000 and the OSCCAL value is loaded in 'W' via hardware or the reset vector is at 0x1FF instead.

Any comment?

    ;------------  for 12F508  ------------------------------------
0000  ORG 0
0000  Start
0000  0025 movwf OSCCAL ; calibrate
0001  0A7A goto Main
    ;---------------------------------------------------------

hi,
The datasheets shows the reset vector at 0000h.
Is this what you mean.?

 

[Nigel Goodwin]

hi,
The datasheets shows the reset vector at 0000h.
Is this what you mean.?

It actually says EFFECTIVE reset vector, and not the physical reset vector.

 

[eblc1388]

Pretty obviously the physical reset vector is the very top of program memory, and then immediately loops to 0x0000 - but does it reall matter?.

Sort of. I therefore have to must make sure the instruction at 0x1FF is a valid PIC instruction and not some data code, which could be seen by the PIC to be a SLEEP instruction.

@ericgibbs,

No. That's not what I meant. I tend to agree with Nigel that the Reset vector on 12F508 has been changed to top of flash memory instead of the usual 0x00.

 

[Nigel Goodwin]

Sort of. I therefore have to must make sure the instruction at 0x1FF is a valid PIC instruction and not some data code, which could be seen by the PIC to be a SLEEP instruction.

As it says throughout the datasheet, and as any decent programmer should do automatically, you should NEVER overwrite or erase the OSCAL value at 0x1FF - ensure your proogrammer handles this correctly, and there's nothing else to be concerned about.

Easy to check:

1) Read the PIC and write down the value at 0x1FF.
2) Erase the PIC.
3) Read the PIC again, and confirm 0x1FF is still the previous value.

For a programmer software writers point of view, the erase routine first reads the value and stores it, next erases the entire PIC, then writes the single value back - and verifies it. Likewise when writing to the chip, the software should first read the OSCAL value, and store it ready to be written back.

I 'think' I added a menu option to WinPicProg to allow it to be bypassed, so you can alter the value if you need to - as otherwise it wasn't possible to do so.

 

[eblc1388]

I 'think' I added a menu option to WinPicProg to allow it to be bypassed, so you can alter the value if you need to - as otherwise it wasn't possible to do so.

One can load whatever value into OSCCAL at the start of the program. No memory gain of relying on executing the OSCCAL value instruction at top of memory.

I would much prefer the PIC to start at 0x00 and if I want to do OSC calibration, which I seldom do, I then make use of the data saved in 0x1FF. Alternatively, I can also hard code the same value in my program start code and use all the space in that 256-word page for table use.

A reset vector at 0x00 is much more flexible for the user. However, since OSCCAL is not in reach by "CALL" instruction for 12F509 without first switching banks, Microchip might have a valid reason to modify the reset vector in this way. Instead of changing banks and perform a CALL, a simple "movwf OSCCAL" is all that is needed at 0x00 to perform the calibration in total two cycles after a reset operation. (see code below for a normal calibration, which takes 7 instruction cycles)

;****************************************************************
;* Calibrating the internal oscillator
;****************************************************************
Start
       bsf     status,rp0   ; bank 1
       call    3ffh         ; get the calibration value
       movwf   OSCCAL       ; calibrate
       bcf     status,rp0   ; bank 0

Edited: Add possible reason why Microchip change the reset vector (see code above)

 

[Nigel Goodwin]

I would much prefer the PIC to start at 0x00 and if I want to do OSC calibration, which I seldom do, I then make use of the data saved in 0x1FF. Alternatively, I can also hard code the same value in my program start code and use all the space in that 256-word page for table use.

If you're down to the last word, things are getting desparate!

Move to the 12F509 and breath a sigh of relief.

 

[eblc1388]

256-word is more than sufficient for 99% of programs so in general a lot of flash memory space left even with a 512-word 12F508.

However, with a 256 entries lookup table it is not as straight forward to place it "NOT" on a page boundary without using some additional tricks.