Alan B. Pearce wrote:
> I suspect that this is to do with the way the memory map wraps around
> when the program counter goes over the top of the memory map. I suspect
> that the upper bits of memory address are not actually there, and could
> be any mix of ones and zeros, provided the lower 9 bits are 1FF. Hence
> by setting the config to FFF they are also allowing for any future 10F
> series chips with larger memory :))))

It may be even simpler than that.  The 10Fs wake up at the config address
when programming, then wrap to address 0 on the next increment.  A
programmer just writes the config word immediately after a reset.  The only
issue is that it might get confused about the data for the config word
depending on where it was expected in the HEX file and where it ended up.

My programmers look for the config data at a specific address.  If any data
is found at an unexpected address it complains.  This usually means you are
trying to program one PIC from a HEX file meant for another, and is why I
made it a hard error.  I suppose other programmers might silently ignore the
config word from the incorrect address and default to FFFh since the value
wasn't specified.  That's why I asked Ken if he verified that any 0 bits in
the config word were actually in effect.

Some programmers might mask addresses from the HEX file with the valid
address bits for the part being programmed, in which case the MPLAB bug
would go unnoticed.  I guess being dumb is occasionally an advantage.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com
_______________________________________________
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist