Potential _interrupt_handler infinite loop

--- Quote Start ---

originally posted by stefanlevie@Mar 10 2006, 01:58 PM

i added a 16550 uart fpga core and when receiving large quantities of data my system is locking up because it is in an infinite loop within the _interrupt_handler assembly code in vector.s. what i find is that i appear to get an interrupt but when i enter _interrupt_handler it appears the ipending register is 0 and this causes an infinite loop!

at the beginning of _interrupt_handler it reads the ipending register to determine which interrupts are pending:

rdctl r24, ipending

later the following code runs to determine which interrupt to process by basically shifting r24 and incrementing r4 until there is a 1 in the lower bit. it then uses r4 to determine which call to make:

6:

andi r3, r24, 1

bne r3, zero, 7f

addi r4, r4, 1

srli r24, r24, 1

br 6b

7:

when i hang, r24 is 0! i'm not sure how this happens, but since r24 is 0 i can never break out of the loop. i assume ipending was 0 when it was copied as otherwise i should not end up stuck in this loop. when i break with the debugger and dump the registers i get:

r3 = 0

r4 = 0x656c462 (obviously ran for a while)

r24 = 0 (actual disassembly shows this as register et)

ipending = 0x44 (after i break with the debugger)

if i go and then break again, r4 changes to 0x79af66b. if i manually set r3 to the ipending value, clear r4 and then go, i get out of the loop and the code appears to run fine except for the lost data.

i suspect that i have a hw problem which is aggravating this. however, i am not sure exactly what the hw can do so that i can end up in this situation.

any ideas how i could appear to be processing an interrupt but yet not have one pending?

any ideas how the hw interrupt functionality could case a problem like this?

shouldn't the system be able to handle a spurious interrupt if this is the cause?

it's not clear to me there is an easy fix to this. obviously any changes here would effect every interrupt so it's possible that there shouldn't be any changes. however, it's certainly something to investigate.

i'm using quartus 5.1 sp1 web edition, nios ii 5.1, ecos for 5.1. this problem also occurs with the 5.0 versions.

thanks,

stefan

<div align='right'><{post_snapback}> (index.php?act=findpost&pid=13321)

--- quote end ---

--- Quote End ---

I suggest you take a look at page 3-11 Determining the Cause of Exceprions in the Nios II Processor Reference Handbook n2cpu_nii5v1.pdf. Is your problem actually an exception? If not then as you surmise it&#39;s likely to be a hardware bug.