We are trying to use the NI-TNT488.2 GPIB chip in an embedded application. However, we are having problems with the chip locking up when the host PC (with clock speeds at 500+MHz) is pushing and pulling data to and from the target (embedded system) in a TALK / LISTEN scenario. The symptom is that the TNT488.2 stops presenting interrupts on "ADSC" status changes. We are doing programmed I/O on the embedded system with the chip configured in "One-Chip" mode. We have an event driven implementation scheme using a multitasking OS. That is, we do not have a dedicated micro servicing the TNT488.2. We have trapped a case where the chip stops presenting interrupt requests - the transition from "ADSC" - "NEUTRAL" to "LISTEN". When we run t he Spy utility on the host PC, we see either no data or one character transfered followed by a GPIB timeout on the host. Any time the chip (on the embedded system) fails to present the interrupt request to the microprocessor, the chip is locked up forever if there is no intervention by the microprocessor to reset the device. Since we have observed this failure condition, we now set a flag and a timer to check for the lock-up. If the lock-up has occurred we issue a "PON" to clear the lock-up. The downside to this approach is that it forces customers to run through error recovery proceedures in their host applicaitons a very high percentage of the time. Error recovery should be part of every solution, but not within every minute of operation.
If anyone has had similar problems and has found the cause of this type of problem, we would like to hear from you.