CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to support@ccsinfo.com

CCS compiler if-statement problem
Goto page Previous  1, 2
 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
zilog
Guest







PostPosted: Mon Aug 13, 2007 3:10 am     Reply with quote

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



Joined: 21 Feb 2007
Posts: 142
Location: Michigan, USA

View user's profile Send private message

PostPosted: Mon Aug 13, 2007 8:31 am     Reply with quote

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?

Code:

struct mystruct {
   unsigned int8 aa;
   unsigned int16 bb;
   unsigned int32 cc;
};

struct mystruct data, *data_ptr;

void main( void )
{
   unsigned int32 myvar = 0;

   data_ptr = &data;

   data_ptr -> cc = 0x0007;

   data_ptr -> cc = myvar;
}


Code:

41:                   unsigned int32 myvar = 0;
  001C    6A0E     CLRF 0xe, ACCESS
  001E    6A0F     CLRF 0xf, ACCESS
  0020    6A10     CLRF 0x10, ACCESS
  0022    6A11     CLRF 0x11, ACCESS
42:               
43:                   data_ptr = &data;
  0024    6A0D     CLRF 0xd, ACCESS
  0026    0E05     MOVLW 0x5
  0028    6E0C     MOVWF 0xc, ACCESS
44:               
45:                   data_ptr -> cc = 0x0007;
  002A    0E03     MOVLW 0x3
  002C    240C     ADDWF 0xc, W, ACCESS
  002E    6EE9     MOVWF 0xfe9, ACCESS
  0030    0E00     MOVLW 0
  0032    200D     ADDWFC 0xd, W, ACCESS
  0034    6EEA     MOVWF 0xfea, ACCESS
  0036    52EE     MOVF 0xfee, F, ACCESS   <<<<<<<<<<<<<<<<
  0038    52EE     MOVF 0xfee, F, ACCESS   <<<<<<<<<<<<<<<<
  003A    6AEC     CLRF 0xfec, ACCESS
  003C    52ED     MOVF 0xfed, F, ACCESS   <<<<<<<<<<<<<<<<
  003E    6AEF     CLRF 0xfef, ACCESS
  0040    52ED     MOVF 0xfed, F, ACCESS   <<<<<<<<<<<<<<<<
  0042    6AEF     CLRF 0xfef, ACCESS
  0044    52ED     MOVF 0xfed, F, ACCESS   <<<<<<<<<<<<<<<<
  0046    0E07     MOVLW 0x7
  0048    6EEF     MOVWF 0xfef, ACCESS
46:               
47:                   data_ptr -> cc = myvar;
  004A    0E03     MOVLW 0x3
  004C    240C     ADDWF 0xc, W, ACCESS
  004E    6EE9     MOVWF 0xfe9, ACCESS
  0050    0E00     MOVLW 0
  0052    200D     ADDWFC 0xd, W, ACCESS
  0054    6EEA     MOVWF 0xfea, ACCESS
  0056    C00E     MOVFF 0xe, 0xfef
  005A    C00F     MOVFF 0xf, 0xfec
  005E    C010     MOVFF 0x10, 0xfec
  0062    C011     MOVFF 0x11, 0xfec
Mogge



Joined: 13 Aug 2007
Posts: 14
Location: Sweden

View user's profile Send private message

PostPosted: Mon Aug 13, 2007 3:58 pm     Reply with quote

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



Joined: 21 Feb 2007
Posts: 142
Location: Michigan, USA

View user's profile Send private message

PostPosted: Tue Aug 14, 2007 6:51 am     Reply with quote

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



Joined: 13 Aug 2007
Posts: 14
Location: Sweden

View user's profile Send private message

PostPosted: Wed Aug 15, 2007 7:03 am     Reply with quote

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



Joined: 21 Feb 2007
Posts: 142
Location: Michigan, USA

View user's profile Send private message

PostPosted: Wed Aug 15, 2007 7:33 am     Reply with quote

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.

Code:

if ( test )
    do something....


And fixed it by adding braces

Code:

if ( test ) {
    do something....
}


But from your earlier post I see you tried this.
ckielstra



Joined: 18 Mar 2004
Posts: 3680
Location: The Netherlands

View user's profile Send private message

PostPosted: Wed Aug 15, 2007 3:46 pm     Reply with quote

Quote:
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 a very strong sign indicating memory corruption. Memory corruption can be caused by hardware problems (chip errata, power supply glitches, etc.) but in 99% of the cases are caused by software errors like buffer overflows, uninitialized pointers, compiler errors, etc.

It might be a compiler bank switching problem. Can you use the email function of this forum to send me the list file for the ChainFUCommunicationRoutine() ?
Mogge



Joined: 13 Aug 2007
Posts: 14
Location: Sweden

View user's profile Send private message

PostPosted: Thu Aug 16, 2007 11:13 am     Reply with quote

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



Joined: 06 Sep 2003
Posts: 287
Location: Milwaukee, WI

View user's profile Send private message Send e-mail

PostPosted: Fri Aug 17, 2007 12:23 pm     Reply with quote

Have you sent this to CCS tech support?

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



Joined: 06 Sep 2003
Posts: 287
Location: Milwaukee, WI

View user's profile Send private message Send e-mail

PostPosted: Mon Aug 20, 2007 7:55 am     Reply with quote

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



Joined: 17 Aug 2007
Posts: 19

View user's profile Send private message

PostPosted: Mon Aug 20, 2007 10:29 am     Reply with quote

Darren Rook wrote:
If you want official CCS support on this matter you need to e-mail me all your files (sources, list files, sym file, etc).


Hi Darren,
An email with the latest state of the project is on its way.

Best regards
Daniel Nilsson
Mogge



Joined: 13 Aug 2007
Posts: 14
Location: Sweden

View user's profile Send private message

PostPosted: Tue Sep 11, 2007 10:09 am     Reply with quote

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
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Goto page Previous  1, 2
Page 2 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group