RAM at 0x7F not defined on PIC16XXX chips

picport · Joined: 01 Jun 2007 Posts: 7

Using the Chipedit.exe to see compiler definitions for PIC16FXXX family chips I see that on many models the RAM memory at 0x7F is not defined. RAM byte at 0x7F is not zeroed nor allocated for variables, so 1 byte of RAM is lost.

As an example PIC16F690 definitions indicate RAM at 0x7F as not used by the C-compiler, but (similar) PIC16F689 indeed defines memory at 0x7F as useable. Why is this? In both chips the RAM location at 0x7F exists. Is it just an error in the chip definition files?

Another related issue. On some chips the "C Scratch RAM" is allocated to 0x20 and on others to 0x77. Why this difference? Isn't the 0x77 location better since it can be accessed on all memory banks? Would the latest verson 4.040 use this bank visibility? Any comments?

PCM programmer · Joined: 06 Sep 2003 Posts: 21708

picport · Joined: 01 Jun 2007 Posts: 7

My current version is the latest one, that is 4.040. Downloaded this morning and found some earlier buggs fixed, but not the chip definitions. Any insight on 0x7F or C Scratch RAM?

PCM programmer · Joined: 06 Sep 2003 Posts: 21708

I don't have the CCS IDE, so I can't directly look at the Device data.
(You don't get the Device Editor with the command line compilers).
If you think there's a bug in the device data files, you should report it
to CCS tech support. They'll upgrade you to the next version when
they fix it (if your support has run out).

picport · Joined: 01 Jun 2007 Posts: 7

Yes, I suppose I should email CCS tech support also. It would be an excellent idea if they give you a free update for each bug you report. I find them continuously...

PCM programmer · Joined: 06 Sep 2003 Posts: 21708

I think it is their policy to let you upgrade to the version that has the
bug-fix, if you report it and if your maintenance has run out. If they
don't do it automatically, then request it.