FM4 Workaround for preventing MISRA C

[developerR]

I am working with the FM4 S6E2CC PIONEER KIT.  I have tried multiple examples from the sdk compiled and loaded them via my j-link and SES. 

But they all hang on  the FM4_CRG->SCM_CTL read during clock setup

// Workaround for preventing MISRA C:1998 Rule 46 (MISRA C:2004 Rule 12.2)
// violations:
// "Unordered reads and writes to or from same location" and
// "Unordered accesses to a volatile location"
do
{
u8IoRegisterRead = (FM4_CRG->SCM_CTL & 0xE0u);
}while ((FM4_CRG->SCM_STR & 0xE0u) != u8IoRegisterRead);
#endif // (CLOCK_SETUP)

Anyone have any ideas how to overcome ?

regards

developerR

[zzz_3221081]

I would say this has nothing to do with Misra.
Misra is just a self-imposed coding style rule set, and has no direct influence on the compiler or the executable.
And, leaving out my personal opinion about Misra here.

The respective rule says :
The value of an expression shall be the same under any order of evaluation that the standard permits.
In the presented case, two different SCM registers are read, masked with 0xE0, and compared.
From the code, I cannot see why this two reads from peripheral registers require a specific order here, you might need to consult the hardware manual. (I don' use / have a  FM4 S6E2CC MCU).

> But they all hang on  the FM4_CRG->SCM_CTL read during clock setup

You probably need to conside the context.
Such busy-waits for register flags are usually done after enabling clock tree features.
Check the assumptions in the code with your hardware.
Does the quartz frequency match the expected one in the code ?
Is there even a quartz populated ?
Are the PLL settings valid and allowed for this MCU ?

Often, SDKs are written for a family/variety of evaluation boards, and you manually need to specify the proper variant, or change a preset default.
Usually in the form of a single define - either in a header or in the IDE's project settings.

[developerR]

Hi zzz

thanks for engaging with me on this topic. The MIRSA suggestion comes from Cypress so I accepted it in good faith. Not sure if its because its a volatile or flash location that requires the ordered treatment. What I am thinking is that a read test immediately after a write probably warrants a tiny delay? Your points on the PLL etc I have checked up on.

regards and thanks again  

[zzz_3221081]

> The MIRSA suggestion comes from Cypress so I accepted it in good faith.

Some commercial customers use/enforce MISRA conformance inside their organisation, and thus many vendor libs/SDKs are written to conform.
I think the mentioned comment in the SDK source was misleading. Supposedly a previous version was not conformant, and caused the MISRA checker to complain about that statement. 
A MISRA violation is not a bug, though.

>  What I am thinking is that a read test immediately after a write probably warrants a tiny delay?

At least from the source code shown, I cannot see a write access.
One needs to keep in mind that access to peripheral registers is usally RMW (read/modify/write), and ver often the sequence matters.

However, from the source alone, there is no obvious interdependence between the SCM_CTL and the SCM_STR visible. The involved bit operation suggests that bits 5..7 of both register are supposed to match.
Just in case, I suggest you can switch to assembler instruction mode and singlestep through the relevant code. Perhaps this helps.
Just keep in mind that debuggers can be obtrusive, and thus can change the program flow. An example are reads from peripheral registers that affect flags in other peripheral registers (which is often the case with receive interrupts).