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.

opt_for_space produces invalid code (C2000 Code Generation Tools 5.2.7)

Hello,

i have a problem with the C2000 Code Generation Tools 5.2.7. When using the compiler option --opt_for_space it is possible that invalid code is produced. Normally the epilog of a function looks like this:

        SUBB      SP,#22
        MOVL      XAR3,*--SP
        MOVL      XAR2,*--SP
        MOVL      XAR1,*--SP
        SPM       #0

If opt_for_space is enabled the compiler is using the function "_epilog_c28x_2" in some circumstances. In this function the P register is used to modify the stack pointer. But when the modified value is written back into SP, this value can be modified by the PM bits in status register ST0. The function does not ensure that PM is set to 1 (= no shift).

        _epilog_c28x_2:
        MOV        PL, @SP
        SUBUL   P, @XAR0
        MOV        @SP, P
        MOVL      XAR3,*--SP
        MOVL      XAR2,*--SP
        MOVL      XAR1,*--SP
        LB           *XAR7

The line "MOV @SP, P" produces the error (see images below)

Is this a known problem? Is it fixed in newer code generation tools versions? I looked into the defect history but found nothing.

Best regards

Simon

  • Simon,

    To verify if there is a bug we would need a reproducible test case, at a minimum the source file(s) in question and complete build options. Please see the last part of this forum message for details on creating a preprocessed source file (so you don't have to send all header files).

    I would also suggest giving v5.2.11 a try (that is the latest version on the 5.2.x stream). It should be available as an update from CCSv4 (Help->Software Updates->Find and Install).

  • Here is the file and the build options. The problem is in function CL_AutoTuneBode::PackFrequencyData.

    C:\Programme\Texas Instruments\ccsv4\utils\gmake\gmake sys/Entity/Drive/AutoTune/AutoTuneBode.obj
    'Building file: ../sys/Entity/Drive/AutoTune/AutoTuneBode.cpp'
    'Invoking: Compiler'
    "C:/TI/C2000_527/bin/cl2000" --silicon_version=28 -g -O3 --cpp_default --preproc_only --define=_DEBUG --define=FPGA_CURRENT_CONTROL --define=XINTF_ZONE7_32BIT --define=FELDTEST --define=LARGE_MODEL --define=MC6 --define=LM_TEST --include_path="C:/TI/C2000_527/include" --include_path="D:/Projekte/DriveSystem/FW/V0/LXM62" --include_path="C:/TI/bios_5_41_02_14/packages/ti/bios/include" --include_path="C:/TI/bios_5_41_02_14/packages/ti/rtdx/include/c2000" --diag_warning=225 --display_error_number --diag_suppress=21 --large_memory_model --unified_memory --no_rpt --opt_for_space -k --output_all_syms --obj_directory="sys/Entity/Drive/AutoTune"  "../sys/Entity/Drive/AutoTune/AutoTuneBode.cpp"
    'Finished building: ../sys/Entity/Drive/AutoTune/AutoTuneBode.cpp'

    Do you need any further iinformation?

    I will try v5.2.11...

    AutoTuneBode.cpp
  • Simon,

    Thanks for sending the source file. I see that when compiling with your build options, that the following code is generated:

            MOVB      XAR0,#22
            FFC       XAR7,_epilog_c28x_2
            SPM       #0
            LRETR

    The call to epilog_c28x_2 occurs prior to resetting the PM bits, which looks like a bug to me. I see the same behavior with a newer version of compiler tools, v6.0.1.

    I have entered a bug report for this, the tracking # is SDSCM00041275. It has been assigned to the compiler team for further analysis. If they require more information or files to further analyze this issue, we will contact you. You may also track the status of the bug using the SDOWP link in my signature, by entering the tracking # in the 'Find Record ID" field. When the compiler team has updates to the status they will be visible from that link.