02-04-2020 02:26 PM
I'm having trouble figuring out how to trigger interrupts with buttons on my Arty Z7.
I have done this successfully with an original Arty Artix 7 and Microblaze using the same sample code provided in Vivado SDK (although conditionally compiled differently) - see https://forums.xilinx.com/t5/Processor-System-Design/ERROR-in-SDK-Example-xgpoi-intr-tapp-example-c-on-VCU108-board/m-p/1070426#M51197 .
The design is very basic, and the mappings to the buttons were chosen to match the sample code (xgpio_intr_tapp_example.c). The program compiles and runs fine, but does not generate interrupts on button press; it times out per the code. The GPIO-Zynq interrupt connections are a reasonable guess based on this video: https://www.youtube.com/watch?v=JPVTVNtJ7R4. (Same result with or w/o the concat.)
A sister example program - a non-interrupt based button reporter (xgpio_tapp_example.c) - works fine, so the external connections in the board design seem okay.
I have checked all the #defines through to xparameters.h, etc., and they seem to be mapped to the correct values (don't know how to confirm that XPAR_FABRIC_AXI_GPIO_0_IP2INTC_IRPT_INTR should be 61U).
If it is possible to step through the code in the SDK with breakpoints on the fly and read the variables, I don't know how. I'm using 18.3.
02-09-2020 12:13 PM
Solving this problem just about broke me:
XScuGic_SetPriorityTriggerType(IntcInstancePtr, IntrId, 0xA0, 0x3); //0xA0 was set to 0xF8
I don't know how 0xF8 got in there. I don't understand enough about the function call, even after reading the cryptic in-code comments, to change it. And it still isn't clear why 0xF8 would fail (other than it set interrupt priority to nothing?).
Aside - as part of the debugging, I added an AXI_Timer module and built its interrupt example project. The sample code included a reference to XPAR_INTC_0_TMRCTR_0_VEC_ID , which was not automatically generated in xparameters.h . I changed it to XPAR_FABRIC_AXI_TIMER_0_INTERRUPT_INTR, then the sample code ran as expected. Maybe I just got lucky?
After rebuilding my project from scratch, rewriting the sample code, then discovering the 0xA0 substitution, I went back to my original project where I was having problems. Surprisingly, it was configured for 0xA0, not 0xF8. More surprisingly, it ran correctly. Might have been some other glitch in the toolchain creating the original failure.