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.

TMS320F28P650DK: [E0004] Cannot redefine existing opcode 'EALLOW' with .define. Assembler ignoring .define."

Part Number: TMS320F28P650DK
Other Parts Discussed in Thread: C2000WARE

Hi,

I'm working with the CLA on a C2000 device and I ran into an assembler warning that I don't fully understand.

Project setup:

  • I started from the C2000Ware example cla_ex7_shared_resource_handling.

  • I removed (excluded from build) the original .cla source file.

  • I added my own CLA task file written in assembly (.asm) instead.

  • The project builds, links, and loads to the device fine, and the CLA code runs.

  • However, I get this warning during build:

    [E0004] Cannot redefine existing opcode 'EALLOW' with .define. Assembler ignoring .define.

My questions:

  1. What is causing this warning?
    (It looks like EALLOW is already defined as an opcode / instruction, and somewhere in the project or headers it's also being defined as a macro, but I'm not sure where that's coming from in the CLA context.)

  2. What's the correct / recommended fix?

  3. Is there a recommended template for writing CLA tasks in pure assembly (.asm) instead of using the provided .cla file format, so that I avoid conflicts like this?

Extra detail:

  • The warning only appeared after I swapped the .cla file for my .asm file. When I build the unmodified example (with the provided .cla source), I do not see the warning.

  • Toolchain: [CCS 20.3 / C2000Ware 6.0.0.00 / ti-cgt-c2000_22.6.2.LTS]

  • Device: [F28P650DK]

I'd appreciate any guidance on the "right" way to structure CLA assembly source for this example so the assembler doesn't complain about EALLOW.

Here is the full project compressed:
cla_ex7_shared_resource_handling.zip 

Thanks!

  • Hi Sebastian,

     TMS320F280039C: EALLOW/EDIS not allowed in CLA background or a sub inline function? 

    Please see the above forum post for the CLA equivalent (MEALLOW) for the opcode mentioned in your post.

    Regards,

    Ozino

  • Hi Ozino — thanks for the pointer. Just to clarify: I’m not using EALLOW/EDIS in my CLA code (I know the CLA equivalents are MEALLOW/MEDIS). I only want to get rid of this assembler warning.
    From what I can tell, the warning is triggered because a C device header (pulled in via .cdecls) defines EALLOW/EDIS as macros that expand to the CPU instruction, and the assembler complains since EALLOW is already an instruction mnemonic. I’m not calling them in the CLA; the macro definition itself is what causes [E0004] Cannot redefine existing opcode 'EALLOW'….
    If there’s a TI-recommended CLA template (for pure .asm instead of .cla) that avoids these macro collisions, I’m happy to switch to that as well. The main goal is to keep the build clean without introducing CPU-only macros into the CLA build.

  • Hi Sebastian,

    Thanks for the clarification. Can you confirm which file is using the .cdecls

    Typically there are code snippets like, below, that are used to tell the compiler what version to use for the EALLOW.

    //
    // Define to allow writes to protected registers
    //
    #ifndef EALLOW
    #ifndef __TMS320C28XX_CLA__
    #define EALLOW __eallow()
    #else
    #define EALLOW __meallow()
    #endif // __TMS320C28XX_CLA__
    #endif // EALLOW

    By including this code it should avoid that issue. Let's try it and see if that works.

    Another questions, are you generating C compiled assembly and trying to run it on the CLA? If so the .cdecls section will need to be modified similarly to the above mentioned code.

    See this document for more information. https://downloads.ti.com/docs/esd/SPRUI03/overview-of-the-cdecls-directive-stdz095556.html 

    Regards,

    Ozino