TNT 4882 chip read errors

[roni]

Dear Scottie

1. EABO Timeout errors on host PC, probably resulting from the lack of EOI assertion:

We checked and captured the EOI on the scope while the failure occurred. The EOI was always asserted.

We found that the EOI’s magnitude of noise was around 1.5 V.  The EOI jittering was happening a few ns after DAV was asserted. We filtered the noise and the read problem disappeared.

2.  Missing first byte on transmission from PC to TNT. This is our major problem right now and we would like to eliminate it. Can this problem also occur due to a noise issue?  If the answer is positive were exactly should we try to trace it.

Can you figure some other reason that may cause such a problem?

[Collin M]

Can you post an oscilloscope screen capture of the EOI jittering problem you described in your last post? Please take the measurement at the which ever end is doing the GPIB read.

[roni]

I have sent you the plot with the EOI signal during a read failure  to your Yahoo mail . The EOI line is the green one.

Do you have suggestions on how to debug the first character loss when the pc writes to our application (The write problem).

Can it be due to noise problems? If yes , where to try and monitor them?

Do you have any idea on some other reason to cause such a problem?

Thank you

[roni]

Hi

The way that we are working, in general, to read messages from the GPIB:

while (endless)
{
 SoftwareFlagForListnerMode = (mr_adsr & b_LA)

 if SoftwareFlagForListnerMode
 {
  A. Perform initialization, including the GO command. ...
  B. Perform transfer, wait B_done ...
  C. Closing stuff ...

 }

}

Assume that in the closing stuff (item C), we do not (!!! do not) place the line:

TNT_Out(R_auxmr, 0x0C)

So, we do not clear the chip listener state.

What we get ?

The chip remains in listner state (until the Host PC will command it otherwise). As a result, the SoftwareFlagForListnerMode
is true in each loop. As a result, the GO command is sent in each loop. As a result, the waiting for B_done is executed each
loop, causing us to stay there for the timeout period (1ms in our case).

What we get is that our software is mainly in the idle loop of waitng for B_done, when no messages are transferred and the
CPU LOad is very high for nothing.

We do not want to wait if nothing is to be send to us !

We tried to use the above line to clear the Listner mode of the chip.

It works and indeed we do not wait for nothing. However, when, in some of our PC Host programms, the scond WRITE (from PC to our device)
is failing (in some of the programms it fail, in some other not).

Do we need to clear the chip litner mode ?
Does the PC sends addressing to Listner before each write or does it assumes that we should stay lisners ?
What is the correct thing to do after transfer is completed (writign from PC to our device) ?

[GPIB_Guru]

If you are addressed as a listener (LA bit is set), you need to be prepared that the host is going to send you some data. You may be "stuck" in this state after a previous read, but if you ignore it (like you are doing by telling the TNT that you are NOT a listener anymore), you will miss any subsequent data bytes sent from the host. However, if the host is not going to send you any more data, you may be wasting cycles.

A better algorithm is to start a read when you get the LA bit, but not poll until it is done, but continue to look for either your FIFO to be not empty (indicating that the host is indeed writing data to you) or for you to be address changed into TADS (indicating that the host is expecting data from you and you should abort the read since no data is coming your way).

Essentailly, your "wait" algorithm seems to be misplaced to handle the asynchronous nature of the GPIB. Essentailly, as a slave on GPIB (or just about any bus), you need to be prepared for whatever the master can throw at you. You can't assume that because you are addressed as a listener that data will complete or even start. It is perfectly legal to address you as a talker/listener/talker/listener/talker/listener/... and never send a single data byte.

I believe that if you have a glitch on the DAV bit at just the wrong time, the listener may discard the byte, so you may want to check for glitches on your DAV line like you had on your EOI line.

Message Edited by GPIB Guru on 01-16-2006 08:35 AM

[roni]

Hi Scott,

Continuing our discussion from yesterday, we are trying to prove that we are losing the first byte as it arrives after we have a timeout (so we do not monitor the FIFO) and before we run the STOP command.

We do have some micro seconds there, which is enough for that to happen.

We are close to prove that this is the problem we have. More updates on that later.

However, while doign this debugging, we have encountered the following questions:

1. As our software is not written the way it should be done optimally, the PC can send us a byte at a time that we reach the STOP command:

TNT_Out(R_cmdr,F_STOP)

What happen in this case. The arriving byte and the STOP command are not synchronized and any timing between them is possible. Can we lose a byte in this way ?

2. We saw on the osciloscope that there is a time (arounf 5us) between the first bytes are entering the chip (NFRD, DAV, ... handshaing) and the asserting of the FIFO_NEF at ISR0. Is there a reason for this ?

Thanks, Eyal

[Collin M]

In regard to your second question, the FIFO flags and interrupts should be updated very shortly after DAV asserts for the first data byte. The NEF interrupt should assert within 200ns of the first data byte being accepted. Are you sure you are looking at data bytes and not command bytes? There are usually a few command bytes that precede a data transfer. These command bytes are used to correctly address the bus. An easy way do distinguish betweeen command bytes and data bytes is that ATN will be asserted (~0V) for command bytes and unasserted (~3V) for data bytes.

Collin

[ScottieB]

And with respect to your first question,

It's possible that you're losing a byte just after performing a "STOP" command.  The trick to not losing this byte is to make sure no more bytes are coming from the controller.  If you've received EOI, then it's safe to stop because you know that the transfer is over.  If you've reached your maximum bytecount, you'll be stopped automatically (you'll see the DONE bit set when you've gotten all the data out of the FIFO's).  If you have reached terminal bytecount without receiving EOI, this is cause to wonder whether or not there are more bytes to be read.  If you've timed out and want to stop the transfer, hopefully you've allowed enough time to be sure that there are no more bytes coming when you write STOP to the cmdr.

So yes, it's possible, and yes, you have to be careful to avoid possible pitfalls.  See chapter 4 in the TNT4882 manual for complete information on this.

Scott B.

GPIB Software

National Instruments

[GPIB_Guru]

To follow up on Scott's post... You should never implement timeouts as a device. If you "timeout", then you are aborting the IEEE 488.1 state machines at a dangerous state. If you abort a transfer at the same time as the host sends you a data byte (asserts DAV), the byte could be lost depending on which event happened first. Essentially, the danger is that when you start the read, you are telling the bus that you are ready for a byte. A talker is allowed to place a data byte on the bus. If the talker places a data byte on the bus at the same time you say "just kidding, I am not really ready", there would be a deadlock since the talker needs to keep the byte on the bus until it is accepted. Therefore, the TNT4882 chip will complete the handshake to alleviate the problem with the talker, but the byte will be discarded.

A device should only abort a transfer when it knows that it is safe to do so. For example, if you have a read transfer in progress and you get an ADSC interrupt indicating that you are now a talker, it is safe to abort the read since you know that you will not be getting any more data bytes.

[roni]

Hi

We have implemented your latest recommendations.

The system runs continuously in the past several hours with no errors.

We are very optimistic and feel the troubles are behind us.

Thank you very much for the continuous professional support.

We would not have done it without you.

Thank you all again