We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

Showing results for 
Search instead for 
Did you mean: 

Adam Taylor’s MicroZed Chronicles, Part 123: Working out our Peripheral Status

Xilinx Employee
Xilinx Employee
0 0 41.9K


By Adam Taylor



So far on this journey into the Zynq-7000 SoC, we have covered a significant amount of ground and looked at a number of peripherals including simple timers, interrupts and DMA. Some of these peripherals have been within the Zynq SoC’s PS (Processor System) while others have been within the PL (Programmable Logic).


However, there is one point which I have been remiss in not addressing until now and that is how we can tell the status of the peripheral we are using. This is important for a number of reasons—for example, when we first configure and initialize the device, using the returned status gives us confidence that we succeeded. Indeed, if configuration and initialization are not successful, we can use the returned status to help us determine the root cause of the issue. Further, when we are using the peripheral, we can use the status to determine or monitor the health/status of our system and degrade performance gracefully if required.


Throughout this series of articles you will have seen the code structure below several times, when we have initialized a new peripheral:



   Status = XSpi_CfgInitialize(&SpiInstance_MIO,SPI_MIO,SpiConfig_MIO->BaseAddress );

   if (Status != XST_SUCCESS) {

                return XST_FAILURE;




The example above configures an AXI Quad SPI driver, which would be located within the PL of the Zynq SoC. Like many functions provided in the API’s available within the generated BSP, the function returns an integer that corresponds to the status following the function’s execution. We can find out the different status values that the function returns by holding the mouse pointer over the function definition within the SDK as shown below. We can also use this feature to determine arguments and their types required by the function in its function call.





Obtaining function status information within SDK



Once the function description appears within SDK, you can click in the green text area and expand or scroll through the information explaining how to use that function and most importantly, what different types of status are returned.






Status returned from the slave select function




With an understanding of what is returned, we need to determine how we can best use the returned status within our program. The function’s returned status is an integer value. In the simplest case: XST_SUCCESS = 0 and XST_FAILURE = 1. However, within a file called xstatus.h, there are many more values that we can use to determine the status of our peripheral and hence our system.


We can use the returned status to determine if the peripheral is busy or if there is another issue that we need to either investigate during commissioning or report during system operation.


If you look in the xstatus.h file within SDK, you will see that there are status values for many peripherals we have used on this journey from simple things like I2C and SPI to the GMAC, DMA, and many others.


Over the next weeks we are going to be getting the Avnet Embedded Vision Kit Camera up and running and we will be using the reported status often to ensure that we have the system up and running as we want.


I should also add, for those developing MicroBlaze systems the same approach holds true.



The code is available on Github as always.


If you want E book or hardback versions of previous MicroZed chronicle blogs, you can get them below.




  • First Year E Book here
  • First Year Hardback here.




 MicroZed Chronicles hardcopy.jpg



  • Second Year E Book here
  • Second Year Hardback here




 MicroZed Chronicles Second Year.jpg



You also can find links to all the previous MicroZed Chronicles blogs on my own Web site, here.





Tags (1)