40X1 memory size?

[saunj]

I am using a 40X1 bought from SparkFun Electronics, their part# COM-08354.
It is labeled PIC16F-887-I/P. According to REV-ED this is the correct part No. for a 40X1
But attached is an excerpt from the Microchip datasheet.
My problem is that when I exceed program size of 2048 bytes, it goes haywire.
I can make it run by #rem .. #endrem enough code that it goes below 2048 (i am now using 2040 and foregoing some capability)
Now Microchip specifies a flash size of 8192 for an 887, and the editor (5.1.5) allows 4196 bytes.
Microchip does have an 882 with only 2048 bytes, but its EEPROM size is 128, and I am
exceeding that in my program without any problem.
What have I got, and what should I be getting?

 

[hippy]

If it's labelled 16F887 amd you can download to the chip as a 40X1 then it is a 40X1.

No idea why you're having a problem but I recommend saving a copy of the source as you have it now in case Rev-Ed need to investigate further - there's nothing worse than trying to investigate a potential problem when that problem cannot be re-created.

Instead of cutting back your code, try the opposite approach, increasing it. After your last return, add a number of SERTXD("ABC...XYZ") lines. That will soon eat up memory and will not cause problems as they shouldn't be executed.

You can try to determine where in your code it crosses the 2048 byte boundary, then add a large block of those SERIN's after the last RETURN before then; you're splitting the code so half's on one side, the rest on the other, and the middle is just filler.

As soon as you get it working ( which hopefully you will ) with a program over 2048 byes, save a copy of that as well. That too will be useful in investigations. Do let us know how you get on.

 

[saunj]

If it's labelled 16F887 amd you can download to the chip as a 40X1 then it is a 40X1.

No idea why you're having a problem but I recommend saving a copy of the source as you have it now in case Rev-Ed need to investigate further - there's nothing worse than trying to investigate a potential problem when that problem cannot be re-created.

Instead of cutting back your code, try the opposite approach, increasing it. After your last return, add a number of SERTXD("ABC...XYZ") lines. That will soon eat up memory and will not cause problems as they shouldn't be executed.

You can try to determine where in your code it crosses the 2048 byte boundary, then add a large block of those SERIN's after the last RETURN before then; you're splitting the code so half's on one side, the rest on the other, and the middle is just filler.

As soon as you get it working ( which hopefully you will ) with a program over 2048 byes, save a copy of that as well. That too will be useful in investigations. Do let us know how you get on.

I will follow up your suggestion when I have a chance. I don't have another 40X1, and the present project is now completed - I found some fat in the code to get it down to < 2048.
(I reduced the number of READs).
The last part of the code was the interrupt routine - this is required.
I am nervous about this test - not only did the device not work, but it wouldn't load - not even with reset on. I tried many times.
It has a LED telltale on the interrupt routine, which is tied to a 1 HZ osc. It was out. I thought the bootstrap was trashed. As I sat and looked at it wondering what to do next, the LED started flashing after about a minute, and then it loaded a reduced program and worked again. I did not expect a code problem, since it was alleviated by commenting out different parts of the code, even code which was not executing.
You can see the code as now in use on my web site. (DAU project)