cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Contributor
Contributor
613 Views
Registered: ‎08-26-2018

PL to PS interrupt (Legacy FIQ) crashes the RPU and APU on MPSoC+

Hello all,

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.

 

 

0 Kudos
2 Replies
Highlighted
Contributor
Contributor
535 Views
Registered: ‎04-25-2017

Re: PL to PS interrupt (Legacy FIQ) crashes the RPU and APU on MPSoC+

Hello,

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?

regards,

Alex.

0 Kudos
Highlighted
Contributor
Contributor
467 Views
Registered: ‎08-26-2018

Re: PL to PS interrupt (Legacy FIQ) crashes the RPU and APU on MPSoC+

Hello lar_fer,

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.

Regards,

Nirdhish

0 Kudos