Any common cause for Invalid OSCCAL on ACL Strobe?

Wow, using the pickit erase function can render the pic unable to be programmed again? That is marketing GENIUS. Think how many more pics you can sell with a feature like that! I've only tried erase once I get the OSCCAL error, so something else is causing it. And yes I HAVE retouched the pins to try and fix unseen bridges or opens.


That still does not explain valid BEFORE adding the transistor and LED, invalid after (if I am remembering the cause and effect right here).


How would one bootstrap the osccal value back in? Would one need to add an external oscillator to make the chip programmable again?? In this mode, the pic reads back all 0's.


THX, kirk
 
Wow, using the pickit erase function can render the pic unable to be programmed again? That is marketing GENIUS.

It is probably poor PICkit programming rather than marketing genius! I'm sure there is a reason for it though.

OSCCAL can be put back and the chip can be re-programmed without an OSCCAL value.
The PICkit should be able to recognise the need to read OSCCAL and save it when programing but you have to know in advance. I was working with 12F-something-or-others and experienced this, it took me two days of changing hardware, code and reprogramming chips to work out why the chip wasnt working!

My programmer (uses PICKIT 2 SW) shows the OSCCAL value on the main screen. Try plugging the device in and doing a read or verify operation and see if OSCCAL is shown! It should be possible to put it back. My PIcKit has a menu item, but I dont think I have ever used it! Tools> set OSCCAL

I summise that if the OSCCAL is totally lost I suppose it would be possible to write any value to OSCCAL, but the oscillator would not run at the right frequency. This might not be critical for most applications. BUT I dont know about this it is only a guess!

here is a link to a site that might help.
http://picprojects.org.uk/projects/recal/recal.htm

As far as the possible hardware cause - I am not sure. :(
Do you program from PICKit standalone software or directly via MPLAB? i have had problems programming from MPlab directly. This could be the cause and not the hardware. I always use the standalone pickit software now when I program PICs.
 
I may be wrong and I can't be bothered digging through data sheets or trawling the web but I've always been of the belief that the oscal value is a trim value that allows the 4Mhz oscillator to be trimmed slightly up or down to get it precise. I'd imagine that having all zeroes or all ones in there would simply shift the frequency by a few kilohertz. If this is the case (and I've been wrong a bit lately when it comes to pics) then it won't have any effect on the strobe other than probably making them a bit more random compared to other ones that are oscillating at precisely 4MHz.
 
AAH said:
I may be wrong and I can't be bothered digging through data sheets or trawling the web but I've always been of the belief that the oscal value is a trim value that allows the 4Mhz oscillator to be trimmed slightly up or down to get it precise. I'd imagine that having all zeroes or all ones in there would simply shift the frequency by a few kilohertz. If this is the case (and I've been wrong a bit lately when it comes to pics) then it won't have any effect on the strobe other than probably making them a bit more random compared to other ones that are oscillating at precisely 4MHz.

I agree with your thoughts.
The problem is that the microprocessor may crash - or simply not run, because it enters a loop due to the reset vector (which should be a movlw) when it expects an osccal value, but it doesnt have one. Putting an OSCCAL value should fix the loop problem, but it wont be perfect timing. The deviation in frequency is only a few percent. At 4MHZ you would never see it visually!
 
I always use MPLAB and a PicStart+ or PicKit3 programmer. Can't say I've ever had an issue with any of them.

When programming PICs, there's almost never a need for erasing the chip manually first. If you're using the software correctly it all happens auto-magically. :)
 
damo1271 said:
Do you program from PICKit standalone software or directly via MPLAB? i have had problems programming from MPlab directly. This could be the cause and not the hardware. I always use the standalone pickit software now when I program PICs.


I usually do standalone- been using the pre-compiled firmware (6 of them) to try to randomize the blinky.


I will give that other link a try, however, it is very strange the part reads back ALL 0s even when erased as it should give back FF after being erased (or am I mis-remembering my old flash memory days).
 
Back
Top