Click here to Skip to main content
15,881,760 members
Please Sign up or sign in to vote.
0.00/5 (No votes)
See more:
I am working on arm xscale embedded system. Here I am seeing a incorrect branch is getting executed in switch case.

Below is my switch case looks like,

C++
switch(val)
{
  case 0:
         ....
         break;
  case 1:
         ....
         break;
  case 2:
         .....
         break;
  case 3:
         .....
         break;
  default:
         printf("case value = %d\r\n" ,val);
         break;
}


In the above case , I am receiving value as zero i.e val = 0.
But the cpu branches to default case, where i have printed the value, which is showing zero only. "case value = 0". Looks very strange.
Break statements are proper. "val" is a signed int(no problem there).
I have tried to understand the assembly generated for this switch case block, but I don't understand the logic used in the generated assembly instructions.
I don't think wrong assembly was generated by assembler(may be I don't know).Is there any possiblity of hardware bug which will create this kind of problem like issues in MMU or TLB , instruction cache parity issues or any other thing ?How to debug this issue?
Posted
Updated 21-Oct-15 1:43am
v2
Comments
CPallini 21-Oct-15 7:46am    
As suggested, disable all the optimizations. Moreover post here the generated assembly code.

1 solution

A hardware bug is very unlikely. It may be a compiler bug. You may put another print statement in front of the switch statement to ensure that the value is zero there.

To confirm a compiler bug the generated assembler code must be checked. You may edit your question and add that. Maybe someone here can verify it.

Another option would be disabling all compiler optimisations. If the behaviour changes it indicates a compiler bug.

Another interesting test would be using another variable which is initialised with the value and passing that to the switch statement.
 
Share this answer
 
Comments
CPallini 21-Oct-15 7:46am    
5
chandrAN2& 26-Oct-15 9:06am    
This problem is not always happening. Once in a while(once or twice per day) only this is happening.
It it is a compiler bug, then the issue should occur always.
This only confusing me, that's why I suspect hardware malfunction may results in this kind of behaviour.

One more doubt is how we strongly believe that hardware problem is unlikely.
Why we trust the processor or related hardware 100%(interested in knowing the answer).
Jochen Arndt 26-Oct-15 9:33am    
That this is not always happening is new (not stated in the original question) and may indicate a hardware problem (a hardware bug is still unlikely).

Possible hardware problems:
- Low voltage
- Bad soldering ("cold joint")
- Bad memory (RAM)
- Other defective components (including processor)
Components are checked by the manufacturer. But integrated circuits are sensitive to ESD (Electro Static Discharge) and improper handling can result in a behaviour as described.

If you have another system I would try that.

Similar problems will also occur when multiple threads modify variables withput proper locking.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)



CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900