...Strange compiling reaction

[PICman]

Hi...

I'm a newbie here but have been doing programming for a while.. (a lot of PIC assembler and PC C programming and more recently, (2 month ago) PIC C programming using CCS 3.249.)

In PIC C, i started writing smaller programs for the PIC16F648A without any problem and started "growing" the code with more and more functions... Everything worked fine!, but lately, i wrote a much larger program (nearly 3000 lines, including a lot of comments!) for the PIC16F2520. and that's where my problems began...

Like many users, i begin with the heart of the code (a paging encoder) and everything works perfectly, but lately, i simply increased the size of a variable array and the program frezzed!

...And i'm far from the PIC's limits (53% ROM, 40% RAM and 17 stack levels (on 31 available)

Can someone explain me what happened? and how i could solve the problem?

My code follows the "standard" code format: First the prepocessor (including defines), instructions, followed by global variables (84 int8's, 137 int32, 8 char's, 10 boolean (int1), and 39 function declarations (all VOID's), no floats.) many subroutines and, at the end, the main() program.

I'm sure there's something that went wong with the compiler, because i simply increased the size of a variable array (in a code that uses 50% of the PIC's RAM. (I also wrote code for subroutines that ARE NOT CALLED ON STARTUP and got the same freezing problem!

Thanks for the help!

[PCM programmer]

See these threads:
http://www.ccsinfo.com/forum/viewtopic.php?t=30368
http://www.ccsinfo.com/forum/viewtopic.php?t=23991

[PICman]

Thanks PCM...

But that does not answer all my questions...

There's a lot of "trial and error" in the solutions shown... but no real answer to the abnormal behavior of the code once in hardware.

As i read some topics on compiling errors, it * seems * (unless i am completely wrong,) that the major (and probably the most logical) reason of code malfunctin remains in bad memory bank control. (outside of that, i've studied the midrange ( 14 bit PIC16's) line in the past, i don't see any cause of such behavior.)

I've examined the assembler CALL and GOTO instructions in the 18F2520/4520 and they have access anywhere within the whole 1Mbyte program memory (two word instruction), however, the RAM space is divided into SIXTEEN banks of 256 bytes each.... Is it possible that the main cause would be in wrong RAM access/address? and if so, is there a clear and reliable way to, at the C code program's beginning (or anywhere else!!), to tell the compiler, in which bank we want which variables to go, so we could prevent bad bank control?

I began with assembler, but as i work in larger and larger C code (my project is far from being completely written) i do not want to go back in complex assembler analysis just to try to see where the compiling error is... I'd like MUCH MORE to write C code correctly, so i could compile and KNOW that if something goes wrong in H/W, this is because of MY code error, not compiling errors!

Also, i actually work with the PIC18F2520... Is there another PIC controller that would be less prone to such compiling errors?

Thanks for your attention.

Normand

[PCM programmer]

Did you do every single thing in those links ?
1. NOLVP
2. Pull-up on MCLR
3. 100 nF capacitors on all Vdd pins
And everything else.



If so, put in some printf statements to track the program execution and
to show the place where the program freezes.

[ckielstra]

Version 3.249 is a stable version, of course it has some bugs but not major ones of the severity you are referring to that I know of. The optimization level related bank switching bug from one of the above mentioned threads was fixed a long time before v3.249.

In my experience a PIC18 has less bank switching problems than the PIC16 processors and arrays are allowed to be larger than 256 bytes.

There have been known several problems for the newer chips with large memories but your chip has only 32kbyte ROM so this is not an issue.

All considering I wouldn't expect the compiler to be the error source unless I had ruled out some other options:
- Check the hardware errata sheets for the silicon revision of your chip. At a quick glance I don't see any obvious memory related errata, but I'm surprised by the more than 40 known errata for the A1 stepping. If you do happen to have this chip stepping I would try replacing it by a B3 or B4 stepping.
- Are you testing with a (hardware) debugger? Does the problem still occur without the debugger? If the problem disappears you can try with another software version, for example the ICD2 firmware is integrated in MPLAB and for me MPLAB version 7.41 has proven to be very stable.
- A very common problem causing your type of errors is a memory corruption. Somewhere in your program you are writing at a RAM location that is reserved for another variable. This will not directly cause problems but only at a later time when the overwritten variable is being accessed. These kind of errors are hard to find because the program hangs at a moment in time not related to the bug causing the memory corruption. Common causes are buffer overflows, writing outside array bounds and bad pointer arithmetic. The best way to fix this kind of errors is to have a 'fresh eye' have a look at your code.

As a general comment: A program with more than 200 global variables doesn't sound like an optimal architecture. For easier program maintenance it is best to keep the variables as close as possible to the code using them, i.e. place the variables inside the function on the stack. A global variable can be used everywhere in your program , that means that if you want to see which functions are using the variable you will have to scan the whole program. Local variables are much easier to track and hence less error prone. As a positive side effect the compiler is smart and can re-use the memory for variables that are out of scope.