This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Value get changed in function arrgument (fixed memory location)

dear friend,

i have function fSaveData. which is called at depth of 5

void fSaveData( uint8x_t* ucArray, uint16x_t uiStartAddress, uint16x_t uiTotal_Bytes,uint8x_t ucResetFlag)

{

uint16x_t aa;
uint16x_t bb;
uint8x_t cc;
uint16x_t dd;
uint16x_t ee;
uint16x_t ee;
uint16x_t ff;
uint8_t gg[15]={0};

// code
//code

// withing that function i am calling one more function, depth of 6
fWrite2eeprom(ucArray,uiStartAddress,ucCummBytes,uiIndex,ucResetFlag);
//

}

as per http://www.keil.com/support/man/docs/c51/c51_le_funcparmsstack.htm
c51 had given fixed addred to each variable. but when i called function fWrite2eeprom
then my variable of function fSaveData get courrupts
this is happning frequently.

this may be case of stack overflow. but in every courrption i got same value in XRAM fixed location.

please help me on this! please ask if my question is not clear

yogesh

Parents
  • But that is not a problem with the C51 compiler, but with how it is used.

    It is well documented that C51 converts auto variables and parameters into global variables shared memory locations with other auto variables and parameters based on the call tree analysis.

    So ISR:s shouldn't call same functions as main loop does. And code should specifically mark functions that needs to be reentrant - or code rewritten to not make sure of recursive designs.

    The important thing here is that the 8051 chip just isn't designed for use with a traditional stack for parameters and local variables.

Reply
  • But that is not a problem with the C51 compiler, but with how it is used.

    It is well documented that C51 converts auto variables and parameters into global variables shared memory locations with other auto variables and parameters based on the call tree analysis.

    So ISR:s shouldn't call same functions as main loop does. And code should specifically mark functions that needs to be reentrant - or code rewritten to not make sure of recursive designs.

    The important thing here is that the 8051 chip just isn't designed for use with a traditional stack for parameters and local variables.

Children
  • Dear Per Westermark,

    i analyzied your reply, please find my query in embedded with your reply.

    But that is not a problem with the C51 compiler, but with how it is used.
    


    accpect, i may not be aware of it, but want to be!

    It is well documented that C51 converts auto variables and parameters into
    global variables shared memory locations with other auto variables and parameters
    based on the call tree analysis.
    


    if possible provide me document links,also i want to see call tree, is this possible?

    So ISR:s shouldn't call same functions as main loop does.
    

    in my case function is only called in ISR, not in ground loop.

    see my interrupt

    static void XFER (void) interrupt 13      //one sec and one min interrupt metrology
    {
    
            int a=0x00;
            gucOneMinuteCount++;
            fTimeinSec();// changed 20/apr/2012
    

    in this interrupt function is fTimeinSec();//

    please see function

    void fTimeinSec()
    {
            uint32x_t lRTsec,ltemp;
            const int lDaysInMonth[12]={0,31,59,90,120,151,181,212,243,273,304,334};
    .
    .
    .
    .
    }
    

    now what complier did, it assigned same fixed memory location to varialbles
    used in function fTimeinSec() and some of the ground loop function arguments.
    ofcourse this may due to function fTimeinSec() is not dependent on any function.
    but interrupt can be occure any time (that is why it is interrupt). call tree found
    interrupt function and ground loop function is independent while it is not. then it courrupt locations.

    now it looks clearly, call tree analysis not done properly. interrupt variable and arrguments should consider for call tree dependancy.

     And code should specifically mark functions that needs to be reentrant - or
    code rewritten to not make sure of recursive designs.
    


    neither i am using reentrant nor i m using recursive designs.

    The important thing here is that the 8051 chip just isn't designed for use
    with a traditional stack for parameters and local variables.
    


    it would be your great help if you make understand what is limitation of traditional stack for parameters and local variables.

    thanks,

  • in my case function is only called in ISR, not in ground loop.

    see my interrupt

    in this interrupt function is fTimeinSec();//

    KISS, keep interrupts short and simple

    have your interrupt increment some variable and in main() use it and, correspondingly, decrement it

    how is gucOneMinuteCount defined? truly global, module local, local?

    it seems that with your construct fTimeinSec(); acn, just as well, be called in main

    Erik

  • dear Erik,

    Variable gucOneMinuteCount is defined as

    1) volatile uint8x_t gucOneMinuteCount=0x00; in Global file. this variable is increment in interrupt and checked in ground loop.

    it is true globle variable.
    2) in function fTimeinSec(); i apart from local variable (which i already mentioned), i m using one more globle variable i.e. gRTsec which is defined as - int32_t gRTsec=0; (global).

    fTimeinSec(); is called at only interrupt.

    regards,

  • fTimeinSec(); is called at only interrupt.
    WHY?, it will work just as well in the main()

    KISS

    Erik

  • Dear Erik,

    My interrupt is triggers on every sec. so i don't want to update my variable before one sec. that's why i m calling this function at every 1 sec interrupt.

    in groud loop its frequency of updation is very high, which i don't want.

    But still all above question is alive?

    yogesh

  • if (gucOneMinuteCount != old....)
    {
    old... = gucOneMinuteCount;
    fTimeinSec()
    }
    

  • hi,

    Now it looks some problem exist, and your suggesting work around.

    And moreover we are not discussing about problem.
    why same address is assigned to procedure arrgument in interrupt?

    now i'will not reply here, but if any body want to discuss then again i am avaiable.

    yogesh