cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
rfried
Visitor
Visitor
252 Views
Registered: ‎07-30-2020

Microblaze code hangs when using "switch"

Using Microblaze 64bit as a co-processor on Versal platform. Toolchain 2020.2.1

Very strange behavior, the same functionality, different implementation.

using the "switch" the microblaze just halts and doesn't work anymore.

What could be the reason ?

The following code works:

int a = 4;

if (a == 5)
  foo();
else if (a == 6)
 foo2();
else
  foo3();

 

This doesn't:

 

int a = 4;

switch (a) {
case 5:
  foo();
  break;
case 6:
  foo2();
  break;
default:
  foo3();
}

 

Tags (3)
0 Kudos
2 Replies
abhinayp
Xilinx Employee
Xilinx Employee
123 Views
Registered: ‎07-12-2018

Hi @rfried ,

I found a reference code in the below document, please check if that could help. I see that there is no break used in the code. 

https://www.xilinx.com/support/documentation/sw_manuals/xilinx11/mb_ref_guide.pdf

 

Best Regards
Abhinay PS
------------------------------------------------------------------------------------------------------------------------------
Kindly note- Please mark the Answer as "Accept as solution" if information provided is helpful.
Give kudos to a post which you think is helpful and reply oriented.
-------------------------------------------------------------------------------------------------------------------------------

0 Kudos
dgisselq
Scholar
Scholar
100 Views
Registered: ‎05-21-2015

@abhinayp ,

That's a big document.  What reference design did you find?

As far as I can tell, the OP is following C standard guidelines.  If Microblaze requires special syntax, such as requiring another break or worse requiring one be removed, then this is a bug.

@rfried ,

I've chased bugs all across designs for some time.  I think @abhinayp 's advice so far is a red herring.  I'd offer two possible places to check.  1) Check the disassembly.  There are only so many ways to build a switch/case statement, and chances are it's being done right.  That leaves 2) a potential bus issue.  These are (unfortunately) common problems among user designs.  I'd recommend you place an ILA on the AXI bus going in/out of the chip and look at what's going on.  A bus protocol checker might be useful as well.  Bus hangs are common causes of problems, and subtle timing issues can be a big problem.  (It doesn't help that Xilinx's demonstration designs, built via create and package custom IP, tend to be broken and known generators of bus hangs ...)

Dan

0 Kudos