How to find issues related to Data consistency in an Embedded C code base? -

let me explain mean data consistency issue. take following scenario example

uint16 x,y; x=0x01ff; y=x; 

clearly, these variables 16 bit if 8 bit cpu used code, read or write operations not atomic. thereby interrupt can occur in between , change value.this 1 situation might lead data inconsistency.

here's example,

if(x>7) //x global variable {  switch(x)         {            case 8://do                    break;            case 10://do                    break;            default: //do default         } } 

in above excerpt code, if interrupt changing value of x 8 5 after if statement before switch statement,we end in default case, instead of case 8.

please note, i'm looking ways detect such scenarios (but not solutions)

are there tools can detect such issues in embedded c?

it possible static analysis tool context (thread/interrupt) aware determine use of shared data, , such tool recognise specific mechanisms protect such data (or lack thereof).

one such tool polyspace code prover; expensive , complex, , lot more besides described above. quote (elided) whitepaper here:

with abstract interpretation following program elements interpreted in new ways:

[...]

• any global shared data may change @ time in multitask program, except when protection mechanisms, such memory locks or critical sections, have been applied

[...]

it may have improved in long time since used it, 1 issue had worked on lock-access-unlock idiom, specified tool lock/unlock calls or macros were. problem c++ project worked on used smarter method locking object (mutex, scheduler-lock or interrupt disable example) locked on instantiation (in constructor) , unlocked in destructor unlocked automatically when object went out of scope (a lock scope idiom). meant unlock implicit , invisible polyspace. @ least identify shared data.

another issue tool must specify thread , interrupt entry points concurrency analysis, , in case these private-virtual functions in task , interrupt classes, again making them invisible polyspace. solved conditionally making entry-points public abstract analysis only, meant code being tested not have exact semantics of code run.

of course these non-problems c code, , in experience polyspace more applied c in case; far less writing code in style suit tool rather tool working existing code-base.