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.

TMS320F280025: RPT ||MOV instruction issue when migrate F2802x to F280025

Part Number: TMS320F280025

Hi Expert,

My customer migrate the below code from F2802x coff to F280025 eabi, there will have the error, also it seem ||MOV  instruction is commented out.

[E0800] Instructions not permitted in structure/union definitions

there is no this issue at F2802x with the same code, any suggestion for this? 

  • Hi Strong,

    Sincere apology for late response. I have just reassigned to C28x expert. Please expect response by Monday.

  • Strong,

    Is this hand-written assembly code or compiler generated code? Could you provide more specific detail on which line or lines the compiler throws an error to?

    My understanding is that the ||MOV is not actually "commented out" even though it appears in Green.

    Thanks,

    Sira

  • Strong,  I consulted with some experts within the compiler team, and they've requested a reproducible test case. For this, you could build your project in preprocess only mode as shown in the picture.

    Additionally, if you're building with EABI, the assembly shouldn't have symbols with leading underscores like _VAC_OFFSET_NEG. Have you consulted the C28x EABI migration guide?

    https://software-dl.ti.com/ccs/esd/documents/C2000_c28x_migration_from_coff_to_eabi.html

    Thanks,

    Sira

  • Hi Sira,

    Thanks for your help.

    It seem the error have nothing to do with ||MOV.

    [E0800] Instructions not permitted in structure/union definitions

    by delete the code, finally check the error is caused by below code,

    .cdecls C, LIST, "f28x_project.h"

    there is no error if comment out above code, the path of f28x_project.h is correct.

    any suggestion for this?

  • Hi Sira,

    We find the root cause, in customer .h file, they define ERROR as below, then there will have the error.

    #define ERROR 0x11

    Remove this define, there will no this error.

  • Strong,

    I've asked for this issue to be re-assigned to the right experts.

    Thanks,

    Sira

  • The .cdecls directive does not support the same identifier appearing as a #define name and the name of a field in a struct, union, or enum.  This is the case even though it is possible to do that in C.  How that happens in this case is not obvious.

    The .cdecls directive refers to a header file ...

        .cdecls C, LIST, "f28x_project.h"

    The header file f28x_project.h has these lines ...

    #include "f28002x_device.h"         // f28002x Headerfile Include File
    #include "f28002x_examples.h"       // f28002x Examples Include File
    #define ERROR 0x11

    In C, the definition of ERROR has no effect on the header files included on previous lines.  But when processed by .cdecls, it does.  Please search the C28x assembly tools manual for the sub-chapter titled Overview of the .cdecls Directive.  Near the end is the phrase ...

    the converted assembly code does not appear in the same order as the original C/C++ source code

    When building the assembly file that contains .cdecls, use the option --asm_listing.  This creates a listing file with the same name as the source file, with the extension changed to .lst.  Inspect the listing file.  This automatically generated line ...

     A   286                         .define "0x11",ERROR 

    ... appears early in the file, before the lines that correspond to the struct definitions from the header files.  

    One of the header files included by f28x_project.h, through other header files, is f28002x_nmiintrupt.h.  That header file has these lines ...

    struct ERRORSTS_BITS {                  // bits description
        Uint16 ERROR:1;                     // 0 Error flag.
        Uint16 PINSTS:1;                    // 1 Error pin status.
        Uint16 rsvd1:14;                    // 15:2 Reserved
    };
    
    union ERRORSTS_REG {
        Uint16  all;
        struct  ERRORSTS_BITS  bit;
    };
    
    struct ERRORSTSCLR_BITS {               // bits description
        Uint16 ERROR:1;                     // 0 ERRORFLG.ERROR clear bit
        Uint16 rsvd1:15;                    // 15:1 Reserved
    };
    
    union ERRORSTSCLR_REG {
        Uint16  all;
        struct  ERRORSTSCLR_BITS  bit;
    };
    
    struct ERRORSTSFRC_BITS {               // bits description
        Uint16 ERROR:1;                     // 0 ERRORSTS.ERROR pin force.
        Uint16 rsvd1:15;                    // 15:1 Reserved
    };

    Note how ERROR appears as the name of a field in three of those struct types.  But because of ...

    #define ERROR 0x11

    ... and how .cdecls works, all these instances of ERROR are replaced by 0x11.  That forms invalid assembly code.  Thus the assembler issues error diagnostics ...

    Instructions not permitted in structure/union definitions

    Thanks and regards,

    -George

  • George,

    Thanks a lot for your clarification. that is clear.