FPGA Central

Hi!

I have the following problem on a Virtex5 system:
I use an interrupt controller, that is connected to the PPC interrupt
port. The interrupt controller and the PPC interrupt handler are
initialized but working ONLY for the very first interrupt. After the
first interrupt occured the processor hangs at address 0x60, which is in
the interrupt vector table:

00000060 <IVOR6>:
60: 7c 70 43 a6 mtsprg 0,r3
64: 38 60 00 06 li r3,6
68: 7c 60 43 a6 mtspr 256,r3
6c: 48 00 00 94 b 100 <non_critical_irq>

Did I miss something about the initialization? I used the source code
provided with the examples of the xps_intc.

Matthias

The thing is really odd. I wanted to figure out when the program jumps
to the address 0x60. I used XMD, set a breakpoint to the interrupt and
went through the whole interrupt stuff step by step (i.e. instruction by
instruction). I could see, that the program is continued correctly after
the interrupt (it sends data through UART). So everything worked as
expected!
However, when I then use "con" to continue the program (after the
interrupt was successful and the normal program already continued), the
program freezes again and the program counter is set to 0x60 (which
seems to be a program exception or something like that).

How can that be?

Matthias



> I have the following problem on a Virtex5 system:
> I use an interrupt controller, that is connected to the PPC interrupt
> port. The interrupt controller and the PPC interrupt handler are
> initialized but working ONLY for the very first interrupt. After the
> first interrupt occured the processor hangs at address 0x60, which is in
> the interrupt vector table:
>
> 00000060 <IVOR6>:
> 60: 7c 70 43 a6 mtsprg 0,r3
> 64: 38 60 00 06 li r3,6
> 68: 7c 60 43 a6 mtspr 256,r3
> 6c: 48 00 00 94 b 100 <non_critical_irq>
>
> Did I miss something about the initialization? I used the source code
> provided with the examples of the xps_intc.
>
> Matthias

Just a small update again. I managed to get the design working a bit
better... I modified my linker script, such that the .vectors section is
now stored in the BRAM memory instead of the DDR2 memory. As a result
the processor keeps working after an interrupt. So maybe the problem was
some kind of timeout error because of the slow DDR-RAM?

But I now have the problem that the processer seems to see interrupts
all the time. Actually there are no interrupts from the interrupt
controller. So the processor just stays in the interrupt routines for an
external interrupt all the time and the normal program is never
continued after there was one or more real interrupts. But it is now
possible to have more than just a single interrupt.

The odd thing again is that the processor goes to the normal program
when I use step by step in XMD.

Matthias



Matthias Alles schrieb:
> The thing is really odd. I wanted to figure out when the program jumps
> to the address 0x60. I used XMD, set a breakpoint to the interrupt and
> went through the whole interrupt stuff step by step (i.e. instruction by
> instruction). I could see, that the program is continued correctly after
> the interrupt (it sends data through UART). So everything worked as
> expected!
> However, when I then use "con" to continue the program (after the
> interrupt was successful and the normal program already continued), the
> program freezes again and the program counter is set to 0x60 (which
> seems to be a program exception or something like that).
>
> How can that be?
>
> Matthias
>
>
>
>> I have the following problem on a Virtex5 system:
>> I use an interrupt controller, that is connected to the PPC interrupt
>> port. The interrupt controller and the PPC interrupt handler are
>> initialized but working ONLY for the very first interrupt. After the
>> first interrupt occured the processor hangs at address 0x60, which is in
>> the interrupt vector table:
>>
>> 00000060 <IVOR6>:
>> 60: 7c 70 43 a6 mtsprg 0,r3
>> 64: 38 60 00 06 li r3,6
>> 68: 7c 60 43 a6 mtspr 256,r3
>> 6c: 48 00 00 94 b 100 <non_critical_irq>
>>
>> Did I miss something about the initialization? I used the source code
>> provided with the examples of the xps_intc.
>>
>> Matthias

I found that catching interrupts when debugging is very hard to do. I had
the same problem of missing interrupts when trying to write the stack frame
save code for a RTOS that I wrote. I was using the PPC405 though.


---Matthew Hicks


> Just a small update again. I managed to get the design working a bit
> better... I modified my linker script, such that the .vectors section
> is now stored in the BRAM memory instead of the DDR2 memory. As a
> result the processor keeps working after an interrupt. So maybe the
> problem was some kind of timeout error because of the slow DDR-RAM?
>
> But I now have the problem that the processer seems to see interrupts
> all the time. Actually there are no interrupts from the interrupt
> controller. So the processor just stays in the interrupt routines for
> an external interrupt all the time and the normal program is never
> continued after there was one or more real interrupts. But it is now
> possible to have more than just a single interrupt.
>
> The odd thing again is that the processor goes to the normal program
> when I use step by step in XMD.
>
> Matthias
>
> Matthias Alles schrieb:
>
>> The thing is really odd. I wanted to figure out when the program
>> jumps
>> to the address 0x60. I used XMD, set a breakpoint to the interrupt
>> and
>> went through the whole interrupt stuff step by step (i.e. instruction
>> by
>> instruction). I could see, that the program is continued correctly
>> after
>> the interrupt (it sends data through UART). So everything worked as
>> expected!
>> However, when I then use "con" to continue the program (after the
>> interrupt was successful and the normal program already continued),
>> the
>> program freezes again and the program counter is set to 0x60 (which
>> seems to be a program exception or something like that).
>> How can that be?
>>
>> Matthias
>>
>>> I have the following problem on a Virtex5 system:
>>> I use an interrupt controller, that is connected to the PPC
>>> interrupt
>>> port. The interrupt controller and the PPC interrupt handler are
>>> initialized but working ONLY for the very first interrupt. After the
>>> first interrupt occured the processor hangs at address 0x60, which
>>> is in
>>> the interrupt vector table:
>>> 00000060 <IVOR6>:
>>> 60: 7c 70 43 a6 mtsprg 0,r3
>>> 64: 38 60 00 06 li r3,6
>>> 68: 7c 60 43 a6 mtspr 256,r3
>>> 6c: 48 00 00 94 b 100 <non_critical_irq>
>>> Did I miss something about the initialization? I used the source
>>> code provided with the examples of the xps_intc.
>>>
>>> Matthias
>>>

I found the solution for this problem. The thing is that the flag for a
decrementer interrupt (DEC) was set in the timer status register (TSR)
after powerup. Since I don't use this DEC interrupts the flag of course
is never cleared. Now when I enable my external interrupts (EE flag in
MSR) the DEC interrupt is enabled as well. Since I don't have an
interrupt handler for this case the interrupt occurs all the time and
the normal program is never executed anymore.
So a single line in the startup code does the trick:

XTime_TSRClearStatusBits(XREG_TSR_CLEAR_ALL);

The difference between stp and con in XMD seems to show that stp just
doesn't care about interrupts at all.

Matthias