| View previous topic :: View next topic |
| Author |
Message |
arunkish
Joined: 23 Dec 2008
Posts: 83
|
| 16F876A Crashes With Variable |
 Posted: Tue Aug 26, 2014 10:23 pm |
 |
|
Hello All,
I am facing a peculiar problem that I would like to share with you for which I am unable to find the solution.
My Compiler version is 3.222 and I am using 16F876A clocked at 4 Mhz with the following declarations.
| Code: |
#device *=16
#fuses XT,WDT,NOPUT,NOBROWNOUT,NOLVP,NOPROTECT
#use delay(clock=4000000)
#use i2c(SLAVE, SDA=PIN_C4, SCL=PIN_C3,FORCE_HW,FAST)
|
Furthermore for your understand I use
1. Watchdog timer
2. I2C (As slave)
3. External Interrupt
External Interrupt will occur very often as well as the I2c.
Memory usage: ROM=22% RAM=44% - 51%
I dont have any problems until this point. But when I simply add variables like
| Code: |
byte test[35];
byte test1[35];
byte test2[35];
|
Memory usage goes to : ROM=25% RAM=73% - 79% and what actually happens is my controller starts to misbehave like.....
the external interrupts does not fire as it was before and at some point the i2c even stops responding.
I made some modification to the code to find what was actually happening and learned that the SSPADD itself gets changed from the address that was actually defined and that makes the i2c to stop responding to the master.
It took lot of time for me to find out it was all because of the variable that was added.
If I comment out the variable, compile it and run the program everything seems to work normally.
Has anyone come across such problem? I know this is very uncommon. But it is happening. I suspected the controller and I replaced with a new one, but it has the same result.
Please advise.
Thanks a lot. |
|
 |
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Wed Aug 27, 2014 1:41 pm |
|
|
Read this thread about how to check for a compiler bug, where the
compiler is re-using RAM locations for variables in your interrupt routine
for variables in other routines.
http://www.ccsinfo.com/forum/viewtopic.php?t=18296
The compiler should not be doing this. But some early versions did have
this bug. |
|
|
ezflyr
Joined: 25 Oct 2010
Posts: 1019
Location: Tewksbury, MA
|
|
| Posted: Wed Aug 27, 2014 3:08 pm |
|
|
Hi,
Another thing, your compiler version is really ancient. If the problem you have observed is a compiler bug, it's likely already been fixed in a later version.
At my company, we won't even talk to customers about a problem if they are running such an old version of code. It's a waste of everybody's time to revisit old problems.....
I understand that not everyone has the resources to keep their compiler always up-to-date, but come on, yours has to be at least 5 or 6 years old!
John |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Wed Aug 27, 2014 3:12 pm |
|
|
My records show that vs. 3.222 came out in mid-March 2005.
If he's a registered owner, and if he contacted CCS and told them about
the bug, it's possible they would give him a free upgrade to vs. 3.249.
That's the last (and stable) version of 3.xxx. |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
