UPGRADE YOUR BROWSER

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!

Adam Taylor's MicroZed Chronicles Part 38 – Answering a question on Interrupts.

by Xilinx Employee ‎06-23-2014 10:43 AM - edited ‎06-23-2014 10:43 AM (232,571 Views)

By Adam Taylor

 

Now that the Adafruit NeoPixel example has been completed (see my eight previous blog posts, below), we’ll be moving on for a look at operating systems. But first, a short interlude. During the past week I received an interesting question about Part 24 of this blog that discussed communication across the Zynq SoC’s PS/PL (processor system/programmable logic) interface. The particular question related to raising an interrupt to an ARM Cortex-A9 MPCore CPU in the Zynq PS from the PL.

 

Here’s a block diagram of the ARM GIC (Generic Interrupt Controller) within the Zynq SoC’s PS, taken from the Zynq -7000 All Programmable SoC Technical Reference Manual (UG585):

 

 

 Figure 1.jpg

 

 

The diagram above shows that each CPU has a number of shared interrupts from the PL to the PS (16 interrupts) and five private interrupts for each CPU core from the PL. These interrupt sources drive a fast interrupt and a regular interrupt for each CPU core. In this example, I show how to use the private interrupt. However the general concept is the same regardless of interrupt used. For this example, I will be using an EMIO GPIO pin connected via the PL, looped back and connected to the processor’s interrupt pin. A simple software program can then demonstrate how an interrupt from the PL works. Note: The interrupt at the PL/PS interface is active high, not active low.

 

The first stage of this example is to enable the interrupts between the PL and PS and to enable the specific interrupt you wish to use.

 

Figure 2.jpg

 

 

 

The second step is to enable a single-bit GPIO using the EMIO option.

 

 

Figure 3.jpg 

 

 

Both the interrupt and the GPIO pin will now appear on the Zynq PS block within the block diagram. These signals can be then be interconnected, so that we can drive the interrupt from the EMIO within the Zynq PL under software control.

 

Having gotten to this stage, the next step is to regenerate all of the output products for the design and implement the design so that we can export it to the SDK. In turn, this allows us to write the code to test the application.

 

Our test application will trigger an FPGA interrupt when we press the push-button switch on the MicroZed board.

 

Within the SDK, we need to perform the following steps:

 

  1. Declare the following header files: Platform.h, xparameters.h, Xscugic.h, Xil_Exceptions.h and xgpio.h. These header files will provide functions and macros that enable us to generate the example.
  2. Define the generic interrupt controller and GPIO device ID and interrupt numbers along with the FPGA interrupt and pin numbers for the EMIO and push-button switch.
  3. Declare and write a number of required functions:
  • Interrupt controller set up function
  • PGA Interrupt handler, which prints a message
  • GPIO Interrupt handler, which drives the EMIO GPIO to trigger a FPGA interrupt upon a push-button interrupt.

 

The attached code (see attachment below, at the end of this blog post) shows in detail exactly how how I implemented this simple example. However, I think I should explain the way I set up the interrupt for the FPGA in a little more detail.

 

When setting up an interrupt in the Zynq we need to do the following things:

 

  1. Initialize the Interrupt controller.
  2. Connect the exception ID to the associated handler so that when an event occurs it can be run correctly.
  3. Connect the FPGA interrupt to the generic interrupt controller. This requires the pre-defined interrupt ID, the call-back handler (which is defined to identify the source of the interrupt), and the interrupt service routine to be run when the interrupt occurs.
  4. Enable the interrupt on the interrupt controller.
  5. Enable interrupts on the processor.

 

The above flow is required for one interrupt or for many interrupts, with points 3 and 4 repeated for each interrupt required.

 

When I ran this code on my MicroZed and pushed the button, I saw the following response:

 

 

 Figure 4.jpg

 

 

It works.

 

 

Please see the previous entries in this MicroZed series by Adam Taylor:

 

Adam Taylor’s MicroZed Chronicles Part 37: Driving Adafruit RGB NeoPixel LED arrays with MicroZed Part 8

 

Adam Taylor’s MicroZed Chronicles Part 36: Driving Adafruit RGB NeoPixel LED arrays with MicroZed Part 7

 

Adam Taylor’s MicroZed Chronicles Part 35: Driving Adafruit RGB NeoPixel LED arrays with MicroZed Part 6

 

Adam Taylor’s MicroZed Chronicles Part 34: Driving Adafruit RGB NeoPixel LED arrays with MicroZed Part 5

 

Adam Taylor’s MicroZed Chronicles Part 33: Driving Adafruit RGB NeoPixel LED arrays with the Zynq SoC

 

Adam Taylor’s MicroZed Chronicles Part 32: Driving Adafruit RGB NeoPixel LED arrays

 

Adam Taylor’s MicroZed Chronicles Part 31: Systems of Modules, Driving RGB NeoPixel LED arrays

 

 Adam Taylor’s MicroZed Chronicles Part 30: The MicroZed I/O Carrier Card

 

Zynq DMA Part Two – Adam Taylor’s MicroZed Chronicles Part 29

 

The Zynq PS/PL, Part Eight: Zynq DMA – Adam Taylor’s MicroZed Chronicles Part 28  

 

The Zynq PS/PL, Part Seven: Adam Taylor’s MicroZed Chronicles Part 27

 

The Zynq PS/PL, Part Six: Adam Taylor’s MicroZed Chronicles Part 26

 

The Zynq PS/PL, Part Five: Adam Taylor’s MicroZed Chronicles Part 25

 

The Zynq PS/PL, Part Four: Adam Taylor’s MicroZed Chronicles Part 24

 

The Zynq PS/PL, Part Three: Adam Taylor’s MicroZed Chronicles Part 23

 

The Zynq PS/PL, Part Two: Adam Taylor’s MicroZed Chronicles Part 22

 

The Zynq PS/PL, Part One: Adam Taylor’s MicroZed Chronicles Part 21

 

Introduction to the Zynq Triple Timer Counter Part Four: Adam Taylor’s MicroZed Chronicles Part 20

 

Introduction to the Zynq Triple Timer Counter Part Three: Adam Taylor’s MicroZed Chronicles Part 19

 

Introduction to the Zynq Triple Timer Counter Part Two: Adam Taylor’s MicroZed Chronicles Part 18

 

Introduction to the Zynq Triple Timer Counter Part One: Adam Taylor’s MicroZed Chronicles Part 17

 

The Zynq SoC’s Private Watchdog: Adam Taylor’s MicroZed Chronicles Part 16

 

Implementing the Zynq SoC’s Private Timer: Adam Taylor’s MicroZed Chronicles Part 15

 

MicroZed Timers, Clocks and Watchdogs: Adam Taylor’s MicroZed Chronicles Part 14

 

More About MicroZed Interrupts: Adam Taylor’s MicroZed Chronicles Part 13

 

MicroZed Interrupts: Adam Taylor’s MicroZed Chronicles Part 12

 

Using the MicroZed Button for Input: Adam Taylor’s MicroZed Chronicles Part 11

 

Driving the Zynq SoC's GPIO: Adam Taylor’s MicroZed Chronicles Part 10

 

Meet the Zynq MIO: Adam Taylor’s MicroZed Chronicles Part 9

 

MicroZed XADC Software: Adam Taylor’s MicroZed Chronicles Part 8

 

Getting the XADC Running on the MicroZed: Adam Taylor’s MicroZed Chronicles Part 7

 

A Boot Loader for MicroZed. Adam Taylor’s MicroZed Chronicles, Part 6 

 

Figuring out the MicroZed Boot Loader – Adam Taylor’s MicroZed Chronicles, Part 5

 

Running your programs on the MicroZed – Adam Taylor’s MicroZed Chronicles, Part 4

 

Zynq and MicroZed say “Hello World”-- Adam Taylor’s MicroZed Chronicles, Part 3

 

Adam Taylor’s MicroZed Chronicles: Setting the SW Scene

 

Bringing up the Avnet MicroZed with Vivado

 

Comments
by Newbie tmco
on ‎06-24-2014 07:51 PM

It looks nice. Thanks Adam

by Voyager
on ‎07-10-2014 08:25 AM

Hey

 

Very useful article Smiley Happy Thanks a lot for the post.

Just a small question : In the C code attached for this blog post  should we clear the FPGAFabric interrupt at the end of the ISR ? Cause in the handler function all it does is just print a message and write to a GPIO pin

 

Regards

Arvind

by Observer taylo_ap
on ‎07-11-2014 11:50 AM

Arvind,

 

This is a interesting question and perhaps again deserves a blog on its own however, I will try to explain here Smiley Wink

 

The short answer to your question is of course yes interrupts must alsways be cleared to prevent a recurring issue. 

 

However, in this example when the button is pressed, the GPIO ISR sets a EMIO to '1' which is routed through the PL and back to the Zynq fabric interrupt I had preconfigured. This then triggers the fabric ISR which sets the GPIO pin back to 0 which hence clears the interrupt.

 

If you look at all of the peripherals e.g. TTR etc there is a interrupt status register to clear this, when using the fabric in a real world application i would suggest in the AXI memory map you have a Interrupt status register which can be cleared by the Zynq as part of the ISR routine.

 

Sorry for not making this clearer.

 

Adam 

by Observer taylo_ap
on ‎07-11-2014 11:51 AM

tmco

 

Thanks I hope it answered your question 

 

Adam

by Voyager
on ‎01-09-2015 03:11 AM

Hey Adam,

 

Thank you so much for the reply. I totally forgot to get back to this thread and follow up. I understand how the example works. Your explanation was very clear. Thanks a lot.

 

I have one last question :

 

After studying this blog post and reading your article in Xcell Journal [XPLANAT I O N : F P G A 1 0 1 : How to use Interrupts on the Zynq SoC ] ( Great article btw Smiley Happy ) I have realized its easy to use the Interrups via the PS_GPIO module.I was also able to use this in my project.

 

The xgpio.h file provides a nice set of functions to configure the GPIO pin and enable the interrupt on that pin. The XGpioPs_IntrClear() function nicely reads the interupt status register and clears the corresponding pin interrupt bit. Hence since all the API's are so straight forward using interrupts via the PS_GPIO module is very easy. Also when using the Zynq timers the XScuTimer_ClearInterruptStatus provides a similar functionality so handling timer interrupts are also very straight forward.

 

However just out of curiosity I was wondering if I was to accept the interrupt via the Core0_nFIQ or Core0nIRQ , are there similar API's to clear the Interrupt ? The xsugic.h does not provide a direct API to do this.

 

Thanks a lot in advance


Kind Regards

Arvind

by Visitor gelu93
on ‎03-20-2015 05:10 AM

Hi all,

 

Thanks for the post.

 

I've adapted the example to process interrupts from the FPGA via GPIO-EMIO as well as the  IRQ_F2P input. I'd like the PS to be able to process them at a rate of 10 kHz however it only works with rates up to roughly 300 Hz  in both cases. Do you happen to know if I am doing something wrong or if I have hit a hardware limitation?

 

Thank you.

Regards.

by Observer taylo_ap
on ‎03-27-2015 01:31 PM

 

Sorry I just realised I never replied to this question I do apologise. 

 

There is no API to cleear the hardware intrrupt that I am aware of, in my code I clear the signal which generates the interrupt when I receive the interrupt. 

 

If one had a AXI connected peripheral you could write to a register to clear the interrupt as you do in the othercode examples. 

 

I hope this helps and sorry for the delay 

 

Ad 

by Observer taylo_ap
on ‎03-27-2015 01:31 PM

 

gelu93

 

Send me your project and I will take a look for you 

 

Ad 

by Visitor gelu93
on ‎03-31-2015 04:35 PM

Thanks Adam,

I could solve the problem by my own, it was just a hidden "printf" between several lines of ISR code.

Thanks for your posts Smiley Happy

 

by Visitor chaitraprasad
on ‎10-09-2015 08:12 AM

Hi,

 

I ran the above code on Zedboard. But when I press the push button I get 'Push button Interrupt Event' twice instead of getting 'FPGA Interrupt Event' in the second line. What should be done to rectify this?

 

Thanks,

Chaitra

by Newbie 1090477
on ‎01-14-2016 03:48 AM

hi i just started working with zink7000 and i intend to use 3 buttons to generate interrupts in the cpu in order to use hardware and software to change the same registry.

 

"Both the interrupt and the GPIO pin will now appear on the Zynq PS block within the block diagram. These signals can be then be interconnected"

 

When i follow the steps and get to this part, i can't connect this two pins in the Zynq Ps, could you send me a picture of vivado with the block design, so that i can compare and see if i made some mistake in the interpretation of this post.

 

best regards

Filipe

by Newbie 1090477
on ‎01-14-2016 03:55 AM

"Both the interrupt and the GPIO pin will now appear on the Zynq PS block within the block diagram. These signals can be then be interconnected"

 

I'm trying to implement the code and the design of the post but i can't connect this two pins on the Zynq Ps Block, could you send a picture off the block design in Vivado, Just to see if i have mine equal or similar.

 

best regards

by Newbie 1090477
on ‎01-14-2016 03:55 AM

"Both the interrupt and the GPIO pin will now appear on the Zynq PS block within the block diagram. These signals can be then be interconnected"

 

I'm trying to implement the code and the design of the post but i can't connect this two pins on the Zynq Ps Block, could you send a picture off the block design in Vivado, Just to see if i have mine equal or similar.

 

best regards

by Observer taylo_ap
on ‎01-14-2016 12:24 PM

Hi Filipe

 

I think if I understand correctly you will use three buttons to generate three interrupts and take different actions depending upon the interrupt occuring? 

 

The first thing you need to do is declare three EMIO using the method as above, you cannot however connect three interrupts to just one priviate CPU interrupt. The simplest method is to enable the IRQ_F2P[15..0] interrupts which can be accessed by either core of the processor. 

 

To use these we also need to use a concatentate block and connect the outputs from the EMIO to the concatenate block, when you verify your design the number of interrupts will be correctly shown on the block diagram. I have included the simple picture below which should show how to do this 

 

Thanks for reading 

 

Adam 

 

interrupt_question.PNG

by Visitor kmnacheva
on ‎05-06-2016 03:25 AM

Hi Adam,

 

Could you give us more details of how you set up the Vivado design for this example? 

We are still interns and very new to this area. 

by Observer taylo_ap
on ‎05-08-2016 02:26 AM

kmnacheva

 

The answer above your questions shows how I configured the hardware for the application, you can get the source code here 

 

https://github.com/ATaylorCEngFIET/MicroZed-Chronicles/blob/master/main_part38.c 

 

I hope this helps and thanks for reading the blog

 

Adam 

by Visitor kmnacheva
on ‎05-09-2016 09:15 AM

Hi Adam, 

 

Thank you for your reply. Would it be possible to send me the Vivado project that you created for this example? 

 

We want to understand the very basics first.

 

In our project we use the ADAU1761 on the ZedBoard to process audio. We need to send the samples that are collected from the PL to the PS. The idea is to generate a custom interrupt whenever a FIFO buffer has collected a certain number of audio samples. Then the PS would read those values from an AXI4-Lite register. 

 

Could you give us some ideas of how to handle the interrupt we need? We are really confused with it. 

 

Regards,

kmnacheva 

by Visitor skoxilinx
on ‎03-04-2017 01:28 PM

Hi

 

I am using Vivado 2016.4.  Starting from a new project I think I have followed the instructions at the top of this blog to get the following

 

 

screenshot.jpg

 

I have generated the bit stream, exported the hardware to the SDK and copied your code to a new software application and BSP. 

 

After running the software using the Jtag port every time I press the button on the microZed I just get following two lines out;

 

Push button Interrupt Event

Push button Interrupt Event

 

The FPGA interrupt is never called.

 

Have you got any idea what I have done wrong please?

 

If it helps I get the following in Vivado when I connect things;

 

WARINING: [BD 41-1731] Type mismatch between connected pins: /processing_system7_0/GPIO_O(undef) and /processing_system7_0/Core0_nIRQ(intr)

 

Thanks for any help you can give

 

Steve

by Observer taylo_ap
on ‎03-06-2017 01:35 PM

Steve

 

I am not qutie sure why it is not working for you, I rebuilt it in 2016.4 and it seemed to work fine for me, ok there was a little bounce from the switch but appart from that it was good.

 

With that in mind I have zipped up my project including Vivado and SDK application and uploaded it to my git hub you can find the link below

 

https://github.com/ATaylorCEngFIET/MicroZed-Chronicles/blob/master/part38_2016_4.zip

 

Hopefully this will be able to help you work out the difference, and please let me know if you need more help

 

Cheers

 

Ad

by Visitor skoxilinx
on ‎03-07-2017 11:48 AM

Thanks for the help Adam, that works well. I too get a few bounces from the switch but it is now going into the FPGA interrupt, all I can think is that I must have selected an option somewhere that I have not been able to spot.  Thank you also for producing the MicroZed Chronicles, I have the Kindle edition and it is a lot of help.

 

Steve

 

Labels
About the Author
  • Be sure to join the Xilinx LinkedIn group to get an update for every new Xcell Daily post! ******************** Steve Leibson is the Director of Strategic Marketing and Business Planning at Xilinx. He started as a system design engineer at HP in the early days of desktop computing, then switched to EDA at Cadnetix, and subsequently became a technical editor for EDN Magazine. He's served as Editor in Chief of EDN Magazine, Embedded Developers Journal, and Microprocessor Report. He has extensive experience in computing, microprocessors, microcontrollers, embedded systems design, design IP, EDA, and programmable logic.