07-02-2019 01:57 PM
The project I am working on involves both the APUs and RPUs present in ZCU102 Ultrascale MPSoC+ board. The APUs run ADI linux whereas, the RPUs run a baremetal code. To reduce the interrupt latency, I moved the interrupt handling for one of the signals from APU to RPU by making use of the legacy interrupt support. The interrupt is an external signal routed to nfiq0_lpd_rpu.
In the software side, I first disabled the GIC FIQ, then registered and enabled FIQ interrupt by doing this :
u32 reg = XScuGic_ReadReg(XPAR_PSU_RCPU_GIC_BASEADDR, 0); XScuGic_WriteReg(XPAR_PSU_RCPU_GIC_BASEADDR, 0, reg & ~8); Xil_ExceptionRegisterHandler(XIL_EXCEPTION_ID_FIQ_INT, (Xil_ExceptionHandler) ISR,(void *)CPU_BASEADDR); Xil_ExceptionEnableMask(XIL_EXCEPTION_ALL);
My ISR just prints "irq".
The problem is, the entire system crashes when an interrupt occurs.
07-11-2019 01:35 AM - edited 07-11-2019 01:40 AM
We are in a similar situation. We want to use the IPI via GIC and also nfiq1_lpd_rpu, that is connected to an AXI gpio interrupt. We found this in AR https://www.xilinx.com/support/answers/70116.html.
The code is similar to yours. Our ISR also prints. We get the prints, but even though we try to clear the gpio irq, it seems that we can´t. We get infinite prints.
Did you get to see the print of your ISR?
07-21-2019 03:35 AM
That is because FIQ is low level triggered. I haven't found a way to make it edge triggered (I don't think it is possible).
If your Interrupt signal's "off time" is deterministic, I think you can use the following workaround.
1) Immediately after entering ISR, deregister the handler.
2) Peform the ISR tasks
3) sleep untill you are sure that the signal is high. In our case, the interrupt signal will stay low for 2ms, so the system just sleeps for 2ms after performing the ISR task
4) Re-register the handler.