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.

RTOS/EK-TM4C1294XL: How is EMAC_config registered to the stack?

Part Number: EK-TM4C1294XL

Tool/software: TI-RTOS

How are the callbacks and variables in EMAC_config registered with the NDK stack?

The NDK Guide says the CSL layer "defines the required callback functions in the "EMAC_Config" data structure and mandates that the driver implement these functions and register them with the driver during the "EMAC_open" call".

The EMAC_call function is not in the example projects. It seems to be contained in pre-built libraries. I think this because commenting out EMAC_config gives the error "unresolved symbol EMAC_config, first referenced in C:/ti/tirtos_tivac_2_16_00_08/products/tidrivers_tivac_2_16_00_08/packages/ti/drivers/lib/drivers_tivaware.aem4f<EMAC.oem4f> httpget_EK_TM4C1294XL_TI C/C++ Problem"

How can these libraries access the variable EMAC_config? EMAC_config is declared in a .c file with no reference in the .h file. I thought variables have to have "extern const EMAC_Config EMAC_config" in the .h file for other files to access .c file contents.

I can only see EMAC_config iused in the line #pragma DATA_SECTION(EMAC_config, ".const:EMAC_config")

Where is DATA_SECTION telling EMAC_config  to be? I expected this to be in the linker file EK_TM4C1294XL.cmd because the wiki says " the defined memory segments of IAR's linker configuration file and memory section of CCS's linker command file can be used with constseg pragma and DATA_SECTION pragma respectively to put a variable inside a specific memory location". Am I misunderstanding?

Should DATA_SECTION not be used? The same wiki page seems to imply the location pragma is preferred to DATA_SECTION: "older CGT version v3.x which does not support the location pragma, and instead for this purpose the DATA_SECTION pragma can be used" - http://processors.wiki.ti.com/index.php/Placing_Variables_in_Specific_Memory_Location_-_MSP430#Using_DATA_SECTION_PRAGMA_With_Defined_Memory_Section_in_Linker_Command_File

  • Additional fun facts and document resources would be appreciated. A through understanding of CCS would help me answer my own questions.

  • Hi Peter,

    The EMAC_config structure is defined in the "board.c" file but used in the tirtos_tivac_2_16_01_14\products\tidrivers_tivac_2_16_01_13\packages\ti\drivers\emac\EMACSnow.c file (I know...horrible name).

    If you look in the EMACSnow file you'll see

    extern EMAC_Config EMAC_config;

    and then several references to it. The EMACSnow.c is part of the TI-RTOS driver library (not to be confused with TivaWare driverlib...TI-RTOS drivers are built on top of driverlib APIs).

    As writing this up, we should have used "const" in the EMACSnow.c file to potentially get a little better optimization and make it obvious that we cannot change any values. We don't modify the structure though...I'm not a compiler guy so I'm not sure if it would have made a difference in the code.

    We debated on whether to have the EMAC driver library reference the variable that the application must define or have the application pass in a pointer to it. We decided on the former. The may reason was that we wanted to keep the number of APIs down.

    Todd

  • Additionally...regarding the #pragma usage...there was a TI linker issue that was pulling in some of the code even if no one referenced it. For example, Empty was pulling all the EMAC/UART/I2C/etc. code. Adding the #pragma "fixed" the problem. I don't remember the exact linker version that fixed the issue. This problem did not exist in the IAR (or GCC) compilers.

    Todd
  • I hadn't given thought to the snowflake naming theme until now. Personal style is a good thing.