enum problem in Cla1ToCpuMsgRAM section

I'm not sure I understand. I think you are saying a memory location changes values for no apparent reason. That sounds like a hardware issue that we compiler experts cannot help with.

Thanks and regards,

-George

typedef enum
{
Done=0,
Init,
Start,
Rampup,
Rampdown,
} MOSPROF_State;

State=Done (result in 0x89E0000)
State=Init (0x89E0001)
If I move the state variable around in the struct that communicate with the CLA the problem moves with it. so I don't think it is a hardware issue.

evs said:

State=Done (result in 0x89E0000)
State=Init (0x89E0001)

Exactly how do you see these results?   -George

On C2000, that enum will be the same size as "int," which is 16 bits. The adjacent 16 bits with contents 0x89E0 are not part of the variable "State."

In the expression window with CCS debuger.

That can be true. But the state machine isn't working. If it happens to be 0 or I change it in CCS debuger to the state done. The code works correctly. The variable description in CCS debug expression window is: enum unknown.

So somehow in CpuToCla1MsgRAM or in CLA a enum is defined as 32 bit and in the main code as 16 bit. That should explain the problem.

edit:

 if I do a sizeof the MOSPROF_State enum i got 2

Sizeof enum in CLA memory is also 2

Sizeof enum(normal memory)  the size is 1.

So that is the problem.

Disassembly:

166         Servo_profile_init.state=Done;
3eac6e:   2B02        MOV          @0x2, #0  

That is a 16bit move and not a 32bit. This state is copied to the CLA and the uninitialized high word is then part of the result.
 

You are correct about the sizes of enum types.  On C28x, they are 16-bits.  On CLA, they are 32-bits.  It is similar to the problem with the size of pointers.  The pointer size problem, and a solution, is discussed in this wiki article.  You need to adopt a similar solution for any enum type shared between C28x and CLA.

Thanks and regards,

-George

I think that pointer alignment and 32 vs 16 bit  enums cast are a complete a difference  thing.  You know that also.

 

But the solution is the same: establish a union between the enum or pointer and a 32-bit integer. That forces it to occupy 32 bits with the proper alignment. When you read or write it on the 32-bit side, it'll see a properly aligned and sized 32-bit entity. When you read or write it on the 16-bit side, it will see a 16-bit entity.

You don't understand the problem. Please reproduce the problem your self. Or forward it to a more experiences TI employee.

The problem is not in the CLA but in the main program.

 I will show you;

CLA mem: enum is int32.

Cla1ToCpuMsgRAM  enum is int32

in main memory enum is int16.

When you copy enums in CLA: in32=int32 // which is correct!

When you copy/define a enum in main program with memory from Cla1ToCpuMsgRAM   the compiler assumes it is int16 so It typecast it to: int32=(int16)int32;

So if there is any value(uninitialized) in the high part of the int32 your enum value is invalid. And that is a problem.

 To get around the int32=(int16)int32; typecast

 I solved it this way in the main program and not in the CLA!!

    long *ptr = (long *)&Servo_profile_init.state;
    *ptr=0;

In this way the complete enum is completely cleared  in main memory. 

It is a compiler issue because the size of a enum is not always int16 in main program. it is int32 when it is placed Cla1ToCpuMsgRAM so the compiler need to manage that.