TNT 4882 chip read errors

[roni]

Hi.

I hope X-Mas and the new year went well for you.

Why did you send this file ? It could not be opened (even after modifying the extension).

In response to your question:

No major modifications were made to the original code, but I would like to update you regarding the problems we are facing:

We are still having the sdame problems with the missing of the first character, we thought it was all behind us (with a new problem), but we were deceived.

Our application consists of the GPIB controller + Intel PXA 255 uController. The application task is a servo motor controller. The same uController, is used in order to run the servo control loop, and the GPIB (and other various tasks). No operating system is used

The servo controller loop interrupt, is called every 64us (16KHz), and takes approx 20-30us, leaving double that time for background tasks, in our case, handling the GPIB. The same servo loop, used to call the 'famous' updateinterface function, in order not to lose GPIB events, and one of our tests was to move the updateinterface function, into the background.

This test definately improved matters with the losing of the first charachter, but still was not solved.

In addition, the host computer read problem still happens (as a result of changing the lines )

This is the place to say, that changing the lines(rhdf and go) definately improved matters. Instead of having the problem every 2 minutes, we reached between 40 minutes-1 hour.

I have a few questions:

1. Are there any ways an independant interrupt routine can cause problems like these to happen. What I mean is, are there any sequences that must happen without any disturbances, such as an interrupt between lines ?

2. What is the length of the ATN pulse. Is it possible I am missing it ? I noticed, that when I miss the 1st char, this char was sent well long before the latter chars.

3. I modified the TNT_OUT/IN macro, that there will be an additional delay of 500ns, we minor improvements.

4. I modified the TNT_OUT/IN macro, that there will be an additional delay of 5us, we saw major improvements. Is there an axpalnation to this ?

5. When I am assigned to be a talker, I prepare local fifos (my SW fifos) of data to be sent. What I noticed, long ago, is that when I receive a request for serial poll, I also receive talker as well. Of course the send fails (data_count=0), but this ruins my inner fifos, and is very time consuming. what i did was, I check the status of adsr, in order to check that it is not serial poll:

// If talk addressed

if((iGPIBStat&TACS)==TACS)

{

Set_Timeout(SLOW_DELAY,TRUE); /* Change timeout */

// check status register

iR_adsr = (unsigned char)TNT_In(R_adsr) ;

if( ((iR_adsr & 0x20)) ||

((iR_adsr == 0)) ||

((iR_adsr & 0x2)==0) ||

((iR_adsr & 0x1)==0x1))

{

return ;

}

//

PopMsg(g_pTxBufferGPIB,&g_iTxIndexGPIB) ;

The pop message is an inner fifo of mine (data to send).

Is it possible the read problem is due to this ? Why, if I receive I am talker, I need to check I am not Serial poll ?

I am sending this to your email as well, This matter is very important and we need your full attention, if possible.

Thanks,

Benji

[ScottieB]

Benji/Roni,

This is a complicated issue.  For those following along, I have some communications from this user offline.  I'll do my best to reproduce the gist of them here.  Benji/Roni, feel free to correct my synopsis.

Basically, they're creating a device using the ESP-488TL codeset, I believe.  They have specific needs for their device: it needs to respond to being addressed as a talker, listener, being serial polled, and being sent Device Clear via GPIB.  The way they know when to perform which task is via a global GPIB Status variable known as iGPIBStat that has bits labelled things such as TIMO, END, EOS, SPOLL, DCAS, TACS, LACS, UCMPL, ERR, similar to ibsta in the mainstream NI-488.2 driver.  The subroutine known as Update_INTERFACE_STATUS2() reads various bits from the GPIB card in the various Interrupts Service Registers (ISR's) and other registers to update this status word.  Then, they just run a loop that does something like this:

1. Update_INTERFACE_STATUS2()

2. Is the DCAS bit set in iGPIBStat ?  If yes, do a device clear & goto 1.

3. Is the SPOLL bit set in iGPIBStat ?  If yes, respond to serial poll & goto 1.

4. Is TACS set in iGPIBStat ?  If yes, talk & goto 1.

5. Is LACS set in iGPIBStat ?  If yes, listen & goto 1.

6. Goto 1.

Now, they are seeing that SPOLL and TACS will sometimes be set at the same time.  This causes obvious problems for the loop above in that we enter BOTH the SPOLL branch in line 3 and the TACS branch in line 4.  I think this is causing their original byte-loss issue.  By entering the TACS branch in line 4, they sent one byte from the beginning of their buffer when they were really just being serially polled.  Why was TACS being set when they were being serial polled??  In some sense, it makes sense: the process of a serial poll is for the controller to send the SPE (serial poll enable) byte and then to address the device being polled as a talker.

The reason they're getting both bits set really comes from the code in Update_INTERFACE_STATUS2(), I think.  SPOLL is being set by reading the ADSR's SPMS bit in their code.  SPMS will set whenever the TNT4882 GPIB chip is in being serial polled AND IT WILL NOT BE UNSET UNTIL THE SERIAL POLL HAS FINISHED.  Further, the TACS bit is being set by reading the TA bit of the ADSR, which will always set when the TNT4882 GPIB chip is in the SPAS (Serial Poll Active State).  It is questionable whether or not the chip should be used in this way.

Reading the TA bit and accepting it as an indicator as when the device is addressed as a talker and should send data isn't entirely correct--as we have seen, a serial poll will activate this bit as well.  Also, reading the SPMS bit is of questionable value when determining when one should respond to a serial poll.  Ideally, one would use the STBO bit in ISR2 to know when to respond to a serial poll, and one would do so by writing to the SPMR.  As soon as you write to the SPMR, the STBO bit will clear.  Thus you won't run into weird timing problems that manifest themselves because SPMS does eventually go away, but only after the device has transmitted the serial poll response to the controller.

So, I wonder:

1) Why use SPMS in ADSR instead of STBO in ISR2?

Scott B.
GPIB Software

[roni]

Scott / Ditto,

The loss of the byte is not sending the byte from the TNT to the host computer, but receiving the byte to the TNT.

Please see additional previous post.

Benji / Roni

[ScottieB]

Understood.  Perhaps this problem is not related to the original.  So are we tracking 2 problems at this point? 

-Loss of byte being sent from PC to TNT

-Entering of the "talker" branch during a serial poll

On the second problem, I'd still like to know why you're using SPMS rather than STBO.  Is the first one related to this, or is it separate?

Scott B.
GPIB Software

[ScottieB]

I haven't heard from you in a few days on this.  Can we get a status update?

Scott B.
GPIB Software
National Instruments

[roni]

Hi.

1. Can I have your email,as I have a rather large mail (>5000chars) to send you. benjis@consol.co.il

2. Regarding the loss of byte - This seldom occurs now, as we inserted delays between reading bytes from the fifo. It is weird, because it also depends on the speed of the host computer - the loss of bytes issue. The fact we need to insert delays between reads is quite unacceptable, and we do not see any documentation regarding this.

The problem we are mostly having  is reading data from the host PC. We read the data, but when looking in the spy, it all goes read and the EABO bit is on. The correct data is there though !!! Why a timeout

Basically, this is the main problem we are having...and we need your assistance ASAP.

3. Regarding the 'Entering of the "talker" branch during a serial poll' - well we read the status of the adsr to ensure we are not serial poll, the problem is, if we just took care of a SP, we need to read adsr a few times in order for it to be updated. It takes time from relesing the SP until adsr is properly updated (we checked this by entering counters on messages sent, and SP, and reads...). After inserting the extra adsr reads, it was no longer a problem. very fishy...

Benji / Roni

[GPIB_Guru]

Timeout with the data indicates an incorrectly terminated message. Make sure that you are asserting EOI with the last byte.

[roni]

How can it be that the same loop that does the sequence : Write, S pool, Read  fails randomally on the read time out after working well for thousants of times.

[roni]

Our code is working in one-chip mode. We configure the Configuration Register (CFG) to have bit 3 (CCEN) with a value of “1”. As we understand the manual:

“In this mode (One-Chip), the CCR is ignored. On the last byte of a GPIB write, EOI is asserted if CCEN = 1”So it seems as the EOI is asserted automatically in this mode. We see a nice EOI pulse (although who knows, maybe it is lost sometimes …).Our questions are:

1. What is “CCR” ?
2. Is the EOI indeed inserted automatically in the One-Chip mode ?
3. If yes, how the chip knows that a given byte is the last one ? Our code just fills the data into the fifo and we give no special treatment to the last one … ? Is it when the counters reaches zero. Is that correct ?
4. If not EOI automatically inserted), and as we see that we have (normally) EOI, which of our commands does it ? (so I can check its timing to see if it is possible that we indeed losing EOI) ?
5. We have some noises (minimal) on the EOI signal. We have also observed that connecting an oscilloscope to this line increases the time between failures. Do you know when exactly inside the cycle (compared to NFRD, NDAC,) the EOI is sampled by the Receiver ?

6. Do you have anything in the database about problems in the counters ? Do we need some time gap between writing Reset FIFO and writing to the counters(CNT0) and between writing to all four counter registers ? In our code Reset FIFO, CNT0, CNT1, CNT2 and CNT3 are written one after the other.

[ScottieB]

Let's pick a problem and get through that one.  So far I've got a few:

1. Missing byte on transmission from PC to TNT.  Minimized by adding delays between FIFO reads.  You should not have to do this.  Something else is wrong.

2. Serial polls reaching the Talker branch of your firmware loop.  My recommendation is to avoid using SPMS and use STBO instead.

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

It seems that you want to work on #3 now.  I'll answer your questions.  Regarding your e-mail, I would prefer we keep this discussion public.  If you have something that must remain off of this forum, we can exchange that via e-mail.

1.  The CCR is not used in one-chip mode.  See the TNT4882 reference manual.

2.  Yes, as long as you have set CCEN to 1 before the write.  Again, see the reference manual.

3.  As long as you are correctly using the count registers by loading the 2's complement of the number of bytes to send, the chip will know which byte is the final one.  You should probably check your count registers to make sure they are being properly loaded.

4.  See above, EOI is generally "automatic".

5. Please provide more information about the type of noise and magnitude of the noise.  Be sure you're using proper cabling (metal shielded connectors are best for harsher environments).  EOI needs to remain in a valid state whenever DAV is asserted. EOI is usually sampled a few ns after DAV asserting, but it must not change states whenever DAV is asserted.

6. You should be fine doing this.  One thing to check is to read the CNT registers just before you reset the FIFO after a write from the chip to the PC.  The CNT registers should indicate that there are no bytes remaining in the FIFO.  If they read non-zero, an incorrect count was probably loaded before the transfer began.

Thanks,

Scott B.

GPIB Software

National Instruments

Message Edited by ScottieB on 01-10-2006 11:05 AM