TNT4882: No interrupt on NEF

[SteveW]

I have set up a TNT4882 in an embedded system to interrupt on "FIFO not full" (IMR3 bit 2 is set). My bus controller (a GPIB-USB-B) sees the interface, and recognizes its address, but that is as far as I can get. No interrupt is generated, and the controller generates a timeout message (error EABO). I am using a Rabbit 3000 processor running Z-World Dynamic C. My TNT4882 initialization code is attached. Any ideas?

Thanks,

Steve

[GPIB_Guru]

Steve,

I think you are almost there. I just have three comments:
1) You don't need to clear KEYREG. This is done at PON for you automatically.

2) I think the reason you are not receiving any interrupts is because you haven't programmed a count into the CNT registers. Until you program a count, the TNT will not accept any data bytes. If it doesn't accept any data bytes, it will not generate an interrupt on the FIFO having data in it. If you just write (for testing) to CNT0 a value of 0xFF and CNT1 a value of 0xFF, you should accept 1 data byte into the FIFO and generate an interrupt. Note: The CNT registers take in the 2s complement of the transfer count.

3) One thing to note: If you ever do enable ISR0 interrupts, make sure you always write bi
t 7 as a 1 or else no interrupts will be generated from the TNT.

Good luck.

[SteveW]

GPIB Guru,

Thanks for the response. I do put a count into the CNT registers prior to sending data, but I was not aware that CNT had to be set in order to receive messages. I just added setting the count registers in my initialization routine, and I still don't get an interrupt when I try to receive data. I also am monitoring ISR3, and it shows the FIFO as always empty.

Thanks again for your help.

Steve

[GPIB_Guru]

Silly me. I forgot to add a couple more things. You need to treat this as a full data transfer, including writing GO to the CMDR to start the data transfer.

[Collin M]

Can you read ISR3 and see if NFF is set?

[SteveW]

Hi GBIB Guru,

Thanks to your comments and those of Dittohead, I got pointed in the right direction and now have communications. Thank you. However, I'm not quite there yet. I now have two problems:

1. Done - I can't get the Done function to work properly. I am currently ending reading of the FIFO based solely on NEF. This works for the moment, but I suppose that if data arrived slowly for some reason, doing this may curtail prematurely. I can't seem to find the trick to detect an EOI following the last byte.

2. Bus Controller Write vs. Query - If I just send queries from my bus controller, everything works as planned. However, if I write data (i.e., send something to the TNT4882 without expecting data back), it works only on every
other attempt. On the one attempt, I get "iberr = ENOL", and on the next attempt all is well. I can't see what I'm setting differently in either case. In the case of the error, an interrupt is not being generated, so my code should not be writing anything to the TNT registers.

Any ideas will be greatly appreciated.

Steve

[SteveW]

Hi Dittohead,

Your suggestion to monitor ISR3 helped lead me in the right direction; thanks. Please see my note to GPIB Guru for my current status.

Steve

[GPIB_Guru]

For reads, you typically interrupt on STOP and END (if you interrupt on END, you also need to set TLCINT in IMR3). DONE is only true if the TNT is stopped and the FIFO is empty. So, you need to interrupt on STOP (byte count is satisfied) or END (last byte received). When you do interrupt on END, you will need to stop the TNT (CMDR register, I believe). Once the TNT is stopped (for either reason), you will empty out the FIFO and then DONE will set.

I am surprised you would get ENOL. That means that there is no listener, which is odd since you are trying to read from the device. What NI-488.2 API call are you getting ENOL from? If you are getting it from ibcmd, it may be that you are doing an NDAC holdoff on the command byt
e? Just a thought. You can look at some of the status registers to determine this. Let me know if this helps...

[SteveW]

Regarding the end issue, your idea of interrupting off of END RX seems good, but handling multiple interrupts in what should be a simple system seems like an overkill. I tried keying off of GSYNC because it is latched, but it never set, and I don't know why. Note that I am not waiting to read from the FIFO until STOP, because what happens if the message is longer than the FIFO is deep? It seems like the FIFO should be read until an EOI is received, then the TNT stopped. What am I missing?

Now to the ENOL. I'm not sure how to answer your question about the API. What I am doing is using a NI GPIB-USB-B as a bus controller, which is connected to a board of my design containing the TNT4882. This board will control high-pow
er RF amplifiers. For bus controller software, I am using the simple "NI-488.2 Communicator" that came with the controller. The only message I get in addition to the ENOL code is an explanation stating that no instrument was detected. I am evidently changing something on every-other pass, but I can't find it. This shouldn't be difficult!

Thanks again for your help.

Steve

[GPIB_Guru]

What you are missing is that the State machine that handles the FIFOs is different from the state machine that handles I/O from the bus. The bus state machine automatically does a holdoff on END (if you configure it to), but the FIFO state machine is still running. The STOP command tells this state machine to stop. Therefore, you typically interupt on STOP (in case the byte count has expired) or on END (in case END is received). In the case of STOP, the TNT is stopped. In the case of END, the TNT is just in a holdoff and still needs to be stopped. You can set the TLCHLTE bit, which will automatically cause the TNT to stop whenever an enabled interrupt in ISR0, ISR1, or ISR2 is generated. That may be somethin
g that will simplify your interrupt handler. You will still need to read the ISRs to see what the interrupt was so that you can handle it properly (i.e., did you get END?).

ENOL indicates that the GPIB addressed a device to listen (i.e., you did a write operation) and both NRFD and NDAC were unasserted. You may need to check your logic or use a bus analyzer to see what may be causing this.