CCS compiler if-statement problem

[zilog]

I am having troubles with the last else if-statement which sometimes happens even when the condition is false!

The log from running this says:

ERROR, Chain_FUCommCheckResultTime occured in an impossible state
state->mainGroup: 2, state->secondGroup: 2, Chain_FULastCodeQueried: 51, CheckCommResultCache: 0

The code is attached below (snipped from its original context), anyone have any hints? I am having similar problems with other if-statements as well :/

[zilog]

To clarify my previous post, what I mean is the

" } else if (CheckCommResultCache) { " statement

[PCM programmer]

[Guest]

[Ttelmah]

Comment one. Try disabling the interrupts, before your test. You obviously have a timer interrupt running, that is changing some of these values, is it possible that this is clearing or modifying the value between the test, and the printf?.
Second comment, try explicit 'bracketting' and value testing. So something like:

[zilog]

I have tried adding {} to everything, also testing with statements like "if (a != 0)" etc, but the same problem remains.

I have also spottet another problem - function calls randomly return erroneous values (more than one function). I have debugged that inside the functions the values are as they should, but when the callee gets the return value, it sometimes is all scrambled - like if something else writes over the memory location where the return value is placed.

What should I do? The entire project is at stake if I cant get this problem resolved shortly.

[kevcon]

what version compiler are you using?

[PCM programmer]

Post your #fuses statement(s).

[zilog]

I have tested to shut down interrupts during all this block of if-statements and function calls. Still borks.

Maybe the if statement is not the problem, but there *are* occational (weird) error in function value return.

PCWH 4.049, also tried going back to 4.039

[PCM programmer]

Try running it without the PLL, and run it at 10 MHz.

[Ttelmah]

If it still fails without the PLL (on some chips, there are odd behaviours if the crystal is slightly overdriven, when the PLL is used), then I'd be suspicious of a memory 'leak'. Perhaps, using pointers somewhere, and talking beyond the size of the addressed value. The chip has no memory controller, and no protection at all for this. Have you checked on the list file, the stack size?.

Best Wishes

[zilog]

Tried without the PLL, also tried with 8MHz xtal + PLL, even tried varying voltage up and down, still we find the same error.

[zilog]

Ttelmah, could you elaborate on when xtal is overdriven, in conjunction with the PLL?

We have changed the xtal to another type, no change, but maybe Iĺl try a series resistor to lower the drive level.

We have checked what we could think of could overwrite anytning.

It may be noted also, that it sometimes reboots, (but much more seldom than the other problems occours) but what causes it we have not tracked down.

[Ttelmah]

This varies between PICs, and especially between chip batches. On the earliest PICs with the PLL, it was a common problem. Basically, oscillators that ran fine without the PLL, when the PLL was enabled, sometimes gave very 'odd' behaviours, with the chip giving random errors. Adding a series resistor, solved the behaviour, and was a common fix.
However if your code shows the same problem, with the PLL disabled, then this is not your problem. I still would put my money on a memory 'leak'. My guess is that a function somewhere is overwriting part of the compiler's scratch memory.

Best Wishes

[zilog]

Thank you Ttelmah

Unfortunately without the PLL the program is running too slow to execute normally, as during normal execution it need to continously communicate with two other processors. So the test result from running without PLL is unusable, sorry i was wrong to state that before.

We will innvestigate both adding a resistor, and check memory usage.

But shoulnt a decent compiler check memory usage itself?

How can we tell where the compiler scatch memory is located?