TNT4882 write succeeded but read failed

[Steve Ju]

I'm writing a linux driver for TNT4882 and met some problems when testing it. The TNT4882 is working in one chip mode, has only one address. I have a host PC with NI LabVIEW software and a PCI-GPIB card installed. I'm using the simplest GPIB read and GPIB write to test my driver. The data from TNT4882 can be successfully transferred to PC by a LabVIEW GPIB read. However, TNT4882 can't get any data from PC, in other words, I can't read data through TNT4882. When a LabVIEW GPIB write is issued, TNT4882 becomes an address Listener (TA bit set in ADSR) but NEF bit is always clear, indicating no data available in FIFO to read.

Currently I'm polling the NEF bit in ISR3 to conduct the data transfer from FIFO to RAM, although I have setup the interrupts. The following is part of the source code.

1. Initialization:
CMDR = 0X22;
SPMR = 0X80;
AUXMR = 0X80;
AUXMR = 0X99;
KEYREG = 0X00;
HESSEL = 0X01;
AUXMR = 0X02;
AUXMR = 0X51;
AUXMR = 0X00;

2. Set address to 10:
ADMR = 0X31;
ADR = 10;
ADR = 0XE0;

3. Read function initialization:
CMDR = 0x10;            // Reset FIFOA and FIFOB
CFG = 1<<6 | 1<<5;   // TLCHLTE =1, IN = 1, FIFOB Only
CNT0 = size & 0xff;    // Transfer count
CNT1 = (size>>8) & 0xff;
CNT2 = (size>>16) & 0xff;
CNT3 = (size>>24) & 0xff;
IMR1 = 1<<4;             // END IE = 1
CMDR = 0X04;          // GO

4. Check ADSR to ensure TNT is an addressed listener -> yes

5. Check NEF bit in ISR3. If set, read data from FIFOB. -> hang here.

Could anybody help me or give me a hint here?
Thanks

[Collin M]

I saw this in your post but it may just be a typo.

2. Set address to 10:
ADMR = 0X31;
ADR = 0X10;
ADR = 0XE0;

You should be writing the two's complement to the CNT registers.

In the hung state can you read STS1 and STS2 and report their values?

[Steve Ju]

Thanks for your prompt reply.

1. It's not a typo, 10 (dec) = 0x0A (hex).

2. The value of STS1 and STS2 is as follows:

STS1 = 0x20;

STS2 = 0x9A;

[Collin M]

First, can you confirm you are writing the two's complement of the byte count to the CNT registers? The two's complement is obtained by inverting all bits and then adding one. See this post for more info on two's complement.

Also, in your initialization routing you write 0x99 to AUXMR. This translates to a write to AUXRA which sets a holdoff on all data. You probably should set the holdoff mode in AUXRA to 00.

[Steve Ju]

I added and checked the macro for 2's complement calculation and I'm sure it's correct.

I set AUXMR to 0x00, however, nothing happened.

When I use LabVIEW write to write 5 data to the GPIB interface, the REM and LSN led is lighting and LA bit in ADSR is set. Then I checked the NEF bit in ISR3, it's clear. It seems that no data arrived at FIFO, is it possible because of the hardware problems?

I used NI488.2 communicator to write data to GPIB, the iberr = EABO and ibcntl = 0, I have no idea about the error message.

[Collin M]

Setting AUXMR to 0x00 is not the same thing as not writing to AUXRA.

When you write 0x99 to the AUXMR it actually writes to the AUXRA. Writing 0x00 to AUXMR pulses the pon message.

The line of code in your original firmware that writes 0x99 to the AUXMR should be removed.

If you still have a problem after making that change please reread STS1 and STS2 and post the results?

[Steve Ju]

I removed AUXMR = 0x99 and insert AUXMR = 0x00, but nothing changed. I noticed that AUXMR and AUXRA share the same address.

The values in STS1/2 and ISR3 do not change and list as follows:
ISR3 = 0x08
STS1 = 0x20
STS2 = 0x9A

[Collin M]

Can you read SASR, ADSR, ISR0, ISR1, and ISR2?

[Steve Ju]

Collin, thanks for your continuous support.

SASR = 0x10
BSR = 0x31
ADSR = 0x54
ISR0 = 0xd
ISR1 = 0x0
ISR2 = 0x13
ISR3 = 0x8
STS1 = 0x20
STS2 = 0x9a

Consulting the TNT4882 Programmer Reference Manual, I feel the state of TNT4882 is not ready for reading. But I don't know where I should change my code.

[Collin M]

Ok, the SASR is 0x10 which indicates the acceptor is in a holdoff state. This makes sense because there is a write of 0x51 to the AUXMR which causes an immediate holdoff. To release the holdoff you should write 0x03 (rhdf) to the AUXMR.