Phil Cross wrote :

> It turned out to be because my programmer driver checks the
> fuse values against values in a "chipinfo.cid" file, and the values
> it checks them against are those generated by __CONFIG. And
> to repeat myself, this is because  __CONFIG fills unused bits
> with '1's, but CONFIG fills them with '0's.

Ah, yes !
I get it. :-)

And with "unused bits" you mean the bits in the config words
that has no config function (in the processor), not the bits that
aren't specificaly set by the __CONFIG (or CONFIG) directives,
 right ?

Yes, that's makes sense. I had a similar problem where what
was read back from the "unused" bits in i config words did
not match what was in the HEX file. That broke the verify.

In that case (this was while using __CONFIG) each config
word was adjusted with an extra "& ..." to set the unused
bits in the HEX file to match whatever was read back from
the processor. A later version of the software simply
stripped off the unused bits before doing the verify, so they
could be set to anything in the HEX file.

That also explains why I saw no direct need to know
the "values" each CONFIG parameter had, since the
unused bits are clearly documented in the datasheet
anyway.

Sorry for the fuzz... :-)

Best Regards,
Jan-Erik.



-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist