tnt4882 chip interrupt stops

[veemo]

I am using the TNT4882 in an embedded environment with the IXP465 processor running at 533Mhz.  I wrote a Linux driver for the chip and I'm testing it by doing read writes and looping it over and over again.  The driver has been hard coded to return a constant string back when a read is issued from the PC controller.  The test runs fine but after some amount of time, the chip stops responding, or it stops generating interrupts to the CPU.  It has failed after a wide range of time periods ( 1 minute, 3 minutes, 30 minutes, 45 minutes).  The chip always get "stuck" on a read.  NI spy shows that ibrd fails with ibsta = 0xc100 ( ERR | TIMO | CMPL ) and iberr = EABO (6). 

I'm able to trace the execution path of the driver up to the point when the chip stops generating interrupts.  The driver initializes the chip for being a talker:

- resets the FIFOs

- sets CFG with TLCHLTE halt bit and CCEN bit enabled

- writes to CNT0 and CNT1

- sets IMR1 with DET, DEC, ERR enabled

-  issues GO command

- sets IMR3 with INTSRC2, TLCINT, DONE enabled

After this process, normally the chip generates an interrupt for INTSRC2 ( indicating FIFOs are at least half empty ), which then it handles the transfer process.  But at this point it seems like the chip is in a hung state.  It doesn't generate an interrupt even when a clear is issued, which it should since the DEC bit is enabled in IMR1.

Does any one have an idea of what could be causing this problem?  I found a post from 8 years ago that someone had mentioned the "hung" chip problem but no one responded to the problem.  Link - http://forums.ni.com/ni/board/message?board.id=140&message.id=27&query.id=108233#M27

[veemo]

The chip is actually asserting the interrupt line constantly when the chip "hangs".  I was able to clear it a few times by reading the ISR registers.  But after the 3rd time it hangs, I couldn't clear the interrupt any more and had to power cycle the board.  What would cause the ISR line to be constantly asserted?

[Caleb_W]

Hi Veemo,

When you reset the line does the chip function as you would expect again? 

[veemo]

Hi Caleb,

What do you mean by resetting the line?   Like doing a soft reset ( writing 0x22 to CMDR )?

Currently I seemed to have fix the problem by avoiding the problem.  My driver is now checking for the INT bit before I exit the ISR, if it's set, it'll continue servicing it.  I don't know if it's possible that the TNT4882 chip was asserting the IRQ before my ISR finished.

[Caleb_W]

I was refering to the fact that you said you were able to clear the problem by reading the ISR register.  I'm glad you got it working, This hang could happen if the interrupt condition occured at the same time the host interface is reading the ISR.  The ISR is not set until the read is finished so it chould have been causing problems.

[veemo]

The chip was able to function as expected after I had cleared the interrupt, by reading all the ISR registers.  However, I was not able to always clear the IRQ by just reading the ISR registers, when this happens, power cycling the system is my only solution.  I'm puzzled by the fact that the IRQ doesn't get cleared when the ISR registers are read because as far as I know, that's the only thing I need to do since the SISB bit in AUXRI is not set. 

Do you know what other conditions would cause the TNT4882 chip to assert the IRQ and continue so even when the ISR registers are read?

Thanks.

[Caleb_W]

The manual outlines the different conditions for the ISR lines and how the device will react.  You can find the manual here: http://www.ni.com/pdf/manuals/370872a.pdf.  Chapter 3 specifically focuses on the Interface Registers.  It will describe all of the conditions that could cause this issue.