topic Unwanted Variable Memory Overlap?! in CodeWarrior for MCU

Unwanted Variable Memory Overlap?!

ThurmaSan — Thu, 12 Jul 2012 17:45:20 GMT

Hello,

currently I'm using CW for MCU 10.2 Eclipse and realize variable memory overlap when using float support.

The following code fragment is used:

for (; {

status=I2C1_SendChar(0);

status=I2C1_RecvBlock(HMDaten,4,&anzahlEmpfangene);
tempRohwert = HMDaten[2] << 6 | ( HMDaten[3] & 0x3f );

tempMesswert= 165.0 / (2^14) * tempRohwert - 40.0;

}

I realized when stepping thru the I2C functions for the second time, the

variable InpLenM (from I2C1.c) gets corrupted (set to nonzero) , which leads I2C1_Sendchar(0); to fail because of

....

if((InpLenM)||(I2C1_SerFlag&(CHAR_IN_TX|WAIT_RX_CHAR|IN_PROGRES))) { /* Is the bus busy */
return ERR_BUSOFF; /* If yes then error */
}

...

I found that a variable (Kspec form rtsch08.c) from the floating point routines use the same memory position (0x0083 in my case) as InpLenM which leads to data modification.

What is wrong here? What leads the to that situation? Whats the reason for that unwanted shared memory usage?

Ideas are very welcome,

Yours,

A.Thurm

Re: Unwanted Variable Memory Overlap?!

CompilerGuru — Fri, 13 Jul 2012 08:36:31 GMT

Sounds like a stack size issue.

Search for STACKSIZE in the forum,

for example

https://community.freescale.com/message/60395#60395

Daniel

Re: Unwanted Variable Memory Overlap?!

ThurmaSan — Fri, 13 Jul 2012 15:01:18 GMT

Thanx Compilerguru for that quick answer,

that works fine for me.

But keeping STACKSIZE in mind leads me to the following question:

How much memory (for "stack" purpose) is used by the float routines?

Knowing this could help sizing STACKSIZE in the future.

Yours,

Andreas

Re: Unwanted Variable Memory Overlap?!

bigmac — Fri, 13 Jul 2012 21:41:17 GMT

Hello Andreas,

The measurement of stack usage required by a function, using FCS, is discussed in the following old thread.

https://community.freescale.com/message/54019#54019

This thread contains the following post -

It is possible to ascertain stack usage for a function using full chip simulation. Set up a test project using a much larger device to give sufficient RAM capacity, and then set the remaining unused stack to a known (non-zero) value, just prior to stepping over the trigononmetric function. Then examine the stack contents to determine the lowest address that still contains the known value. Subtract this from the current stack pointer, and you will have the stack usage for the function.

For initialising the stack contents, the following function might be of use. The first four positions below the current stack pointer are not initialised. The parameter lolimit represents the address of the bottom of the stack.

void clr_stack( word lolimit, byte val)
{
__asm {
        tsx
        lda val
LOOP:   aix #-1
        sta ,x
        cphx (lolimit)
        bhs LOOP
}
}

The code snippet shown, that uses HLI assembler, is applicable only to a HCS08 device. Perhaps the following thread may also be of interest.

https://community.freescale.com/message/37326#37326

Regards,

Mac

Re: Unwanted Variable Memory Overlap?!

CompilerGuru — Thu, 29 Oct 2020 09:28:19 GMT

There actually is even a new feature which was not available when that thread took place.

The current MCU 10 linker supports for the S08 to compute the stack size for simple code, it cannot handle recursive code, function pointers. But it does include calls to the runtime support. For example for this app

#include <hidef.h> /* for EnableInterrupts macro */#include "derivative.h" /* include peripheral declarations */float a = 1/3.0f;float b = 1/5.0f;float c;void t(void) { c = a/b;}void main(void) {  for(;;) { t();    __RESET_WATCHDOG();  }}

for the S08 QE128, banked memory model, I get the following in the map file if I enable the stack computation:

*********************************************************************************************STACK CONSUMPTION COMPUTATION---------------------------------------------------------------------------------------------1)FileName = C:/Users/r1aake/workspace/s08/a/MC9S08QE128/Project_Settings/Startup_Code\start08_c.obj_Startup = 39Maximum Stack Usage is calculated for following path:-----------------------------------------------------_Startup|+-main  |  +-t    |    +-_FDIV      |      +-_FDIV_Common        |        +-_FDIV_K_is_L_div_K

For mcu 10.2 it can be enabled in the project properties, C/C++ Build/Settings , int Settings are, select S08 Linker/Output,

check "Enable Stack Consumation Computation (-StackConsumption).

The feature supports to compute the stack of specific functions, for example for t. For details search the online help of MCU10.2 for "STACK_CONSUMPTION".

Also by adding the interrupt handlers separately, one can compute all the stack sizes which might accumulate. Even when a app has recursion, knowing how much stack certain non recursive functions like this t need helps a lot.

Cool nice feature .

Re: Unwanted Variable Memory Overlap?!

ThurmaSan — Thu, 19 Jul 2012 22:22:27 GMT

Once again,

thank you very much CompilerGuru for that information.

I make HEAVY usage of function pointers in my current application, so there is no way to step thru the entire code, because calls (even recursive) depend on user interaction. So "Enable Stack Consumation Computation (-StackConsumption)." will maybe lead to insufficent stack size.

(Well you know, dealing with FDIV on devices like S08DZ32 is a potential risk in terms of memory usage:-)

Yours,

Andreas

Re: Unwanted Variable Memory Overlap?!

bigmac — Fri, 20 Jul 2012 01:06:32 GMT

Hello Andreas,

If there remains any doubt whether the chosen stack size will be sufficient, you might wish to dynamically monitor for a stack overflow condition. This assumes that, should overflow be detected, there is a course of action that can be taken to report the issue, and that the overflow does not result in a reset.

The idea is to create a small segment immediately below the stack segment, and allocate a variable (say 32-bit) within this segment. Each time the main loop is executed, the variable can be checked for an altered value. If this variable is clobbered by stack overflow, it is very likely that some of your other static/global variables immediately below will also be affected.

Regards,

Mac