• Locked Locked
  • Replies 8 replies
  • Subscribers 53 subscribers
  • Views 1143 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.

C2000 CGT 6.1.0 MISRA 10.1

Lori Heustess
Guru* 93800 points

Other Parts Discussed in Thread: CONTROLSUITE

Platform: C2000

Codegen: 6.1.0

I have the following, where DIVSEL is a bitfield with the type Uint16 

   if (SysCtrlRegs.PLLSTS.bit.DIVSEL != 0)    // line 151
   {
       EALLOW;
       SysCtrlRegs.PLLSTS.bit.DIVSEL = 0;    // line 154
       EDIS;
   }


Both line 151 and 154 issue the same MISRA warnings (below) but I am not able to get line 151 to go away.

I've tried using a U suffix for unsigned ( 0U ) and I've also tried casting to Uint16 (i.e. (Uint16)0   )

Both solutions remove the error for the assignment on line 154. Neither remove the warning for the comparison on line 151.

Is there something I'm missing?

Misra warnings:

"C:/ti/controlSUITE/device_support/f2833x/v133/DSP2833x_common/source/DSP2833x_SysCtrl.c", line 151: warning:
          (MISRA-C:2004 10.1/R) The value of an expression of integer type
          shall not be implicitly converted to a different underlying type if
          it is not a conversion to a wider integer type of the same signedness
     if (SysCtrlRegs.PLLSTS.bit.DIVSEL != 0)
                                          ^

"C:/ti/controlSUITE/device_support/f2833x/v133/DSP2833x_common/source/DSP2833x_SysCtrl.c", line 154: warning:
          (MISRA-C:2004 10.1/R) The value of an expression of integer type
          shall not be implicitly converted to a different underlying type if
          it is not a conversion to a wider integer type of the same signedness
         SysCtrlRegs.PLLSTS.bit.DIVSEL = 0;
                                         ^

  • TI__Guru* 93800 points

    As a follow-on the same occurs if the value  being compared/assigned is a variable of type Uint16 instead of a constant.  That is the comparison I can't fix, but the assignment I can.

    Uint16 value;

    ....

       if (SysCtrlRegs.PLLSTS.bit.DIVSEL != value )    // <- warning
       {
           EALLOW;
           SysCtrlRegs.PLLSTS.bit.DIVSEL =  value;         // <- no warning
           EDIS;
       }

  • in reply to Lori Heustess
    Mastermind 6240 points

    Lori,

    See the last answer in this topic (http://stackoverflow.com/questions/10582523/how-are-integer-types-converted-implicitly), thwy suggest a casting solution. Is it possible to try the same in your code?

    Other possibility is that it's another bug on the Misra checking of TI's compiler like the one mentioned here http://e2e.ti.com/support/development_tools/compiler/f/343/t/144535.aspx

    Regards

  • in reply to Johannes
    TI__Guru**** 253380 points

    The answer I like best is (written as pseudo-code) ...

    if (bitfield) { bitfield = 0u; }

    This also works ...

    if ((int16) bitfield != 0) { bitfield = 0u; }

    What's going on?  The operands of a C operator like != are subject to the usual arithmetic conversions.  Search on that for all the details.  In this case, it means both operands need to be of type int.  According to MISRA, implicitly converting the bitfield to int is bad.  One solution is to make the conversion to int explicit.  Another solution, which I prefer, is to avoid the problem != operator altogether.

    The assignment is different, because the usual arithmetic conversions do not apply.  The constant 0 has the type signed int.   The problem there is implicitly converting it to unsigned int.  As you discovered, the fix is to make the 0 explicitly unsigned.    

    Thanks and regards,

    -George  

  • in reply to George Mock
    TI__Guru* 93800 points

    Sorry for the long delay - too many other things on my plate.  I hope to get back to this tomorrow.

  • in reply to Lori Heustess
    TI__Guru* 93800 points

    After trying a few things I am thinking this is a bug. 

    It seems I have to move the constant first - but I think that's another rule.

    The following will all trigger MISRA 10.1

        if(adcTest->useInternalInput == 1){
        if(adcTest->useInternalInput == 1U){
        if(adcTest->useInternalInput == (Uint16)1){
        if(adcTest->useInternalInput == (Unsigned int)1){


    The following works, but I would think it should still trigger MISRA 10.1 since the constant is being implicitly converted:
        if(1 == adcTest->useInternalInput){

    I think the following would be a better solution:

        if(1U == adcTest->useInternalInput){


  • in reply to Lori Heustess
    TI__Guru* 93800 points

    Thoughts?  Should I file a CQ?

  • in reply to Lori Heustess
    TI__Guru**** 253380 points

    Lori Heustess said:

    The following will all trigger MISRA 10.1

        if(adcTest->useInternalInput == 1){
        if(adcTest->useInternalInput == 1U){
        if(adcTest->useInternalInput == (Uint16)1){
        if(adcTest->useInternalInput == (Unsigned int)1){

    I presume useInternalInput is a bit field.  If so, it makes sense for 10.1 to be emitted in all these cases.

    Lori Heustess said:
    The following works, but I would think it should still trigger MISRA 10.1 since the constant is being implicitly converted:
        if(1 == adcTest->useInternalInput)

    I agree.  This seems like a compiler bug.  Please file a CQ.

    Lori Heustess said:
    I think the following would be a better solution:

        if(1U == adcTest->useInternalInput){

    I still favor the solutions I wrote in my post on August 16.

    Thanks and regards,

    -George