cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Explorer
Explorer
4,032 Views
Registered: ‎04-23-2013

IRQ_F2P interrupt only runs after cold boot

Jump to solution

Hello,

I am using SDK to code the ARM on the Zynq FPGA.

I set up IRQ_F2P[0] with the XPS_FPGA0_INT_ID for edge sensitivity.

It works the first time after cold boot, but not on subsequent re-starts.

This might be OK for the final product, but slows development since I have cycle power and program FPGA every time.

 

Below is my initialization.

Is some extra initialization needed?

 

Thanks,

Emmett

 

///////////////////////////////////////////////////////////////////////////
// Initialize IRQ Interrupt
// Xil_ExceptionInit(); this is an empty function leftover for backwards compatibility

// Initialize the interrupt controller driver (IntcConfig is static global)
IntcConfig = XScuGic_LookupConfig(XPAR_SCUGIC_SINGLE_DEVICE_ID);
if (NULL == IntcConfig) return XST_FAILURE;

InitStatus = XScuGic_CfgInitialize(&IntcInstance, IntcConfig, IntcConfig->CpuBaseAddress);
if (InitStatus != XST_SUCCESS) return XST_FAILURE;

// Connect the IRQ ISR handler to hardware
Xil_ExceptionRegisterHandler(XIL_EXCEPTION_ID_IRQ_INT,
(Xil_ExceptionHandler)XScuGic_InterruptHandler, &IntcInstance);

// Enable IRQ exception in the CPU
Xil_ExceptionEnableMask(XIL_EXCEPTION_IRQ);

// Connect a handler function to the IRQ interrupt
// Use XPS_FPGA0_INT_ID instead of XPS_IRQ_INT_ID for programmable sensitivity
InitStatus = XScuGic_Connect(&IntcInstance,XPS_FPGA0_INT_ID,
(Xil_ExceptionHandler)PLIntrHandler,
(void *)&IntcInstance);
if (InitStatus != XST_SUCCESS) return XST_FAILURE;

// Enable the IRQ_F2P
XScuGic_Enable(&IntcInstance, XPS_FPGA0_INT_ID);

0 Kudos
1 Solution

Accepted Solutions
Highlighted
Moderator
Moderator
6,604 Views
Registered: ‎09-12-2007

you could put the EOI in the init (for your use case), you should clear in your handler.

View solution in original post

10 Replies
Highlighted
Voyager
Voyager
4,018 Views
Registered: ‎06-24-2013

Hey @emmettbradford

 

Do you handle (and clear) the interrupt in your code?

 

Best,

Herbert

-------------- Yes, I do this for fun!
0 Kudos
Highlighted
Scholar
Scholar
4,017 Views
Registered: ‎02-27-2008

e,

 

One post is sufficient (no need to post in multiple places).

 

How are you "restarting"?  A PROG_b causes a full configuration of both the PS & PL.  A reset of the PS does not re-load the configuration of the PL.  Operation over JTAG (commands, re-loading) depends on what commands, and what is re-loaded.

 

PS == processor system

PL == programmable logic

 

 

Austin Lesea
Principal Engineer
Xilinx San Jose
Highlighted
Moderator
Moderator
4,015 Views
Registered: ‎09-12-2007

If you resert the pl, without resetting the ps, then you may need to set the EOI during init. For example can you add the line in the interrupt init in your application Where XX is your interrupt ID

XScuGic_CPUWriteReg(&InterruptController, XSCUGIC_EOI_OFFSET, XX);

Highlighted
Explorer
Explorer
4,014 Views
Registered: ‎04-23-2013

Thanks for the reply.

Here is my handler.

If I need to clear the interrupt here, I don't yet know how.

 

static void PLIntrHandler(void *CallBackRef, u32 Mask)
{
PLIntrCnt++;
/*
u32 ReadData;
// Toggle an LED on the KR module
ReadData=Read_creg(0x0081);
if(ReadData & 0x80000000)
Write_creg (0x0081, ReadData & 0x7FFFFFFF);
else
Write_creg (0x0081, ReadData | 0x80000000);
*/

while((Read_dreg(0x007F) & 0x00000002)==0) {Read_dreg(0x0030);} //Check empty flag and read out DarkOutFIFO
while((Read_dreg(0x007F) & 0x00000008)==0) {Read_dreg(0x0031);} //Check empty flag and read out RawOutFIFO
while((Read_dreg(0x007F) & 0x00000020)==0) {Read_dreg(0x0032);} //Check empty flag and read out CalOutFIFO

}

0 Kudos
Explorer
Explorer
4,009 Views
Registered: ‎04-23-2013

Hi stephenm,

Thanks for the reply.

I want to work and not hang when I stop and start debug in SDK, without power down.

I have testing this morning and see some other wierdness depending on where I toggle the LED, in or out of the PLIntrHandler.

So maybe it's a different problem altogether.

However, should I be clearing the interrupt at initialization and in the handler?

Thanks,

Emmett

0 Kudos
Highlighted
Moderator
Moderator
4,004 Views
Registered: ‎09-12-2007

   Add this to your handler an let us know if this works


    IntIDFull = XScuGic_CPUReadReg(&InterruptController, XSCUGIC_INT_ACK_OFFSET);
    XScuGic_CPUWriteReg(&InterruptController, XSCUGIC_EOI_OFFSET, IntIDFull);

0 Kudos
Highlighted
Explorer
Explorer
3,997 Views
Registered: ‎04-23-2013

I see these lines in XScuGic_InterruptHandler.

Is XScuGic_InterruptHandler something that runs at every interrupt?

Should I put these lines in my handler as well or in my initialization?

0 Kudos
Highlighted
Moderator
Moderator
6,605 Views
Registered: ‎09-12-2007

you could put the EOI in the init (for your use case), you should clear in your handler.

View solution in original post

Highlighted
Explorer
Explorer
3,979 Views
Registered: ‎04-23-2013

I put both lines in my handler and init.

It doesn't seem to make a difference whether in either or both functions.

On the 1st debug run after power on and FPGA config, the interrupt will run.

On repeated debug runs, the interrupt will eventually not run.

 

Please check my code to see if I did what you suggested.

 

Thanks,

Emmett

0 Kudos
Highlighted
Explorer
Explorer
2,225 Views
Registered: ‎04-23-2013

I never resolved this.

I made a workaround by changing my debug configuration to reset everything and program FPGA.

It takes longer though.

I would still like to get this working on recursive PS starts.

Thanks,

Emmett

0 Kudos