Compiler/TMS320F28377S: Compiler does not generate SPM #0 before unsigned multiplication

Part Number: TMS320F28377S

Tool/software: TI C/C++ Compiler

Hello there,

We've encountered a situation where the result of the unsigned multiplication was twice as expected and upon investigation we've noticed that the ST0.PM field was 000b at the time instead of 001b. Trying to find out what's going on I stumbled upon the https://e2e.ti.com/support/tools/ccs/f/81/t/116897?C2000-C-C-CODE-GENERATION-TOOLS-COMPILER-BUG-  post which describes a similar situation to ours.

Upon reading this post I generated assembly listing for all modules and searching through them found that the compiler does generate the SPM #0 assembly instruction in other modules but not in the module where we found the issue with multiplications. What makes the compiler add the SPM #0 assembly instruction? All modules are compiled with the same compiler options:

"C:/ti/CodeGenerationTool/___ti-cgt-c2000_18.1.3.LTS/bin/cl2000" --cmd_file="C:/work/f4t/software/App/FEX4K/Make/ccs/../build_options.cmd"  -v28 -ml -mt --cla_support=cla1 --float_support=fpu32 --tmu_support=tmu0 --vcu_support=vcu2 -Ooff --opt_for_speed=0 --fp_mode=relaxed --fp_reassoc=off --include_path="C:/ti/CodeGenerationTool/___ti-cgt-c2000_18.1.3.LTS/include" --include_path="C:/work/f4t/software/App/FEX4K/Inc"  --advice:performance=all --define="NDEBUG" --define="__SYSMEM_SIZE" --define="_FLASH" --define="CPU1" --define="LARGE_MODEL" --define="_16BIT_ARCHITECTURE" --define="FPU_SUPPORT" --define="ccs_c2k" --symdebug:none --float_operations_allowed=32 --printf_support=nofloat --diag_wrap=off --display_error_number --issue_remarks --quiet --obj_directory="C:/work/f4t/software/App/FEX4K/Bin/Obj" --gen_func_info_listing --preproc_with_compile --preproc_dependency="C:/work/f4t/software/App/FEX4K/Bin/pp/AcQualify/AcQualify.d_raw"  "C:/work/f4t/software/AcQualify/Src/AcQualify.c"

but in one module the SPM #0 assembly instruction not inserted before the unsigned multiplication. The build_options.cmd file is empty.

The function where we observed this behavior is very simple:

static uint32 ConvertRmsToLocalBound( uint16 RmsBound,  uint16 Scale )
{
    volatile uint32 ConvertedBound = (uint32)RmsBound;

    ConvertedBound <<= MDL_ADC_PRECISION_SFT; // shift by 10
    ConvertedBound  /= Scale;

    ConvertedBound = ( ConvertedBound * ConvertedBound );

    ConvertedBound = ( ConvertedBound  * (uint32)NUM_OF_SAMPLES_PER_HALF_CYCLE ); // division by 22

    return( (uint32)ConvertedBound );
}

We're using uCOSII as RTOS and as such all context switching is implemented in assembler. Adding an SPM #0 in the assembly code that performs context switching seems to provide correct multiplication results but the question that still remain is why in most modules the compiler automatically inserts them while in this particular module it does not.

Other questions would be if there are instances where the compiler sets the ST0.PM field to another value and what precautions we need to take to avoid incorrect behavior?

Thanks a lot,

Doru