10F206 OSCCAL

[BLL]

Hi
I am new to using 10F pics. My Pickit2 programmer trod all over the OSCCAL value and erased it!
Is there any way to insert a value at I believe 0x1FF?
I have no idea what the original value was, but I saw a value of 0C1A suggested.
The backup location has been erased as well!

Thanks

Brian

[Ttelmah]

If you downgrade your PIckit2 (go and find the V1.21 PC software and firmware), this has a feature to automatically generate a 'good' value!.
It tries the values, and checks the clock being generated against the Pickit clock, to work out the number that has to be stored. A nice feature and really 'silly' that they got rid of it in the later software.

If you don't mind about your clock accuracy, then you can just store a default value in your code. However some programmers complain if the backup value does not match the normal value, so you have to change both:

[BLL]

Hi, Thanks for that and I'll follow those instructions, but I find there is another problem!
Pickit2 allows one to set an OSCCAL value in its Tools menu. When you do, it says it has programmed the device and sure enough, if I scroll down to the last hex location, there the value is. So far, so good.
Then I import my hex file produced in my v5 compiler and immediately the Pickit says the OSCCAL value is invalid and scrolling down to the last hex value shows it has been changed, so there appears to be a problem either with the hex file or Pickit's use thereof!

Any ideas please?

Brian

[Ttelmah]

Problem you are having is that when you program the code, the Pickit, then checks the programmed OSCCAL, with the stored 'reserved' value. Since this doesn't agree you then get the complaint....

You need to have a #rom in the code to set this value to match the value you are setting in the tools.

[BLL]

Hi Ttelmah
I downloaded 1.21 and as you rightly said, it produced a new OSCCAL value of 2020.
Interestingly, if I selected erase, it saved the OSCCAL value, erased the device and restored the OSCCAL value. 2.61 doesn't; it just erases EVERYTHING, including the OSCCAL value, so this obviously wasn't tested before release!
If I import my hex file into 1.21 and try to program it, it reports "Verify error in Programming" and highlights 0000 with a value of 100.
I then get a 2nd error "Verify error in UserIDs"
If I erase it again and then load v2.61, it reports a different OSCCAL value of 0CFF! If I include the 2 #rom lines in my source file and compile, then when I try and import it into 2.61, it says that the hex file is too big for the device!
Without the 2 #rom values, it loads without error but overwrites the OSCCAL value and then reports it as invalid!!
What a mess! Is there a version somewhere between 1.21 and 2.61 that will program a 10F206, I wonder?

I am completely bemused!

Brian

[BLL]

Hi Ttelmah, our messages crossed! As I said, if I put the #rom lines in with 2020 as the value, 2.61 says the hex file is too large, so I can't proceed.
Just to check, the 2 lines I am adding are:

#rom 0x204 = {0x2002}
#rom 0x1FF = {0x2002}

Brian

[Ttelmah]

Where on earth did you get 0x2002 from?.
This value is too large to fit into an instruction word.

[BLL]

0x2002 came from v1.21's OSCCAL recalculation.

Brian

[Ttelmah]

The value, has to be a machine instruction.
12bits only, with the form MOVLW xx. The MOVLW instruction codes as 0xCxx. The 'xx' is the 8bit value to be returned.
The bottom bit wants to be off (otherwise Fosc/4 gets output losing a pin).

So 0xC00 would be OK, but 0x2002, can't happen....

It almost sounds as if the programmer thinks it has a different chip, and is generating a value for that.

[BLL]

I have tried 0xc00 in the #rom statement, but when I import the hex file, that is NOT the value at 0x1FF!
I definitely have the correct chip selected.
I just don't know how to proceed.

Brian

[Ttelmah]

It appears that some copies of the software automatically write into location 0x1ff, what they are reading from the backup location. Problem is that if this has been erased, you are then shafted!...

I've found on another group, a suggestion to try manually programming the chip as a 10F222. The reason is that this chip has 1K of ROM, so should allow you to set the values into 0x1FF, and 0x204. So you'd need to just set the chip to this, and manually set the value at 0x204 to 0xC00, and then program. Hopefully if you then switch back to the 206, it'll then read this as the 'backup' value.

However it is worth noting, that the backup value, will _not_ be erased by a standard bulk erase of the chip. So I have to wonder 'how' yours got erased?. Have you successfully programmed the chip at any time?. If The ICSPCLK and DAT are reversed, the chip will read as all blank.

[BLL]

Hi
Thanks for the suggestion. I have manually selected 10F222, but the hex display still only goes as far as 0x1FF, so I can't see 0x204.

Am I doing this wrong or what?
I have yet to get this pesky device to program correctly at all!

Is there any way to read what is at 0x204?

Brian

[Ttelmah]

OK. Just checked, and it is the 10F322, that has the larger ROM space. The
poster on the thread I was looking at must have got the number confused.

That is odd though. The 'parametric search', says this is a PIC10, with 0.896KB
flash, but the data sheet still only shows the program memory going up to
0x1FF. So won't help. Duh!...

It's worse, since you should be able to set the clock value 'anyway'. It is
perfectly legitimate to adjust the stored clock value to tweak the timing, so
if it is insisting on rejecting things if the two values don't match, it is silly
Must admit I prefer the CCSLoad program, which allows you to set 0x1FF without complaint, however won't work with your programmer....

There are a huge number of threads online about this problem and the Pickit2. Generally, most do say that specific versions of the software do work to regenerate the value. Oddly the displayed value in the code, seems to incorrectly be a 16bit value, which it can't be. Suspect it is because the code routine is actually written for 'other' chips, that do use different values for the instruction, and this displays it incorrectly. However most people do seem to manage to get it working, if the chip is correctly in the programmer. However there are several thread with repeated problems and most of these seem to be that the chip is not actually connected right.

[BLL]

Hi Ttelmah
Thanks for your time and trouble. I will continue playing but I think I'll use a 12F509 instead. At least they program fine!

Thanks

Brian

[temtronic]

OK, I have to ask WHY try to use such a 'small ' PIC when we all know you'll run out of ROM, RAM or I/O pins ?
Yes, I used to like the challenge of stuffing 10K of code into 2K of space, Charlieplexing, and a hose of other 'squeeze' methods but I use the 18F46K22 for 99% of the projects here. Way overkill but I know it woeks.
Have to admit I have a few '8 pinners' collecting dust...as they were ONE pin short...sigh...
just curious
Jay