• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 52 subscribers
  • Views 4482 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.

Strict Ansi C language mode for MISRA does not recognize extended C key words.

jason wiseman
Intellectual 675 points

Hello,

I am using CCS4.2 with 6.0.2 Codegen tools.

I am using the MISRA language option which requires the strict Ansi C language option.

I get the following errors when I compile on extended C keywords and a few other symbols. These errors do not occur with relaxed Ansi.

C Code Error

extern cregister volatile unsigned int IFR;  "../include/DSP2802x_Device.h", line 51: error: omission of explicit type is nonstandard ("int" assumed)     "../include/DSP2802x_Device.h", line 51: error: expected a ";"

extern cregister volatile unsigned int IER; Same as above

 

typedef interrupt void(*PINT)(void); "..\include\DSP2802x_PieVect.h", line 26: error: omission of explicit type is nonstandard ("int" assumed)

"..\include\DSP2802x_PieVect.h", line 26: error: expected a ";"

 

interrupt void WatchdogISR(void) Same as above +

"../pwm_int.c", line 145: error: invalid combination of type specifiers

 

 Is there something I am misunderstanding, or is there an issue with Strict Ansi Lanuage mode and the keywords 'interrupt' and 'cregister' ?

 

  • 0
    TI__Guru**** 249860 points

    MISRA rules require that you build in strict ANSI mode.  This means it is an error to use any feature not specified in the ANSI standard.  In your case, these features are the keywords cregister and interrupt.  The net effect is you cannot use interrupt and cregister and, at the same time, conform to MISRA.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Intellectual 675 points

    Georgem,

    I found this in the compiler manual spru514d.pdf :

    6.5.4 The interrupt Keyword

    ....

    "Use the alternate keyword, __interrupt, if you are writing code for strict ANSI/ISO mode (using the

    --strict_ansi compiler option)."

     

    Adding the __ in front of  "interrupt" prevents the compiler errors from occuring, but I'm not sure what this does exactly. Nothing was mentioned about this in the cregister section, but it also seems to make the error go away. 

     

    Is this correct?

  • 0 in reply to jason wiseman
    TI__Guru* 84285 points

    The point of --strict_ansi (-ps, "strict ANSI" mode) is that the compiler is supposed to accept all "strictly conforming" programs.  For instance, the following is a strictly conforming program:

    int main() { int interrupt = 5; return 0; }

    There is nothing special about the identifier "interrupt" in standard C, so the compiler must accept this program in "strict ANSI" mode.  However, in the default mode, TI compilers treat the identifier "interrupt" as a keyword, so TI compilers will reject the above program with a syntax error.  You must use --strict_ansi to get the compiler to accept the above program.

    There is still a need, even in strict ANSI mode, to allow TI extensions such as being able to specify interrupt functions, so the TI compilers additionally provide the __interrupt keyword, which does the same thing.  Strictly conforming programs may not use this identifier, so the compiler is free to accept the __interrupt keyword even in "strict ANSI" mode.  You should use __interrupt everywhere you are currently using interrupt, and you will not need to worry about whether you are using "strict ANSI" mode.

    There is also a __cregister keyword; the fact that this is not documented is an error in the documentation.  I've submitted SDSCM00042611 to track this issue.

    All header files should use __cregister and __interrupt instead of cregister and interrupt to avoid problems with "strict ANSI" mode.  Does the header file DSP2802x_Device.h come from a TI-produced package?

  • 0 in reply to Archaeologist
    Intellectual 675 points

    Yes, the header file DSP2802x_Device.h was from the TI produced package:

     

    I'm also having some problems with the following inline assembly instructions from the same file. In relaxed ansi I can add them as needed in my C code.

    In the assembly version of a particular C file using "EALLOW;" (I always keep the interlisted C/asm files for reference) I can see the "EALLOW;" becomes a "LCR       #_asm" 

    With relaxed ANSI it gets inserted inline as "EALLOW" in the assembly version.

     

    The statements of interest:

    #define  EINT   asm(" clrc INTM")

    #define  DINT   asm(" setc INTM")

    #define  ERTM   asm(" clrc DBGM")

    #define  DRTM   asm(" setc DBGM")

    #define  EALLOW asm(" EALLOW")

    #define  EDIS   asm(" EDIS")

    #define  ESTOP0 asm(" ESTOP0")

  • 0 in reply to jason wiseman
    Intellectual 675 points

    It looks like the double underscore also applies to asm(" ") functions as well.

     

    Thanks !

  • 0 in reply to jason wiseman
    TI__Guru* 84285 points

    Use __asm.  In "strict ANSI" mode, asm is not recognized as a keyword, so what you get looks like this:

    void func()
{
   asm(" EALLOW");
}

    and the compiler sees this as a call to an unprototyped function named "asm" which takes a string as an argument.  The compiler cannot emit a warning about this because the user might very well have created such a function...