Bad fuse option for PIC12F629?

[Warren Massey]

<font face="Courier New" size=-1>I have been working with the PIC12F629 for the past few weeks and am now convinced that CCS should not be offering the following fuse option:

BANDGAPLOW (=00) Lowest Bandgap voltage or
BANDGAPHIGH (=11) Highest Bandgap voltage

For one thing, Microchip Tech Support has confirmed to me that "there are 4 total settings for the bandgap calibration bits." These two bits represented by this option can, and do, take on values other than 00 and 11. If this fuse option were retained (which I don't think should happen) it would also need to have 01 and 10 options to be complete. (The Microchip datasheet just listed the two extreme values; it did not mean to imply that nothing fell between the extremes.)

I think the fuse option should be eliminated altogether however, since programmers of these chips (such as the Warp-13 CCS sells) do not allow these bits to be changed from what is already in the chip. The PIC12F629 datasheet has this to say about those bits:

From <a href="http://www.microchip.com/download/lit/pline/picmicro/families/12f6xx/41190c.pdf" TARGET="_blank"> <a href="http://www.microchip.com/download/lit/pline/picmicro/families/12f6xx/41190c.pdf" TARGET="_blank">http://www.microchip.com/download/lit/pline/picmicro/families/12f6xx/41190c.pdf</a></a>
"The Bandgap Calibration bits are factory programmed and must be read and saved prior to erasing the device as specified in the PIC12F629/675 Programming Specification. These bits are reflected in an export of the configuration word. Microchip Development Tools maintain all calibration bits to factory settings."
And from the PIC12F629/675 Programming Specification at <a href="http://www.microchip.com/download/lit/suppdoc/specs/41173b.pdf" TARGET="_blank"> <a href="http://www.microchip.com/download/lit/suppdoc/specs/41173b.pdf" TARGET="_blank">http://www.microchip.com/download/lit/suppdoc/specs/41173b.pdf</a></a>
"Note: The OSCCAL word and BG bits must be read prior to erasing the device and restored during the programming operation. OSCCAL is at location 0x3FF and the BG bits are bits 12 and 13 of the configuration word (0x2007)."

So, given that Microchip doesn't want these values modified and the programming systems do not support their modification, I cannot see why this fuse exists within the compiler.

I emailed CCS a couple of weeks ago asking them about this but, so far, have not heard anything back from them.</font>
___________________________
This message was ported from CCS's old forum
Original Post ID: 13596

[R.J.Hamlett]

:=<font face="Courier New" size=-1>I have been working with the PIC12F629 for the past few weeks and am now convinced that CCS should not be offering the following fuse option:
:=
:= BANDGAPLOW (=00) Lowest Bandgap voltage or
:= BANDGAPHIGH (=11) Highest Bandgap voltage
:=
:=For one thing, Microchip Tech Support has confirmed to me that "there are 4 total settings for the bandgap calibration bits." These two bits represented by this option can, and do, take on values other than 00 and 11. If this fuse option were retained (which I don't think should happen) it would also need to have 01 and 10 options to be complete. (The Microchip datasheet just listed the two extreme values; it did not mean to imply that nothing fell between the extremes.)
:=
:=I think the fuse option should be eliminated altogether however, since programmers of these chips (such as the Warp-13 CCS sells) do not allow these bits to be changed from what is already in the chip. The PIC12F629 datasheet has this to say about those bits:
:=
:=From <a href="http://www.microchip.com/download/lit/pline/picmicro/families/12f6xx/41190c.pdf" TARGET="_blank"> <a href="http://www.microchip.com/download/lit/pline/picmicro/families/12f6xx/41190c.pdf" TARGET="_blank"> <a href="http://www.microchip.com/download/lit/pline/picmicro/families/12f6xx/41190c.pdf" TARGET="_blank">http://www.microchip.com/download/lit/pline/picmicro/families/12f6xx/41190c.pdf</a></a></a>
:= "The Bandgap Calibration bits are factory programmed and must be read and saved prior to erasing the device as specified in the PIC12F629/675 Programming Specification. These bits are reflected in an export of the configuration word. Microchip Development Tools maintain all calibration bits to factory settings."
:=And from the PIC12F629/675 Programming Specification at <a href="http://www.microchip.com/download/lit/suppdoc/specs/41173b.pdf" TARGET="_blank"> <a href="http://www.microchip.com/download/lit/suppdoc/specs/41173b.pdf" TARGET="_blank"> <a href="http://www.microchip.com/download/lit/suppdoc/specs/41173b.pdf" TARGET="_blank">http://www.microchip.com/download/lit/suppdoc/specs/41173b.pdf</a></a></a>
:="Note: The OSCCAL word and BG bits must be read prior to erasing the device and restored during the programming operation. OSCCAL is at location 0x3FF and the BG bits are bits 12 and 13 of the configuration word (0x2007)."
:=
:=So, given that Microchip doesn't want these values modified and the programming systems do not support their modification, I cannot see why this fuse exists within the compiler.
:=
:=I emailed CCS a couple of weeks ago asking them about this but, so far, have not heard anything back from them.</font>

There is nothing wrong with offering the option. You can code the other versions if needed, by simply making your own defines. Some programmers _do_ want the bits, and having these 'embedded' in the code, makes it simpler for ICE systems. At the end of the day, don't use the bits if you don't want them...
Even on the OSCCAL, it can be useful to be able to configure this. I have used a system, where we deliberately 'tweaked' the OSCCAL setting, with a seperate program, to push the clock slightly off it's nominal frequency.
Just because an option is there, doesn't mean you have to use it...

Best Wishes
___________________________
This message was ported from CCS's old forum
Original Post ID: 13603

[Warren Massey]

:=There is nothing wrong with offering the option. You can code the other versions if needed, by simply making your own defines. Some programmers _do_ want the bits, and having these 'embedded' in the code, makes it simpler for ICE systems. At the end of the day, don't use the bits if you don't want them...
:=Even on the OSCCAL, it can be useful to be able to configure this. I have used a system, where we deliberately 'tweaked' the OSCCAL setting, with a seperate program, to push the clock slightly off it's nominal frequency.
:=Just because an option is there, doesn't mean you have to use it...

I will concede that all you say is correct. But I still do not think it is a good way to handle this, if nothing else because good documentation of the actual behavior is missing (and perhaps this message thread will fix that).

If someone is going to try to actually change these bits then they do need to know that more bit combinations (than CCS provides for) are available to them if they do, as you suggest, something like this:

#define BANDGAPMEDIUMHIGH 0b10
#define BANDGAPMEDIUMLOW 0b01

They also need to know that the current WARP-13 & Microchip programming software goes out of its way to prevent these bits from being changed by whatever might be in the C code and resultant .HEX file. If they really do feel it is necessary to change these bits, it is going to take some special poking and prodding by them of the programming hardware to make it happen. In fact for the Warp-13 I have it would be easier to make the changes to these bits entirely through the Warp-13 programmer's interface software rather than involing the compiler at all. I also suspect any tweaks to these bits (or the OSCCAL for that matter) would be done on a chip-by-chip basis since you probably do not want to deviate too far from the factory calibration. A one-size-fits-all value specified in the C code is probably not what most calibration tweakers would use (assuming they had more than just one of these PIC chips to program).

I guess I feel that if 99\% of the people who use this PIC are not going to change these bits and do not want these bits changed then, to me at least, it doesn't make sense to include an incomplete implementation for the other 1\% who might want them changed. In the end it turned out to be a mostly harmless option for CCS to have included since its effects are routinely ignored by my programmer. Figuring out how it all actually worked (or didn't, depending on your viewpoint) did burn up time I would have rather spent elsewhere however. Just so I don't feel bad about the time I spent on this I did want to mention this here so others might benefit from what I found.
___________________________
This message was ported from CCS's old forum
Original Post ID: 13615