code optimation and sprintf problems

[matute]

Hi to everyone,

I'm working with Kinetis K05Z32 on Codewarrior 10.6 and I have some problems.

First, the code is so longer that it is not enter in its flash, so I thought in optimize the code (without debug). But, to my surprise, the behavior is not the same as the code without optimizations.

Second, when I was trying without optimizations, the behavior of "sprintf" function was very strange sometimes. It seems (in fact happened) sprintf changes other variables values, sometimes. I had big buffers, so I believe that it was a problem of heap or stack because the behavior change when I modified some lenght of these buffers.

So, I'm a little scared because I believed that optimizing code I will solve the size flash problem...

Thanks to yours comments

Matias

[matute · Accepted solution]

Mark and Norm, well...

As I've never had to use optimizations I've never used "volatile" declaration in shared global variables and structs. This, of course, is solve the behavior problems when I need optimize the code.

Thanks to your comments, I learnt something important new.

Matias

[mjbcswitzerland]

Hello

The GCC sprintf() does seem to require heap and so can be a problem for devices with small RAM footprints. You write K05 but I think you mean KL05 (?)

Are you sure you need sprintf()?

In the uTasker project functions like

extern CHAR *fnBufferHex(unsigned long ulValue, unsigned char uLen, CHAR *pBuf); // take a value and convert it to a string in a buffer

extern CHAR *fnBufferDec(signed long slNumberToConvert, unsigned char ucStyle, CHAR *ptrBuf); // take a value and convert it to a string in a buffer

allow most output formatting with very low overhead.

Regards

Mark

Kinetis: µTasker Kinetis support

KL05: µTasker FRDM-KL05Z support

For the complete "out-of-the-box" Kinetis experience and faster time to market

[matute]

Hi Mark, Thank you for your reply.

Yes, I meant KL05... I'm using a lot of times sprintf function, I'm interfacing this MCU with a SIM900 module, and it seem that the flash and RAM aren't sufficient. But my doubt is in optimization, why does this change of code behavior?

Matias

[ndavies]

Do you have global variables that are shared between ISR and non ISR routines? Do You have Global variables that are shared between 2 tasks in a multitasking environment? Did you define these shared global variables as volatile?

Are you using C++? do you have classes that are shared between ISR and non ISR functions?

The most common failure when optimizing is not using the volatile keyword.

The optimizer makes the assumption it has complete control over all the variables within scope. With optimized code, it holds the variables in the registers.  They aren't pushed back to the variables location in RAM. Non-optimized code will push the variable back to RAM after every operation.

When an ISR fires it sees old data in the global variable, since the non ISR function hasn't pushed the updated data back to the location the ISR is expecting to read it.

Marking a variable volatile forces the optimizer to store the variable back to RAM after every operation. It stops the optimizer from just holding that variable in a register.

[matute]

Hi Norm,

It seems that I'm not using correctly variables as volatile. I will ckeck it and verify again.

Thanks a lot for your comments.

Matias

[mjbcswitzerland]

Matias

Changing optimisation will change RAM and Flash requirements (and location of code and variables) and if you have any code that is not correctly using volatiles it may also fail.

If you have a problem with RAM you may have stack and heap or varaibels corrupting each other and when the size of the program or RAM usage is modified it just means that the location of the corruption will change.

You seem to be in an unstable situation where small changes will cause different behavior. You need to first analyse and clean up the memory usage before things will start making sense and without doing this you can't generally expect sensible results.

Probably the best thing to do is take a step back and remove blocks of code (eg those requiring sprintf()) until you have a stable environment with known FLASH and RAM utilisation, with the optimisation levels of interest. Then add additional items, again check the footprint as you do this and you can then determine where the limits are.

Regards

Mark

Kinetis: µTasker Kinetis support

KL05: µTasker FRDM-KL05Z support

For the complete "out-of-the-box" Kinetis experience and faster time to market

[matute]

Thank you very much for your comments Mark.