Debug variables wrong

[Jérémy Moffa]

Posted on January 24, 2017 at 01:21

Hello,

I'm facing a very embarrasing problem with variables in ST visual develop.

When I add a breakpoint just before a function call and I hover the parameter being sent with my mouse I can see it. But when I step into the function, the parameter became wrong : it has totally random values.

Also when the mcu has to do calculations, it can do it wrong.

This kind of calculation can be wrong :

result = (uint16_t)((sqrt((float)sum / measures_nb) / 1023.0 * 3.3 / 0.1) * 1000);

If I do this with another compiler, the result is correct.

I disabled all optimisations except +split because without this I get a .text overflow

If someone can help, I appreciate.

Thanks

[Tesla DeLorean]

Posted on January 24, 2017 at 02:04

Isn't sqrt() using doubles?  double sqrt(double x)

Do you want sqrtf() ?

Is it holding values/variables in registers and not memory? Is the stack frame moving?

You should review the assembler code related with the function. Ideally a code/assembler listing type file if the compiler generates such.

Not sure there is much STM8 support to be had here.

// This might have better casting

result = (uint16_t)((sqrt((double)sum / (double)measures_nb) / 1023.0 * 3.3 / 0.1) * 1000.0);

You could also save the values as a double and check that first. Consider also checking/debugging on a PC compiler with test values.

[Jérémy Moffa]

Posted on January 24, 2017 at 02:50

Isn't sqrt() using doubles?  double sqrt(double x) 

Yes it is. What wrong could happen by using a float instead of a double ?

Is it holding values/variables in registers and not memory? Is the stack frame moving?

I will check this tomorrow but can you explain a little bit more what you want to know and what values you are talking about because i'm not an expert with assembler, register,  ...

Thanks

[Tesla DeLorean]

Posted on January 24, 2017 at 05:49

The choice of float/double depends a lot on the range of numbers and precision, and the speed at which you want to do the computations.

If you can stay in one form and not convert back-and-forth, that would save a lot of time. As will keeping the constants in one form, and having the compiler fold up the math.

result = (uint16_t)((sqrtf((float)sum / (float)measures_nb) / 1023.0f * 3.3f / 0.1f) * 1000.0f);

Sorry don't have any specific experience with the STM8 and its compiler/debugger. Visibility of variables may be limited if they are held in registers rather than memory. You'll have to read the code to gauge what it is doing

[luca239955_stm1_st]

Posted on January 24, 2017 at 11:27

Hello,

in the Cosmic stm8 compiler doubles are silently converted to float, since double is not implemented for this micro as it would use too many resources.

For the values of variables not showing as you would expect, the reason is probably as Clive says: in some points variables might be held in registers or stack and the debug info is not always able to follow this, generating some confusion when you debug. Usually declaring the variables as volatile is enough to make them display correctly, but this is a dirty workaround, and you should remove the keyword when you have checked your values.

As for the result of the calculation being wrong, it has probably something to do with the precison of the float: just to give you an idea, the float type has a precision of around 7 useful digits, therefore if your calculation (or some of its interlmediate results) requires more the calculation might go wrong: if you do the same calculation with bigger types (on a PC or on a bigger micro where the double type is actually implemented) you will see the difference.

Regards,

Luca

[Philipp Krause]

Posted on January 24, 2017 at 12:30

in the Cosmic stm8 compiler doubles are silently converted to float, since double is not implemented for this micro as it would use too many resources.

Currently all compilers (SDCC, IAR, Cosmic, Raisonance) for the STM8 will use float instead of double. Some silently (at least Cosmic), others with a warning (at least SDCC).

Philipp