Inquiry MISRA C:2012 13.2

Hello.

Polyspace 2018a tool detected MISRA C:2012 13.2 warning at "vulSdAdcCalPositiveModule3" , but I didn't know the reason why polyspace detected it.

Could you explain the reason refering to the below codes?

Is it possible that polyspace tool mis-detect the below three parameters as same?

vulSdAdcCalGainModule3 =  65535.0 / (float)(vulSdAdcCalPositiveModule3 + (0xFFFF - vulSdAdcCalNegativeModule3));

Thank you.

Sincerely yours.

SY Seo

[Walter Roberson]

Are vulSdAdcCalPositiveModule3 or vulSdAdcCalNegativeModule3 volatile ?

A copy of the error message would help.

Answer 1

[Seungyeop]

Thank you for your reply.

I checked that these are volatile values, that's why MISRA-C 2012 13.2 error occurred.

I have the other questions as the below.

1. Could you explain the reason why it's warning when accessing multiple volatile values?
2. Would you mind providing the best solution to avoid this warning? Is it one of the solution to stare volatile value at local variables?

For example,

<Before>

vulSdAdcCalGainModule3 =  65535.0 / (float)(vulSdAdcCalPositiveModule3 + (0xFFFF - vulSdAdcCalNegativeModule3));

<After>

a = vulSdAdcCalPositiveModule3;    //Store at non-volatile local variable
b = vulSdAdcCalNegativeModule3;   //Store at non-volatile local variable
vulSdAdcCalGainModule3 =  65535.0 / (float)(a + (0xFFFF - b));

Thank you.

Sincerely yours.

SY Seo

[Walter Roberson]

MISRA has to assume that volatile variables might be connected to hardware latches, such that the action of reading from one of them or writing to one of them might change another one. This is mediated by the rules in C and C++ about "sequence points", which are rules that most people get wrong.

There are no sequence points between evaluation of the operands for addition; see https://en.wikipedia.org/wiki/Sequence_point so when A and B are both volatile, A + B could result in either A being fetched and then B being fetched, or in B being fetched and then A getting fetched. With hardware latching, accessing A might change B or accessing B might change A, or both might be true. Therefore in the presense of volatile variables, C does not define the result of A + B, whether it is (fetch A)(fetch B)(add them) or (fetch B)(fetch A)(add them). MISRA detects this and complains.

Storing into local variables is a good work-around -- just be sure to document why the order of access is what it is -- why you did not assign to b before a, whether that is what is needed for your hardware behavior, or whether hardware is simply not a factor for this purpose, or whether they have somehow been latched in a way that the access order does not matter until your code issues a trigger event.