18F452 hangs/behaves badly with addition of code,

[burnsy]

I'm know this has been listed on this forum previously, but I have a slightly different question after my explanation. The code is too long to post.

I am running a 18F452 at 4Mhz, no ICD. Code is up around 11,500 bytes and running fine. If I do this:

#include<ecomms.c>
#include<euart.c>

...but do not calll any of the functions in those files, it affects the way the processor operates. I loose my RX interrupt (which stops comms from my internal uart). I can also generate a problem by adding simple code to another area of my program.

eg
x = 1;
x++;

I had this problem using V3.156. I upgraded to 3.209 and the problem dissappeared (the code size with 2.209 was less, about 10,000bytes). After the program size expanded beyond 11,500 bytes again, I have the same problem. I have just upgraded to 3.225 and the problem is not fixed still. The size of the program may just be a coincedence.

I have read about the 18F452 silicon issues, and workarounds Does this also apply to the 18F458? and other in the 18F series?
_________________
This is the last code change until its ready....

[PCM programmer]

1. Do you guarantee that you don't call any functions in those files ?
Have you looked at the .LST file to see that you don't ?

2. Do you have any #define statements in those files that would
affect the rest of your code ?

3. Do you have any #fuses statements in there ?

4. Do you guarantee that you are reading the versions of ecomms.c
and euart.c that you think you are ? Could there be multiple
copies of these files in various directories on your system, and
each one is a little different from the other, and you're picking
up one that's full of bugs ?


If you feel that the problem is truly due to adding those files,
then trouble-shoot it by commenting out the code within those
files with the /* */ style of comments. Initially, comment
out all of the code in those files. Doing so should eliminate the
problem. If not, check if you're including the files from the proper
directory. If commenting out everything does fix the problem,
then un-comment the code in those files, a few blocks at a time.
Find out what lines are causing the problem.

[Charlie U]

... and how old are the actual devices that you are using?? Remember, that the '452 had a nasty little problem if a call went across the 4000h boundary back in the old days, a couple of years ago.

If your devices are older, you will need to envoke the errata fix in the compiler via the device editor.

[burnsy]

Thanks for your help guys. I managed to fix the problem. The functions in the files I was adding were not being called by me, BUT on eof them must have been called by the compiler. here it is.

#int_rtcc
void
timer_int(void)
{
/* reset timer to trigger int next pulse */

}

It is a left over function from months ago that now does nothing. At least in my old 16F877 compiler, it did nothing. When I comment it out, all the problems go away. I don't enable the RTCC interrupt anywhere btw.


RE my 18F452 chips, one of them is old. Thanks for the tip RE implementing Errata workarounds. I'll try and figure out how to enable this.


Thanks again for your help. Been a cruel start to a new proccessor, but finally making progress.
_________________
This is the last code change until its ready....