+- MISRA Discussion Forums (https://forum.misra.org.uk)
+-- Forum: MISRA C (https://forum.misra.org.uk/forumdisplay.php?fid=4)
+--- Forum: MISRA-C: 2004 rules (https://forum.misra.org.uk/forumdisplay.php?fid=17)
+---- Forum: 6.11 Pointer Type Conversions (https://forum.misra.org.uk/forumdisplay.php?fid=38)
+---- Thread: Rule 11.3 Access to registers or memory (/showthread.php?tid=1042)
Rule 11.3 Access to registers or memory - barbara.seyfarth - 27-03-2014
A cast should not be performed between a pointer type and an integral type, this casts from type "unsigned int" to "uint32_t volatile *" (MISRA C 2004 rule 11.3)
In two cases this error occurs on my system (ARM Cortex M3 with IAR workbench and MISRA check from IAR):
1. Access to registers.
2. Access to RAM (during a cyclic RAM test).
Is there any way conform to MISRA C2004 for the following code?
Code:
register uint32_t address; /* during the critical section no RAM access other than the test access may occur */
register uint32_t pattern;
...
*(volatile uint32_t *)address = pattern;Re: Rule 11.3 Access to registers or memory - barbara.seyfarth - 28-03-2014
Another solution is, to use the following code. But then I get a violation of MISRA C2004 rule 17.4 Pointer arithmetic should not be used.
Code:
register uint32_t *address = ANY_RAM_ADDRESS;
register uint32_t pattern = ANY_PATTERN;
*(volatile uint32_t *)address = pattern;
address += 1; /* violating rule 17.4 */So I tried to eliminate this error... and came back to rule 11.3:
Code:
address = (uint32_t)p_memory;
address += sizeof(uint32_t);
p_memory = (uint32_t *)address;Perhaps I should not ask "how to eliminate the violation" but "which violation is the least problematic violation"?
Re: Rule 11.3 Access to registers or memory - misra-c - 11-04-2014
The MISRA-C Guidelines recognise that, in some situations, it is unreasonable or even impossible to comply with a coding rule and that it is necessary to deviate. Your example of casting an integer to a pointer is a situation where a deviation would be reasonable.
It is important that such deviations are properly recorded and authorized. The deviation procedure should be formalized within the software development process. No process is imposed by MISRA C because methods used will vary between organizations, for example:
- * The physical methods used to raise, review and approve a deviation;
* The degree of review and evidence required, which may vary according to the guideline in question, before a deviation can be approved.
- * The guideline being deviated;
* The circumstances in which the deviation is permitted;
* Justification for the deviation, including an assessment of the risks associating with deviating compared with other possibilities;
* Demonstration of how safety is assured, for example a proof that an unsafe condition cannot occur, together with any additional reviews or tests that are required;
* Potential consequences of the deviation and any mitigating actions that have been taken.