Showing results for 
Show  only  | Search instead for 
Did you mean: 
Registered: ‎03-28-2020

MicroBlaze Exception (00100 = Data bus error exception) debug approach


could you please give me a hint on how to best use the VITIS & VIVADO to detect the reason for a Data bus error exception. The issue reliably comes up in the "release" build, but is not present in the "debug" build. 


I could narrow down by disabling code segments, the area it happens in. This indicates it is the communication between the  Xilinx AXI_QuadSPI, as this is the only AXI component that actively gets called from that segment. Sure other AXI components do their job in the background (memory, cache, interrupts, timers). But I am ruling them out as this are stable in all other code segments, which are larger and run longer.

In my case I had to implement the communication to the AXI_QSPI using the lowlevel driver interface, as the component requires direct control of the chip select. By that I am able to fill the FIFOs much faster, than the XILINX spi driver would do. Therefore I suspect back pressure on the AXI is causing the exception.

Now the question:

- How to best us the VIVADO / VITIS tools to debug an AXI bus exception? 

- Is it possible to trigger a trace of the AXI-BUS and the program when an exeption occuers? Any document or that gives me a first step into it?


I think about using a ILA to monitor the AXI bus and the SPI component. In case the exceptions kicks in, I switch a GPIO, to trigger the ILA. Is there a better way?


Tags (2)
0 Kudos
2 Replies
Registered: ‎05-21-2015


Most of the bus *exceptions* I've dealt with are associated with attempting to address a non-existent peripheral.  In this case, I'd try testing each individual peripherals address to see if they could be used successfully.

The AXI Quad SPI core is different.  To see why, check out your ${INSTALL}/data/ip/xilinx/axi_quad_spi_v*/hdl directory for the AXI quad SPI simulation component.  If you look through this component, you'll see that BRESP and RRESP, the AXI error returns, are set based upon an IP2Bus_Error.

Basically, several Xilinx cores use an IPIF processor to handle their AXI transactions.  It's notoriously slow as molassas, but it usually works well enough.  This core simplifies the AXI transaction to something easier for the core to handle--something that can also be non-clock synchronous, so that it can cross clock domains.  The Quad SPI core then provides responses on this IP interface, which are then returned to AXI responses.

On the IP interface, there's an IP2Bus_Error flag.  This flag will be set if there's an underlying protocol error of some type--such as attempting to read when there's nothing there to be read, or attempting to write when the write is already busy--which is probably what's going on in your case.

My guess is that you'll have to undo your software changes, and that if you really want speed from a SPI port, you'll need to build that speed yourself from your own custom IP component.


Registered: ‎03-28-2020

Hi Dan,

thanks again for your high quality feedback. Based on your explanation here and on the other threat I changed direction of search. Instead of focusing on the COM on the AXI between CPU and SPI, I checked again if I do something wrong with the SPI.

It seems that the TX-FIFO for the QSPI is not meant to be filled while the SPI is active. So I have to:

  1. inhibit the SPI
  2. fill the TX-FIFO
  3. activate the SPI
  4. wait for TX_FIFO empty
  5. take data from RX_FIFO,
  6. inhibit SPI again (just in case).

I had hopped that the FIFO  allows me to do part of the transfers (CPU -> SPI -> Extern) in parallel.

Thanks again and yes I have to start my own SPI block soon.


0 Kudos