• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 83 subscribers
  • Views 462 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.

Original question:

epwm skipping

TMS320F280039C: CPU skipping instructions unless breakpoint is added before them

Lucas Sinopoli
Intellectual 671 points

Part Number: TMS320F280039C
Other Parts Discussed in Thread: C2000WARE

Hi there,

I'm facing a problem in which the CPU is skipping instructions with no evident cause. It has happened already in the following two ocasions:

1. When writing to a float32_t array by calling the function provided by TI static inline void SPLL_1PH_SOGI_reset(SPLL_1PH_SOGI *spll_obj)
In this case, the function has the following three lines:
spll_obj->u[0]=(float32_t)(0.0);
spll_obj->u[1]=(float32_t)(0.0);
spll_obj->u[2]=(float32_t)(0.0);
After the function is called from my ISR, I can see in the Expressions window that u[0] = 0, but u[1] and u[2] are different than zero.

2. When writing zero to the EPwm6 CMPA register by using TI's drivelib function EPWM_setCounterCompareValue(uint32_t base, EPWM_CounterCompareModule compModule, uint16_t compCount)
After the function is called, I check in the Registers window the value of EPwm6 CMPA and the value of the register is different than zero.

In both cases, if I place a breakpoint right before the function call, then the instructions ARE NOT skipped, and the behaviour is as expected. On the contrary, if I don't place such breakpoint, the instruccions are skipped by the processor.

Could you please help me resolve this issue?

Many thanks,
Lucas

I'm copying the compiler flags below for your reference. I've deleted some details for the include paths for confidentiality reasons.

-v28 -ml -mt --cla_support=cla2 --float_support=fpu32 --tmu_support=tmu0 --vcu_support=vcu0 -O1 --opt_for_speed=5 --fp_mode=relaxed --include_path="C:/ti/c2000/C2000Ware_4_01_00_00/device_support/f28003x/common/include" --include_path="C:/ti/c2000/C2000Ware_4_01_00_00/device_support/f28003x/headers/include" --include_path=".../device" --include_path=".../device/driverlib" --include_path="C:/ti/c2000/C2000Ware_4_01_00_00/driverlib/f28003x/driverlib" --include_path=".../libraries/SM" --include_path=".../libraries/CLAmath" --include_path=".../libraries/DCL" --include_path=".../libraries/POW" --include_path=".../libraries/SFO" --include_path=".../libraries/SPLL" --include_path=".../libraries/Utilities/rampgen" --include_path="C:/ti/ccs1110/ccs/tools/compiler/ti-cgt-c2000_21.6.0.LTS/include" --define=_TI_EABI_ --define=_DEBUG --define=CLA_DEBUG=1 --define=F28x_DEVICE --define=CPU1 --define=LARGE_MODEL --define=_FLASH --define=BUCK_CONTROL_RUNNING_ON_CPU -g --float_operations_allowed=32 --diag_suppress=10063 --diag_suppress=173 --diag_warning=225 --diag_wrap=off --display_error_number --quiet --abi=eabi --cla_signed_compare_workaround=on -k --asm_listing --include_path=".../RELEASE/syscfg"

  • 0
    TI__Guru 50611 points

    Lucas,

    It looks like you are using --opt_for_speed=5

    Please take a look at the compiler document on details optimization for speed.

    https://www.ti.com/lit/pdf/SPRU514Y 

    A fast branch (BF) instruction is generated by default when the --opt_for_speed option is used. When --
    opt_for_speed is not used, the compiler generates a BF instruction only when the condition code is one of
    NEQ, EQ, NTC and TC. The reason is that BF with these condition codes can be optimized to SBF. There
    is a code size penalty to use BF instruction when the condition code is NOT one of NEQ, EQ, NTC and
    TC. (Fast branch instructions are also generated for functions with the ramfunc function attribute.)

     

    Can you try removing the --opt_for_speed=5 in the compiler command if it helps you?

    Regards, Santosh

  • 0
    Intellectual 671 points

    Hi Santosh,

    Thanks for your reply. Unfortunatelly I didn't get an email as usual, so didn't see it till now. I've managed to resolve the problem by simply re-arranging the code, which is quite unsatisfactory. However, I don't have an easy way of replicating right now, as the code has already changed substantially. 

    I did, however, read the optimization for speed section in the compiler document, as you suggested. I'll lower the level, as it looks risky to have it at maximum.

    Cheers,

    Lucas

  • +1 in reply to Lucas Sinopoli
    TI__Guru 50611 points

    Hi Lucas,

    I am glad you are able to resolve the issue.

    Regards, Santosh