S08QE32 Won't Exit Math Function

[Designer11]

Hi Everyone,

This is a really odd problem and i don't know where the problem comes from. I'm working on a piece of code that is a little math intense and i don't know whether this is an issue with stack size or the uC does not have enough RAM (2048 bytes). The problem is the program won't exit this function, Update Table (see attached file for more details). Initially, i thought it was the stack size so i increased the stack size to 0x350 in the .prm file  (If i go any higher i will get memory allocation error) and the problem is still there.

I'm totally lost and don't know where to tackle the problem.

Thanks,

V

Original Attachment has been moved to: Calculation.c.zip

[Designer11]

Hi Guys,

It was the COP timeout. I found and fixed the problem. Thanks for your help

BR<

Vu

[Designer11]

Rod and Mac,

Thank you very much your suggestions. I will reexamining my codes and include your recommendations.

Regards,

Vu

[bigmac]

Hello Vu,

With a stack size of over 800 bytes, I would suspect this is not the problem.  The most likely contender is a problematic Delay() function.  It is unusual to have a delay within a function that is purely computational.  You might alter the position of the delay to outside the function, and see whether the problem shifts.  Single stepping through the function should also identify precisely where the problem occurs within the function.

Having said that, I feel that your UpdateTable() function can be significantly simplified as an attempt to reduce code size.

1.  Firstly, I would assume that the global static arrays GC[], GL[] and GF[] are actually meant to be constant look-up tables.  If so, replace 'static' modifier with 'const', so that this data will be programmed to flash memory, rather than initialised to RAM.

2.  Within the UpdateTable() function, the variable x should be a normal local variable, and not static.  Since you are cycling x from 0 to 255 within the function, it would appear unnecessary to retain the last value between function calls.  I presume that this function would not be called very often - perhaps during initialisation only.

3.  The section of code used to calculate the value of i can be considerably simplified.

  for (i = 7; i > 1; i--) {

    if (x > GL[i])  break;

  }

Note that GL[i] may alternatively be calculated using the expression (1 << i).

4.  The following statement would never be executed, and may be omitted from your code -

  else if ((x == GL[i]) && (x > 4))  tmpVal = GC[i+1];

This is because, if x > 4 (and i > 1), x will always exceed the value GL[i].

5.  Consider the following section within your code -

  pdiff = (GC[i+1] - GC[i]);

  ratio = (float)(x - GL[i])/(GL[i+1] - GL[i]);

  tmpVal = (int)(GC[i] + (float)(pdiff * ratio));

For the calculation of ratio, in general GL[i+1] is equal to 2*GL[i], which would give the simplified expression -

(x - GL[i])/GL[i]

The one exception within your code is when i = 7, where the expression becomes (x - 128)/127 instead of (x - 128)/128.  However, I suspect that this may possibly be an error within your look-up table for GL (which would actually need to be a 16-bit table, rather than the current 8-bit one for the expected value 256 for the final value).  There may also be a problem with your cast for the calculation of tmpVal since pdiff and ratio are already floats, and the result of the multiplication should be cast to an int.

6.  With what you are attempting to do, I do not believe anything is to be gained using floating point calculations.  A similar degree of precision for the integer result should occur for a correctly sequenced integer calculation, giving potential reduction of code size.  Assuming that tmpVal is changed to a long integer (to simplify any casting, and for compatibility with Convert2Gray() function parameter) perhaps you could try the following statement -

   tmpVal = ((long)(GC[i+1] - GC[i]) * (x - GL[i]) / GL[i]) + GC[i];

or

   tmpVal = ((long)(GC[i+1] - GC[i]) * (x - (1 << i)) / (1 << i)) + GC[i];

The first expression does not rely on the final (ninth) entry in the GL table, so this could remain an 8-bit table.  For the second expression, the GL table is not used.

Regards,

Mac

[RodBorras · Accepted solution]

Hi,

I do not think your problem is in the code you posted. I created a tiny CodeWarrior project around it...

void main(void) 
{
MCU_Init();
counter=0;
for (;;) 
  {
  UpdateTable();
  counter++;
  }
}

and counter increments correctly. I increased the stack like you did: STACKSIZE 0x350

Things I would check:

  - can the debugger tell you where you get stuck?

  - effect of Delay(10)

  - not sure why you declared x as static

  - are you sure you are not encountering a reset due to memory overflow, COP timeout, division by zero, etc.

  - I would make the variables all global, and track them in real time using the debugger

  - also maybe put in a few breakpoints, and see if the math is correct, or gets corrupted, along the way

  - try the float=64-bit and float=32-bit models

Regards,

Rod.