Three Bytes at the end of Memory of PIC12C508 - Page 1
Forum section: electronics / general

author: PICmonster
author_rank: Regular Contributor
timestamp: March 31, 2015, 03:02:10 pm
content: Dear AllI 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:00000001FFAny Idea what they are?

author: helius
author_rank: Super Contributor
timestamp: March 31, 2015, 03:16:56 pm
content: OSCCAL instructions

author: Howardlong
author_rank: Super Contributor
timestamp: March 31, 2015, 03:18:00 pm
content: 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.

author: Skimask
author_rank: Super Contributor
timestamp: March 31, 2015, 03:19:28 pm
content: http://ww1.microchip.com/downloads/en/DeviceDoc/30557g.pdfSection 2.3

author: PICmonster
author_rank: Regular Contributor
timestamp: March 31, 2015, 03:30:18 pm
content: Thanks to everyone for your help

author: Ian.M
author_rank: Super Contributor
timestamp: March 31, 2015, 04:17:57 pm
content: The last one looks bad (:0203FE00FF0FEF)That's all 12 bits of the last program memory word containing '1' when it should be a MOVLWnnopcode (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.

author: 22swg
author_rank: Frequent Contributor
timestamp: April 01, 2015, 07:59:42 am
content: So how did you read the 12C508 ? You switched threads

author: macboy
author_rank: Super Contributor
timestamp: April 01, 2015, 02:22:49 pm
content: 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?

author: Ian.M
author_rank: Super Contributor
timestamp: April 01, 2015, 02:43:45 pm
content: 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 programMidrange (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 (1412bit core).Edit: Correction to last line

author: macboy
author_rank: Super Contributor
timestamp: April 01, 2015, 03:05:57 pm
content: Quote from: Ian.M on April 01, 2015, 02:43:45 pm12C5xx 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.

author: Ian.M
author_rank: Super Contributor
timestamp: April 01, 2015, 03:10:16 pm
content: 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.