• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 31 subscribers
  • Views 2646 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

HALCOGEN: Halcogen MISRA-C compliance

David M. Alter
Guru 61235 points
Part Number: HALCOGEN

Hello Hercules Team,

A user is trying to check MISRA-C compliance of Halcogen 4.06.00 generated code using CCS v7.  There are many warnings.  This is easy to duplicate.  I created a new RM42 project using Halcogen and just saved the generated files.  I then created a new empty CCS v7 project that uses ARM compiler 16.9.3.LTS.  I enabled "ALL" MISRA checks for the CCS project.  Just building a single source file (adc.c), I get dozens of warnings.  I then changed to only "REQUIRED" MISRA checks.  I get far fewer warnings, but do still have warnings. Some of the warnings pertain to include files coming from the compiler.  But others come from the Halcogen generated source file (adc.c) itself.  For example:

ptr++;

"../source/adc.c", line 446: warning #1476-D: (MISRA-C:2004 17.4/R) Array indexing shall be the only allowed form of pointer arithmetic

CCS is supposed to be checking for compliance with MISRA-C:2004, which is the same version that Halcogen is supposed to be compliant with.  I saw several other older posts on this subject to which responses suggested that Halcogen compliance was evaluated using a tool from LDRA.  But, I'd think the example I give above is pretty straightforward and would be a violation using any tool, wouldn't it be?

How can users have confidence in Halcogen MISRA compliance if it cannot pass our own CCS check?

Any other suggestions/comments here?

--------

Update: I see the ptr++ code lines seem to have a waiver cited in the code comments:

"../source/adc.c", line 446: warning #1476-D: (MISRA-C:2004 17.4/R) Array indexing shall be the only allowed form of pointer arithmetic

Fair enough on that.  There are still other warnings though that I cannot make sense out of.  For example:

return adc->EVTIN;

"../source/adc.c", line 856: warning #1423-D: (MISRA-C:2004 17.6/R) The address of an object with automatic storage shall not be assigned to another object that may persist after the first object has ceased to exist ("adc")


I'm not seeing where the address of an automatic var is being assigned to a persistant object.  The code line is returning a value to the calling function.

--------

Thanks and regards,

David

  • 0
    TI__Guru 59540 points
    Hello David,

    MISRA-C is a bit of a strange standard in that there are openings for adaptation for each project. i.e., certain rules can be included or excluded. I am not certain that CCS has the capability to make these customizations in order to prevent the warnings. Full scale implementations of MISRA-C do include this configurability and are generally more widely accepted for their accuracy and efficiency. As noted, LDRA is one of these types of tools with a level of usability far and above to the CCS implementation as far as I am aware.

    Prathap has done a good job of explaining why, for a SIL or ASIL rated project, it isn't recommended to use the CCS implementation of MISRA-C checking. In addition, he has done a fairly good job of explaining why some tools may return error messages or warnings since the Halcogen team adopted a specific set of rules and excluded some within the guidelines and acceptable use of the MISRA-C tool. I have copied our current HalcoGen owner in case there are additional questions of need for additional documentation.

    Here is a link to the post where Prathap has answered the same question you have provided: e2e.ti.com/.../589595
  • 0 in reply to Chuck Davenport
    TI__Guru 61235 points

    Chuck,

    Thank you for the response.  I'm still struggling with this however.  I tried digging into just a couple of the warnings.  Some of the supposed violations have comments stating "Approved" in the code source.  Others do not though.  The MISRA-C:2004 17.6/R violation I cited previously appears to be a compiler bug (in that the warning should not occur).  But there are other warnings that appear legitimate.  For example, there are global var declarations with static qualifiers (meaning, scope is limited to that source file) that are accessed in only a single function.  MISRA-C:2004 8.7/R violation occurs:

      (MISRA-C:2004 8.7/R) Objects shall be defined at block scope if they are only accessed from within a single function

    The violation seems valid, and there is no comment in the source about this being an approved ignor.

    In Prathap's post that you cited, he says he has a document with the details of how the rules have been handled by Halcogen, which he offered to share with the poster.  Could I get that document?

    Thank you,

    David

  • 0 in reply to David M. Alter
    TI__Guru 59540 points

    Hi David,

    I understand your concerns. I am copying the current Halcogen owner, Veena, so that she might respond to your concerns and/or send the document Prathap referenced directly via email.

  • 0 in reply to Chuck Davenport
    TI__Mastermind 31525 points

    Hi David,

    Can you let me know which customer is asking for it? I am not sure whether I could share that document in forum. I will check with my manager and get back to you.

    Thanks and Regards,

    Veena

  • 0 in reply to Veena Kamath
    TI__Guru 61235 points

    Venna, Chuck,

    Thank you for the document.  Unfortunately, there are MISRA warnings that cannot be explained away.  I've attached file adc.c, which was generated for a new project using Halcogen 04.06.00.

    6763.adc.c

    When this file is compiled using TI ARM compiler v16.9.3.LTS, I get warnings for the following MISRA rules:

    19.4/R  (3 times) - The document you sent indicates blanket waiver treatment by Halcogen

    20.1/R (1 time) - Code comment indicates waiver approved for 20.2/R.  20.1 and 20.2 are very similar rules, so I'll chalk this up to interpretation differences between the compiler MISRA checking, the LDRA MISRA checking, and the code comment.

    17.4 (2 times) - The document you sent indicates case-by-case waiver treatment by Halcogen

    17.6 (3 times) - This looks to be a compiler bug where the warning is given in error

    8.7 (1 time) - This one I cannot explain away:

    Line 211 declares a static constant with file scope, but it is accessed by only a single function:

    static const uint32 s_adcSelect[1U][3U] =
    {
       ...

    }

    The TI compiler throws the following MISRA warning, and seems justified in doing so:

    "../source/adc.c", line 211: warning #1387-D: (MISRA-C:2004 8.7/R) Objects shall be defined at block scope if they are only accessed from within a single function (variable "s_adcSelect")

    According to the spreadsheet you sent, Halcogen is supposed to treat MISRA-C:2004 8.7/R as mandatory and adhered to in all implementations.

    ***How do we explain this?

    The analysis above was done for just a single source file generated by Halcogen.  I suspect other files will yield similar results.

    Thank you and Regards,

    David

     

  • 0 in reply to David M. Alter
    Guru 92251 points

    David M. Alter said:
    17.6 (3 times) - This looks to be a compiler bug where the warning is given in error

    This might be the same problem as the outstanding bug CODEGEN-1639, for which there is a test case in Bug: MISRA-C Rule 17.6 Misreported by arm compiler. Maybe you should post on the compiler forum to confirm.

    In both cases, the 17.6 warning appears to be triggered by a function de-referencing a field in a structure passed as an argument.

  • 0 in reply to David M. Alter
    TI__Guru 59540 points

    Hi David,

    Just to follow up for completeness on this thread, discussion with the SW team lead to the understanding/statements below.

    The code generated through Halcogen is not 100% MISRA-C compliant. Every effort was made to comply within reason, but, in some cases, drivers would have needed to be re-architected for compliance so the decision was made to accommodate the exception due to resource and effort constraints. An attempt was made in most cases, to add comments and explanation in either the code or the CSP to identify these exceptions; however, there are still some remaining cases where they are not documented.

    As difficult as this is to both TI and our customers, it is a reality of where the SW development stands. We will continue to evaluate the impact of this and identify any way that the collateral surrounding the SW can be improved to provide full and complete explanation of each non-compliance but there are currently no confirmed plans for specific updates.