Hi !
In our system there are two interrupt sources : the timer (with ID 2) and our custom PIO (with ID 1).
The problem we are facing is that the Altera interrupt handler is randomly called with a mask value equal to 1. But the custom PIO is configured at the moment so that it can't raise any interrupt. The interrupts with the timer work fine.
Is there anything that could generate these unknown interrupts ?
Hi Isaac,
That does indeed sound like a weird issue. I'd like to know a few more details to help you pinpoint the issue.
What do you mean by the "Altera interrupt handler is randomly called with a mask value equal to 1"? Where and how do you capture this information? How do you ensure that your custom PIO does not raise interrupts?
Could you post a screenshot of your main Qsys connection window? Have you assigned unique interrupt IDs in Qsys using System > Assign interrupt numbers, and re-assigned the memory addresses also after adding your component? What are the corresponding macro values in the BSP's system.h?
Have you added an interrupt sender interface in your component definition in Qsys? Did you bind it to the Avalon slave interface as discussed here: https://moodlearchive.epfl.ch/2020-2021/mod/forum/discuss.php?d=55741?
Have you defined your own interrupt service function in your C code, and registered it using alt_ic_isr_register as described in https://www.intel.com/content/dam/altera-www/global/ja_JP/pdfs/literature/hb/nios2/n2sw_nii52006.pdf?
Thanks and cheers,
The TAs team
Hi Alexandre,
Before answering all your questions I remembered about the JTAG module that also can send interrupts requests. Is it possible that this is the interrupt source ? Does it raises interrupts during the main loop program?
What do you mean by the "Altera interrupt handler is randomly called
with a mask value equal to 1"? Where and how do you capture this
information? How do you ensure that your custom PIO does not raise
interrupts?
I put a breakpoint in the Altera interrrupt handler and checked the mask value just before the corresponding ISR is called. I modified the VHDL code of our custom PIO so that the IRQ signal remains low : " irq <= '0' "
Could you post a screenshot of your main Qsys connection window? Have you assigned unique interrupt IDs in Qsys using System > Assign interrupt numbers, and re-assigned the memory addresses also after adding your component? What are the corresponding macro values in the BSP's system.h?
Unfortunately I don't have access to QSYS today, I can post a screenshot tomorow if needed. But the two IPs have a IRQ ID.
Have you added an interrupt sender interface in your component
definition in Qsys? Did you bind it to the Avalon slave interface as
discussed here: https://moodlearchive.epfl.ch/2020-2021/mod/forum/discuss.php?d=55741?
Yes
Have you defined your own interrupt service function in your C code, and registered it using alt_ic_isr_register as described in https://www.intel.com/content/dam/altera-www/global/ja_JP/pdfs/literature/hb/nios2/n2sw_nii52006.pdf?
Yes, the only interrupt registered is the timer's one, which works fine. If I don't register it I still get interrupts from this unknown source. The interrupt actually occurs even before the fist line of our code is executed.
Best,
Isaac
Yes the JTAG debug module may raise interrupts, so depending on your code it could interfere with your logic. However, in your Qsys design it should have an interrupt ID that is different from the other peripherals, and you should be able to catch it in alt_ic_isr_register(alt_u32 ic_id, alt_u32 irq, alt_isr_func isr,void *isr_context,void* flags) as the second parameter named 'irq'. How do you check the mask value?
Cheers,
Alex
I check the mask value with a breakpoint in the main ISR where the specific ISR is called.
Here's a screeshot of the qsys system (ID 1 is the JTAG module):
I have been confused by the JTAG module module which, as I understood now, raises interrupts when using the printf() function.
I understand know what was going on. But there is still something that I don't get: the ipending register (ctl4) has for default value 6 (0b110), JTAG and Timer interrupts enabled. Therefore the timer generates interrupts without the ISR being registered. I have ensured that the system was reset. I don't get why this interrupt is enabled by default.
Best,
Isaac
However the hardware interrupts for the timer are enabled if I understood correctly? So if the timer generates hardware interrupts, the processor will see them in hardware in ipending, indeed with the bit at position 2 (the physical interrupt lane is up). Even if you do not register an ISR for this particular IRQ ID, this does not change the behavior of the hardware. Registering the ISR simply ensures that the interrupt vector will redirect the program flow to your function of choice at a given memory location, otherwise it just noops.
Thanks for your answer.
But how come the hardware interrupt for timer is enabled by default but not the PIO one ?
Ah I understand your confusion now.
The ipending register does not contain the configuration of interrupts, rather the interrupts that have been raised and currently need servicing (i.e. the corresponding peripherals have raised their lanes).
By default the Interval Timer IP will raise an interrupt every time interval as specified in your instance parameters. So it may happen quite often. If you don't service these interrupts, the lane stay up, and so does ipending.
The only way to clear ipending is for the CPU to access your peripheral and perform the specific operation that the device needs to lower the interrupt lane value (often you will write to some control register through a bus write to notify the device that you took care of it).
Let me know if it's still unclear,
Cheers,
The TAs
Follow the pulses of EPFL on social networks
© 2023 EPFL, all rights reserved