Function returns illogical value at runtime, but returns correct value during debug.

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Function returns illogical value at runtime, but returns correct value during debug.

Jump to solution
642 Views
belskyc
Contributor III

Hello,

 

I'm running an application in the HCS08DZ60A microprocessor written in C.  I have a function that crunches a 5th-order polynomial and returns the result.  All variable types are 'float'.  Here are the bug symptoms:

 

1) The poly function returns an incorrect value when executing real-time in the platform.  However, if I step through the function using CodeWarrior Real-Time Debugger through the BDM port, the function returns the correct value.

 

2) The format of the function is:  float F_polyf(unsigned char n, float *Coef, float x) where x is the input value, *Coef is a pointer to an array of the coefficients, and n is the number of coefficients.

 

3) I've been using this same poly function for 5 years in both the HC08AZ60A and HCS08DZ60A and it has always worked.  Now this time around, my application simply involved a 'minor' update to a seemingly unrelated area and after recompile the bug has appeared. 

 

4) The bug only appears after a hardware power-up / reset.  If I exercise the product a bit after power-up, the bug clears up.

 

5) I've verified my 'logic' with the CodeWarrior Real-Time Debugger. When stepping through the function with the debugger, the math comes out correctly.  Thus, my issue seems related to something else.

 

6) I call this function in four different locations in my program, but the 'bug' only appears at one of the locations.  The other three locations always calculate correctly. 

 

Has anyone seen any symptoms like these?  I've run out of ideas, and I'm just looking for somewhere to go. 

 

Thanks much,

~Bizkits

Labels (1)
0 Kudos
1 Solution
334 Views
bigmac
Specialist III

Hello,

 

This could be indicative of a stack overflow problem - the changes that you did may have increased the stack size requirement, and global or static variables could be over-written.  Does the function make use of any of these?

 

The fact that the problem only occurs at one of the four locations where the function is called, may be determined by the stack usage prior to the call.  Also perhaps all interrupts do not occur when you are single stepping - each interrypt will require additional stack on top of that required for the floating point operations.  I assume that you are not attempting to use nested interrupts?

 

Is the array of coefficients meant to be constant data, to be located in flash?  Perhaps the data actually resides in RAM.  The project map file should reveal its location.

 

Regards,

Mac

View solution in original post

0 Kudos
1 Reply
335 Views
bigmac
Specialist III

Hello,

 

This could be indicative of a stack overflow problem - the changes that you did may have increased the stack size requirement, and global or static variables could be over-written.  Does the function make use of any of these?

 

The fact that the problem only occurs at one of the four locations where the function is called, may be determined by the stack usage prior to the call.  Also perhaps all interrupts do not occur when you are single stepping - each interrypt will require additional stack on top of that required for the floating point operations.  I assume that you are not attempting to use nested interrupts?

 

Is the array of coefficients meant to be constant data, to be located in flash?  Perhaps the data actually resides in RAM.  The project map file should reveal its location.

 

Regards,

Mac

0 Kudos