Arm Xscale incorrect branch

Question

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 21-Oct-15 1:15am

chandrAN2&

Updated 21-Oct-15 1:43am

CPallini

v2

Add a Solution

Comments

CPallini 21-Oct-15 7:46am

As suggested, disable all the optimizations. Moreover post here the generated assembly code.

1 solution

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

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

Jochen Arndt · Answer 1 · 2015-10-21T01:33:00

Solution 1

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.

Posted 21-Oct-15 1:33am

Jochen Arndt

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.