This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CCS - CC3200: enum value not being assigned

Dear all 

I have a rather strange problem, in that an instruction that assign a new value to an enum type is being ignored.

In a header file I defined my enum as

typedef enum

{

my_UndefState = 0,

my_WorkingState1,

my_WorkingState2,

my_WorkingState3

} my_enum_t;

I have also implemented a task routine, running in TIRTOS, as a while loop, in the form

while(1){

Event_pend(...);

do_whatever  {

}

}

The enum object is defined as

my_enum_t my_enum = my_UndefState;

within the routine, prior to the while loop.

In the while loop I have different if conditions and depending on those a new value should be assigned to my_enum.

While the code seems to work fine,  the value of my_enum never changes, and I don't have any warning or error about that.

The problem appears to persist even if  I use an unsigned char in place of my_enum_t  to define the my_enum  object.

If I use modifiers such as volatile, or if I define my_enum as an extern variable in the header, the problem presents itself as well.

Do you have any idea as to why this enums behaves strangely?

I used others enums without apparent problems.

Regards.

john

 

  • There isn't much here to go on.  My instinct says enum types have nothing to do with it.  As I understand it, this statement ...

    john doe95743 said:
    my_enum_t my_enum = my_UndefState;

    executes as expected.  But then my_enum is never assigned again.  Is that right?  I presume so.  Just as an experiment, change all the enum assignments to function calls.  Do any of those functions ever get called?  My guess is they don't. 

    Thanks and regards,

    -George

  • Hello John,

    It could be that code optimization is causing your variable to not be updated properly in the expressions windows.  Change your enum variable to a global variable and then see if it shows up correctly in the expressions window.

    Stephen 

  • I am sorry for the late answer and for not correcting my previous statement.

    Actually, in my setup no optimization is used. 

    Also, apparently, it has nothing to do with enums but rather, with the assignment itself.

    As I understood the issue, the problem is  related to a function that is called before the assignment. The function is supposed to return a value, but said value is actually ignored, since there is no variable to get it. Therefore the first assignment after the function it appears to be ignored, or maybe the return value is forced in the variable in place of the value supposed to be assigned.

    In fact if I put an additional unnecessary assignment, or if I collect the value returned by the function (which is an assignment as well), the problem never presents itself again.

    Quite creepy I'd say.

    I don't have the issue anymore, at the moment, but I feel like the problem is likely to be in the compiler.

    Thank you for your time anyway 

  • Hello John,

    "Therefore the first assignment after the function it appears to be ignored, or maybe the return value is forced in the variable in place of the value supposed to be assigned."

    Can you please post more of the actual code or an example of the actual code.

    Do you mean what is described by the code below?

    int abc;
    int def;
    int ghi;
    ghi = 6;
    int func(void); // ignore func()'s return value,e.g the number 3; func();
    // The value 6 is not stored in abc, The ignored func()'s return value (e.g. 3) is stored in abc. abc = ghi;

    "In fact if I put an additional unnecessary assignment, or if I collect the value returned by the function (which is an assignment as well), the problem never presents itself again."

    Please post more of the actual code or an example of the actual code.

    Do you mean what is described by the code below?

    int abc;
    int def;
    int ghi;
    
    ghi = 4;
    
    int func(void);
    
    // The return value is not ignored.  The value returned from func() is the number 1;
    def = func();
    
    // The value 4 is stored in abc 
    abc = ghi;
    

    Also, it might be best for you to single step through the assembly code.

    Thanks,

    Stephen

  • Dear Stephen

    that's almost what appears to happens.

    I am sorry since I cannot  paste a working code sample, since it's really long (spans over several files).

    The code snippet, however, is the following:

    iRetVal = RFA_SendBeaconReq( bUpdateStatusMode ); // do not remove iRetVal or the WG_Status assignment will be ignored.

    //WGTEST = 1;

    WG_Status = WG_BeaconReqTX;

     

    If i remove the "iRetVal =" part, WG_Status remains equal to zero.

    Since RFA_SendBeaconReq is supposed to return zero, and actually zero was the default value for both WGTEST AND WG_Status, I don't actually know for certain if the assignment is simply ignored or actually forced with some other value that happens to be zero.

    I cannot say for certain, but I believe that maybe the issue may be related to a couple of malloc calls that are in a subfunction within SendBeaconReq, since I've never noticed this occurrence anywhere else in the code.


    At the moment I am pressed for time,  thus I cannot investigate further, nonetheless I will take into account your suggestion and work on it at the first occasion.

    Thank you very much.

     

    John.

     

  • Hello again, and thanks for the suggestions in the other topic as well.

    Back to this topic, you ask:

    stevenh said:

    Do you mean what is described by the code below?

    int abc;
    int def;
    int ghi;
    ghi = 6;
    int func(void); // ignore func()'s return value,e.g the number 3; func();
    // The value 6 is not stored in abc, The ignored func()'s return value (e.g. 3) is stored in abc. abc = ghi;

    I went back to check and that's exactly what's happens.

    I found where the error lies in the subroutines.

    For completeness sake, the solution to the issue is reported in the other thread :

    https://e2e.ti.com/support/development_tools/compiler/f/343/p/454042/1636272#1636272

    Thank you again.

    Sincerely.

    John