CCS compiler if-statement problem

[zilog]

Series resistor on osc out to xtal did not help.
470 ohm seem "right", at about 10k it fail to start.
The waveform got nicer, but the program still fail similarly.

What is more frightening is that we found other places in the program where if-statements fail sometimes. Iĺl see if i can get a REAL-ICE here ASAP to trace this mystery!

[kevcon]

You might want to look at the assembly to see if the compiler is doing something strange.

This was compiled with 4.038 for a pic18F65J10 part

Look at where cc gets set to 0x0007, what are the extra mov's for?

[Mogge]

kevcon, what optimization level did you use?

Here is an example of unnecessary bankswitching:
http://www.ccsinfo.com/forum/viewtopic.php?p=84772#84772

[kevcon]

level 9

I tried level 10, no effect

Level 11 didn't have any effect on it other than adding a subroutine to init the FSR0 regs

[Mogge]

To get back to our problemthe thread is really about:
We experience if-statements giong wrong, and functions returning impossible values, but they are OK inside the function.
We are anxiously waiong for the REAL-ICE-debugger to arrive.

Meanwhile below is a sum-up of themost important things we have done.


_____Technical details for anyone interested____

We have eliminated any cirquit layout, EMC, and clocking errors, and
studied the compiler generated assembler.

The assembler this compiler (CCS) generates is a lot less efficient than
expected, and it sometimes do some things in a really clumsy way, but we have yet not found anything plain wrong. We have tried different versions of the compiler, and different optimisation levels.

As we have a UART we use to send debug to a test terminal, and by that we have spotted that functions evaluate correctly, but the calling routine sometimes, very rarely get a completely different value.  We have by variable sampling before and after code lines also spotted if-statements evaluate wrong. Even with all interrupts disabled, and all hardware environment such as supply and clock checked very thoroughly. This is really hair pulling!

We also have tried moving the code to to other adress: same problem.
And it happens in more than one place in the code.

What is currently even more strange is that the problem seem to went away
after a recent work on a completely unrelated part of the program.   This is
NOT good as we will probably have the problem back at any random time we
implement more functiojnality.  And we need to have the problem to cath it.
So we keep hunting.

Yes we have read the erratas and datasheet may times...


__On the hardware side we have tried:

POWER SUPPLY
o Although we could not scope any supply voltage noise, we improved the
already good decoupling with more capacitors of different technologies, and
damping R-C network.
o We tried medium, max and min operating voltage.

OSCILLATOR
We learned from forum that some early chips in this family could have problem with the PLL oscillator if not using series resistor to drive the crystal, so we also experimentet with this.

LAYOUT
Careful layout of power and oscillator, etc - we are no beginners...

OTHER CHIP INDIVIDUAL
o Another microcontroller of same type is soldered on top of the "old". They have all pins in parallel except reset, and crystal cirquit. So by a switch
we can at any time select which to run by holding the other in reset.

SHIELDING
o all sorts of shielding, we already had power plane under the uC, then also
GND connected copper taped on top of processor and bottom of board.

PHYSICAL MOVE
o Moved it from DriveLPI; elongated connections to DriveLPI and put the board
30cm away in a metal box, and all cable through noise suppression toriods

REDUCE SWITCING POWER NEARBY
o  We avoid using the the brake switch in this board
o  We supply power through battery instead of DriveLPI
o  We disconnected motor from DriveLPI

o   MICROSCOPE
We borrowed a good stereo microscope to study all solder joints

o  HF oscilloscope
Studied oscillator waveform
Supply noise

o  Digital sampling oscilloscope
...is another tool used

And lots of tests...

NONE of the hardware changes have had any notable effect!
Now we focus on compiler, change processor, and keep looking over our own code although we ruled it out for th basic problem, we improve parts slowly.

The other microcomputer in this project, the panel and measurement unit in the handle, is and have been working like a charm all time, no problem whatsoever.  We there used the same compiler but a smaller sister to the main microcontroller.

[kevcon]

Have you looked at the .sym file, there have been cases where the compiler is re-using memory locations that shouldn’t be re-used?

I had a similar problem with if statements like this not working correctly.

[ckielstra]

[Mogge]

ckielstra, thank you.
We will send the file tomorrow. (the one from the program verison that have problems in that part... )

We now recieved the REAL-ICE debugger, which we will learn and hope to catch something interesting with.

Microchip support have suggested we try their C18 compiler, but I think there is a lot of work to port the code. We have not used many pre-built functions, but some.

Anybody knows more about porting?

[Darren Rook]

Have you sent this to CCS tech support?

Which if fails?
_________________
I came, I saw, I compiled.

[Darren Rook]

If you want official CCS support on this matter you need to e-mail me all your files (sources, list files, sym file, etc).
_________________
I came, I saw, I compiled.

[zilog]

[Mogge]

It does seem pretty clear to us now, that there is some bug in the interrupt system in this chip :(

http://forum.microchip.com/tm.aspx?m=280401&mpage=3