Three Bytes at the end of Memory of PIC12C508

[PICmonster]

Dear All

I have been tasked with checking that the programming house is blowing the right code into the PIC12C508 devices. I am happy that they are as the check-sum matches ON ALL, additionally I have used text compare software "Beyond Compare" to view the HEX and they do compare apart from Three Bytes at the end of memory.

Below are the snippets of the end memories of three devices, as you can see three byte differ,WHY?

:1003E000210C3900360A1F0C0600AE02070C8E00E5
:0E03F0000307D70BC10C02001802100AFF0F02
:021FFE00EE0FE4
:080400000700090008000100DB
:0203FE009C0C55
:00000001FF

:1003E000210C3900360A1F0C0600AE02070C8E00E5
:0E03F0000307D70BC10C02001802100AFF0F02
:021FFE00EE0FE4
:080400000700090008000100DB
:0203FE00A00C51
:00000001FF

:1003E000210C3900360A1F0C0600AE02070C8E00E5
:0E03F0000307D70BC10C02001802100AFF0F02
:021FFE00EE0FE4
:080400000700090008000100DB
:0203FE00FF0FEF
:00000001FF

Any Idea what  they are?

[helius]

OSCCAL instructions

[Howardlong]

I believe it's the factory calibration bytes for the internal RC oscillator. Three bytes in bold, first two are the cal constant (12 bits, little endian, upper 4 bits zero), last byte is the hex file line's check sum.

I think if you try hard enough you can overwrite it, but it's not recommended, especially if you are reliant on it for a certain degree of timing accuracy.

*Edited to correct regarding how many bytes are cal constant and how many are check sum. It looks like the last example has had its cal bytes erased.

[Skimask]

http://ww1.microchip.com/downloads/en/DeviceDoc/30557g.pdf

Section 2.3

[PICmonster]

Thanks to everyone for your help

[Ian.M]

The last one looks bad (:0203FE00FF0FEF)

That's all 12 bits of the last program memory word containing '1'  when it should be a MOVLW nn opcode (0xCnn).  That's supposed to be impossible on a normal PIC12C508 as the oscillator calibration word is factory programmed and although it can be corrupted by writing a '0' to a '1' bit the chip uses EPROM memory that can only be erased from '0' to '1' by UV light, and the UV erasable windowed CERDIP PIC12C508/JW devices are no longer available.

It could be a bogus read-back caused by an unreliable connection between the device and the programmer.

[22swg]

So how did you read the 12C508  ? You switched threads 

[macboy]

It's actually two bytes that differ. The last byte on each line is the checksum, which is part of the intel hex file format, not part of the data. The other two bytes form a 12-bit instruction word (note the '0' nibble in all cases; this is the unused upper four bits of the second byte).

As with Iam.M, I am concerned about the third case ending in FF0FEF. Ignoring the EF (checksum), the instruction word is then 0FFF, which is the erased/empty state of the EPROM. It is also the instruction "XORLW 0xFF" which will simply flip all bits of the W reg and continue. This should be a "MOVLW N" where N is a 8-bit number to be optionally used to program the oscal register. This instruction looks like 0x0C?? which is what the first two examples look like. If you do not use the internal oscillator then there is nothing to worry about, as you haven't written the code to take advantage of this value. If you use it, then you have a questionable device that has not had the value factory-programmed as expected. Is it perhaps a 12F508 device that was erased?

[Ian.M]

Small correction for accuracy: 

• Baseline (12 bit core) devices with the calibration in the user FLASH use a MOVLW nn instruction for the factory OSCCAL, and start execution at the highest address, letting it wrap around to address zero to start the user program
• Midrange (14 bit core) devices with the calibration in the user FLASH use a RETLW nn instruction for the factory OSCCAL, start execution at address 0 and the user program is responsible for calling the OSCCAL RETLW.  If the RETLW is missing this usually results in a wraparound and infinite loop in the startup code.

PIC12C5xx and PIC12F5xx devices are baseline (14 12 bit core).

Edit: Correction to last line

[macboy]

PIC12C5xx and PIC12F5xx devices are baseline (14 bit core).

12C5xx are definitely 12 bit (i.e. baseline) instruction set.  This includes the 12C508 in this discussion. Actually, the term baseline was only used with the flash parts (e.g. 12F508) that used the 12 bit instruction set, "baseline flash". Anything "baseline flash" is 12-bit, including several 16Fxxx and some 10Fxxx parts .

12F5xx (only three exist: 12F508/509/510) are also 12 bit or baseline flash parts. With the exception of possibly configuration bits, the 12F508/9 are intended as drop-in replacements for the 12C508/9.

All other 12F such as 12F629/675/etc are the 14 bit midrange instruction set, and include the deeper stack, interrupts, and far more choice of peripherals.

[Ian.M]

Well, I FUBARed that didn't I. 

Of course I meant "(12 bit core)" in the last line but had a brain-fart and typed 14.