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

Ram corruption

Hello,

I have the following piece of code:

static void SETBIT( Pcf8574 xdata *Object, Nat8 Pin, Nat8 Active )
{
    ASSERT( ( 0 <= Pin )
          &&( Pin <= 7 )
          );

    ASSERT( ( Active == TRUE )
          ||( Active == FALSE )
          );

    if ( (Bool)Active )
    {
        Object->Buffer |= (_crol_( 0x01, Pin ) & 0xFF);
    }
    else
    {
        Object->Buffer &= (~_crol_( 0x01, Pin ) & 0xFF);
    }

    WriteI2c( Object );
}

This function receives a pointer to an object (object is a structure with two elements of type unsigned char). The object is located in XDATA, hence the memory specifier.

After some processing on the object (changing a bit in the Buffer member of the structure), the object is passed as an argument to the function WriteI2c().
The prototype of this function is:
static void WriteI2c( Pcf8574 xdata *Object ).

When the function SETBIT is called, the address of Object is (in my case) X:0x000002 and points to location X:0x00014D in Ram, where my array of structures is located (in the example given, the pointer points to the second element of the array).

Up until the call to WriteI2c( Object );, everything is ok. However, when I enter the function WriteI2c(), all of a sudden the address of the object Object is changed from X:0x000002 to D:0x04 (still points to the Ram location X:0x00014D). How can this change of memory space from XDATA to DATA be explained for the address of Object???.

I also encounter another problem:

Below, you can find the implementation of the function WriteI2c():

static void WriteI2c( Pcf8574 xdata *Object )
{
    i2c_swi2c_Write( Object->I2cAddress
                   , &( Object->Buffer )
                   , 1
                   );
}

The assembly code of this function is:

   129: static void WriteI2c( Pcf8574 xdata *Object )
C:0x45AC    8F82     MOV      DPL(0x82),R7
C:0x45AE    8E83     MOV      DPH(0x83),R6
   130: {
C:0x45B0    E0       MOVX     A,@DPTR
C:0x45B1    FF       MOV      R7,A
C:0x45B2    AC83     MOV      R4,DPH(0x83)
C:0x45B4    AD82     MOV      R5,DPL(0x82)
C:0x45B6    ED       MOV      A,R5
C:0x45B7    2401     ADD      A,#0x01
C:0x45B9    FD       MOV      R5,A
C:0x45BA    E4       CLR      A
C:0x45BB    3C       ADDC     A,R4
C:0x45BC    FA       MOV      R2,A
C:0x45BD    A905     MOV      R1,0x05
C:0x45BF    7B01     MOV      R3,#0x01
C:0x45C1    90000A   MOV      DPTR,#0x000A
C:0x45C4    7401     MOV      A,#0x01
C:0x45C6    F0       MOVX     @DPTR,A			<===!!!
C:0x45C7    0231D2   LJMP     i2c_swi2c_Write(C:31D2)

This function also gives me problems: when the command on the line indicated by "<===!!!" is executed, I get a Ram corruption.

Earlier in the process, there has been declared a buffer in XDATA as follows:
xdata Nat8 buf[ 40 ];.

This buffer is filled with the result of the following command:
sprintf( buf, "Date: %s - Time: %s", __DATE__, __TIME__ );

This buffer is (again in my situation) located on address X:000008. When the line with the indication above is executed, it overwrites (among other locations) the content of my buffer on address X:0x00000A.

What happens is that the value #0x000A is loaded into the DPTR (third last assembly line). After that, the value 0x01 is loaded into A and then the content of A is written to locaion X:0x00000A via a MOVX instruction, so to XDATA.
But I have a buffer which is already assigned to this memory location!!!
"buf" is positioned between the locations X:0x000008 and X:0x000038, so why is the code generating instructions to write on location X:0x00000A (so, overwriting other memory areas)??? Can someone explain this? To my humble opinion, this should not happen!

Also creating temporary variables like given in the code below, doesn't solve the issue:
static void WriteI2c( Pcf8574 xdata *Object )
{
    Nat8 TempAddress = Object->I2cAddress;
    Nat8 TempData    = Object->Buffer;

    i2c_swi2c_Write( TempAddress
                   , &TempData
                   , 1
                   );
}

I've looked already for hours to this problem but can't find neither an explanation nor a solution.

Any help is highly appreciated.

Rgds,

Geert

PS.: uVision2, compiler = V7.02b

Parents
  • Up until the call to WriteI2c( Object );, everything is ok. However, when I enter the function WriteI2c(), all of a sudden the address of the object Object is changed from X:0x000002 to D:0x04 (still points to the Ram location X:0x00014D). How can this change of memory space from XDATA to DATA be explained for the address of Object???.

    Probably because there is more than one object named object. The argument to the WriteI2C function is stored in registers which are in data memory.

    Your second problem appears strange. It appears that the last argument passed to the i2c_swi2c_Write function is being stored in that function's argument space in XDATA. You can find out where this is located by looking for the ?XD?filename?I2C_SWI2C_WRITE symbol. Its address will probably be something like 0x000A.

    Actually, there's not enough information to really figure out what's going on here. If you continue having problems you may want to contact technical support.

    Jon

Reply
  • Up until the call to WriteI2c( Object );, everything is ok. However, when I enter the function WriteI2c(), all of a sudden the address of the object Object is changed from X:0x000002 to D:0x04 (still points to the Ram location X:0x00014D). How can this change of memory space from XDATA to DATA be explained for the address of Object???.

    Probably because there is more than one object named object. The argument to the WriteI2C function is stored in registers which are in data memory.

    Your second problem appears strange. It appears that the last argument passed to the i2c_swi2c_Write function is being stored in that function's argument space in XDATA. You can find out where this is located by looking for the ?XD?filename?I2C_SWI2C_WRITE symbol. Its address will probably be something like 0x000A.

    Actually, there's not enough information to really figure out what's going on here. If you continue having problems you may want to contact technical support.

    Jon

Children