• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 97 subscribers
  • Views 440 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Compiler/TMS320C6678: Different behavior with/without printf

Idris Kempf
Intellectual 685 points

Part Number: TMS320C6678

Tool/software: TI C/C++ Compiler

Hi there,

following two situation lead to different behavior and it is crucial to me to know why:

1.) Code includes a printf statement:

#pragma DATA_SECTION(selfId, ".local_data")
Uint32 selfId;
void main(void) {
    selfId = CSL_chipReadReg(CSL_CHIP_DNUM);
    printf("selfId = %d\n", selfId);
    config_cache(selfId);

....

2.) Code does not include a print statement:

#pragma DATA_SECTION(selfId, ".local_data")
Uint32 selfId;
void main(void) {
    selfId = CSL_chipReadReg(CSL_CHIP_DNUM);
    config_cache(selfId);

....

In both cases .local_data maps to L2SRAM with L2SRAM defined in platform package as: {name: "L2SRAM",base: 0x00800000,len: 0x00080000,space: "code/data",access: "RWX" }. The same image is uploaded to each core.

Function config_cache asserts that selfId is between 0 and 7. I am getting different results depending on whether I include the printf statement or not:

- For situation 1 (with printf), things work fine, except that I am getting an error like "Invalid CIO command (11) in the CIO buffer at address (0xC02C248) was not recognized. Please check the device and program memory maps.". I guess that is due to the fact that several cores print at once.

- For situation 2 (without printf), the code fails with an assertion error. Function config_cache seems to see some random values

Please help. Thank you very much.

  • 0
    TI__Guru** 116960 points

    Idris,

    Please checkout the guidelines provided by our compiler team on using CIO printf in code :

    http://software-dl.ti.com/ccs/esd/documents/sdto_cgt_tips_for_using_printf.html

    In multicore programming using System_printf(TI RTOS) and UART_prinf using UART driver are better options as they are not intrusive and streamline use of IO functions.

    Regards,

    Rahul

  • 0 in reply to Rahul Prabhu
    Intellectual 685 points

    Hi Rahul,

    thank you very much for your answer. The phenomenon persists when I'm using System_printf. I reformulated the question in:

    https://e2e.ti.com/support/processors/f/791/t/823735

    Best wishes,

    Idris

  • 0
    Intellectual 685 points

    Part Number: TMS320C6678

    Tool/software: TI C/C++ Compiler

    Hi there,

    following two situation lead to different behavior and it is crucial to me to know why:

    1.) Code includes a System_printf statement:

    #pragma DATA_SECTION(selfId, ".local_data")
    Uint32 selfId;
    void main(void) {
        selfId = CSL_chipReadReg(CSL_CHIP_DNUM);
        System_printf("selfId = %d\n", selfId);
        config_cache(selfId);

    ....

    2.) Code does not include a System_printf statement:

    #pragma DATA_SECTION(selfId, ".local_data")
    Uint32 selfId;
    void main(void) {
        selfId = CSL_chipReadReg(CSL_CHIP_DNUM);
        config_cache(selfId);

    ....

    In both cases .local_data maps to L2SRAM with L2SRAM defined in platform package as: {name: "L2SRAM",base: 0x00800000,len: 0x00080000,space: "code/data",access: "RWX" }. The same image is uploaded to each core:
        .local_data:       > L2SRAM

    Function config_cache asserts that selfId is between 0 and 7. I am getting different results depending on whether I include the printf statement or not:

    - For situation 1 (with System_printf), things work fine.

    - For situation 2 (without System_printf), the code fails with an assertion error. Function config_cache seems to see some random values and the values are mixed up among cores: e.g. some cores all obtain selfId=3. I would understand this phenomenon if selfId would be placed in shared memory, but since it is placed in the cores local memory I don't understand it anymore.

    Please help. Thank you very much.

  • 0
    TI__Genius 9065 points

    Hello ldris,

    Which core is running the test? What is your compiler options?

    Can you try this:

    volatile Uint32 selfId;

    best regards,

    David Zhou

  • 0 in reply to dzhou
    Intellectual 685 points

    Hi David,

    Thank you for your answer. To start with: in order to simplify things, I removed the BIOS components required for System_printf and switched to assertions.. I'm compiling on the highest optimisation level and the compiler output looks like:

    Building file: "../main_blkdg_matmpy_ipc_shram_v3.c"
    Invoking: C6000 Compiler
    "/home/idris/ti/ccsv8/tools/compiler/ti-cgt-c6000_8.2.4/bin/cl6x" -mv6600 --abi=eabi -O3 --opt_for_speed=5 --include_path="/home/idris/ti/pdk_c667x_2_0_11/packages" --include_path="/home/idris/ti/pdk_c667x_2_0_11/packages/ti/csl" --include_path="/home/idris/ti/ccsv8/tools/compiler/ti-cgt-c6000_8.2.4/include" --define=SOC_C6678 -g --diag_warning=225 --diag_wrap=off --display_error_number --preproc_with_compile --preproc_dependency="main_blkdg_matmpy_ipc_shram_v3.d_raw" --cmd_file="configPkg/compiler.opt" "../main_blkdg_matmpy_ipc_shram_v3.c"

    It does include with configPkg/compiler.opt because I defined my own platform package which requires some generic platform to be loaded. However, the *.cfg for the BIOS is empty. The program is loaded onto all 8 cores.

    It is a bit embarrassing but the volatile keyword fixed my problem (I had to change some vars in config_cache() to volatile as well). Why is that so? Local data is defined with the local address range of the L2SRAM of each core. So each core should only access his own memory, shouldn't it? Moreover, caching of other cores L2 memory is not enabled (not even sure if that would be possible).

  • 0 in reply to Idris Kempf
    TI__Genius 9065 points

    Hello Idris,

    The volatile keyword is a hint to the compiler that it should not be overly-clever when trying to optimize expressions involving a particular variable.

    If you want to compare, you can compare the assembly code (which compiler generate) with or without volatile keyword and you will see the difference.

    best regards,

    David Zhou