TNT4882 - finding it from MAX

[D521]

RE to: dittohead

Ok, We've made progress here, but I'm still not quite there yet. I have found that there has been an error in the library part of my schematic. the NDACN has been confused with the DACKN. the siganl names for the chip on my part in the scematic have names almost identical, so it was routed wrong and when I checked the pins several times I didn't pick up on the fact that I was actually verifying connection with the wrong signal.

so now when I send the ibcmd "\x23" I don't get an error. I get:
[130] < cmpl cic atn >
count: 1

after that I try to read the ADSR register like you suggested and I keep reading 0. no change to the register after the ibcmd.
I have been able to read other type of registers successfully, plus I've also done a data bus check by writing all combinations (0 to 255) to the FIFO register and reading them back.

any suggestions from this point on?

also, MAX still won't detect my device nor can I open a VISA session.

thanks

[Collin M]

Thats great new, the status after sending ibcmd "\x23" means that the TNT4882 successfully accepted the command byte.

So, the TNT4882 accepted a command byte but it didn't interpret that command byte as its own listen address. You said you were setting the GPIB address of the TNT4882 to 3, can you verify this?

Also, after the TNT4882 has received the command byte (0x23) can you read the CPTR at offset 0x0A? The CPTR stores the last command byte received and it should read 0x23.

[D521]

I've verified the address by reading back the ADR0 register right after I set it to 0x03. also, I'm not detecting any change in the CPTR register. I read in the programer's reference manual that this register has no memory and that this register should be read only during DAC holdoff. For now I am polling this register to detect a 0x23 command, where I assume that my DSP is much faster then the GPIB and I will be able to catch the command. do you think this is OK? It seems at this point that the TNT4882 is not decoding its address. I've verified the connections between the DIO pins of the TNT and the GPIB cable and they seem fine. These pins are routed directly with no external drivers as I understand that with the TNT4882 none are required. Now, the DIO signals are acting strange. I try to detect the 0x23 command with my scope. the only thing that I can detect is DIO2 being asserted (High - Low - High) and DIO7 asserted with a positive pulse (Low - High - Low). I detect no change with the rest of the DIO signals. Also the level of the DIO signals when connected to the GPIB controller when no command is taking place is as follows: (DIO0 to DIO8: 0 1 1 1 1 0 0 1) where high is at 3.5V. What do you make of all this?

[Collin M]

When a GPIB device is addressed to talk or active controller it will always drive the GPIB DIO lines. In the TNT4882, the state of the DIO lines immediately after becoming addressed to talk or becoming CIC is undefined. If your GPIB controller has a TNT4882, as soon as you issue the ibsic command the TNT will drive something onto DIO. When you issue ibcmd \x23, the GPIB controller will drive 0x23 onto DIO, and it will keep driving 0x23 onto DIO until you send another command or it becomes not an active controller.

I forget if the CPTR is a register or just reflects the state of the DIO lines, but after sending ibcmd "\x23" you should read 0x23 from the CPTR because the GPIB controller is still driving that. You can also read the DSR which simply reflects the state of DIO at any time. After sending ibmcd \x23 reading DIO and CPTR should give the same value.

Here is another thing to try. After sending ibcmd \x23 from the controller, read the DSR and CPTR (they should be the same). Then, using a DMM or scope, read the state of the DIO signals. Remember that GPIB signals are active-low, so if a DIO line is at ground the corresponding bit in the DSR/CPTR should be 1. After sending ibcmd \x23, measuring the voltage level of the DIO pins should be as follows DIO8 -> DIO1 (1 1 0 1 1 1 0 0) where 1 indicates ~3.3V and 0 indicates ~0V.

If you measure something different, disconnect the GPIB cable between your device and the controller and measure the DIO signal again on the controller side and the device side, and also read the DSR and CPTR. On the device side they should all be unasserted (~3.3V). On the controller side they should be as stated above.

[D521]

I've detected the 0x23 command on the BSR register coming in but not in the CPTR register. I think the CPTR register is definetly not showing the current status of the IO's. the DIO's when communication is taking place is at a constant (DIO8 to DIO1:10011110). the DSR is showing a 0x61 which is the real bits on the data bus, but the CPTR is always showing 0x14. when the command 0x23 is sent, then the CPTR has some change in it but at this point it's happening too fast and I can't catch the value, however, I know the value is definetly not 0x23 because I'm polling for it. on the DSR it is showing: 0x23 during the command so I know the command is comin in fine. Any thoughts?

[Collin M]

1. Are there any other GPIB devices connected to the bus?

2. After ibcmd "\x23" is successfully sent, you should still read 0x23 from the DSR. Is this correct? What does the CPTR read after the command is sent?

3. After you send ibcmd "\x23", enter the iblines command in ibic. This will tell you what the states of the other GPIB signals are.

4. Can you double-check the routing of GPIB signals other than DIO? If they were in an incorrect state that could explain the problem you are having. For example, IFC continuously being asserted (grounded) would cause the symptoms you are seeing.

5. Can you also read the BSR (0x1F) from the TNT4882 before and after you send the IFC command? This will tell you the states of the GPIB signals other than DIO as the TNT4882 senses them.

6. Can you verify that your firmware is using the correct address (0x0A) for the CPTR?

[D521]

1. there are no other instruments connected

2. I can only read 0x23 during in BSR during the command. its behaving just like cptr is suppose to I think (what's the difference between the two anyway?)

3. using iblines I am reading: GPIB Lines: [52ff] < ATN REN NDAC >. when I read the ADSR i now get 0x3F, which consistent with what I am measureing now on the signals. the states of the GPIB signals from the controller have changed since the last few times that I was doing such a test
4. as far as I can tell, the control signals seem to be fine

5. I read from the BSR register: 0xA1, which seems to agree with the iblines command return of ATN REN and NDAC asserted

6. Yes, 0x0A offset is used for CPTR

[Collin M]

I am assuming you meant DSR instead of BSR in your response #2 above.

In your response #3, you said your were reading the ADSR but I think that is a typo. What register are you reading that is giving you 0x3F? This may be important as the command 0x3F is the UNLISTEN command. If the UNLISTEN command is being sent for some reason that may be causing the TNT4882 to become unaddressed to listen.

Try reading ISR2 in the TNT4882 after after sending the ibcmd "\x23". Look for ADSC (bit 0) to be set. If it is set then the TNT4882 may have become address to listen and then unaddressed to listen.

Do you have an ISR set up in your firmware? What happens if the TNT4882 asserts an interrupt? Are you enabling any interrupts through any IMRs?

Also, each time you send ibcmd "\x23" to the TNT4882, send the ibsic command immediately before. This should initialize the TNT4882 to a known state.

In response to your question about DSR and CPTR, the DSR reflects the state of GPIB DIO signals at any given time. The CPTR should store the last command byte received and parallel poll responses, which you are not doing. If the GPIB controller is only sending one command byte "\x23", then reading the CPTR and DSR should give the same value, 0x23. The BSR reflects the state of the 8 GPIB control/handshake signals.

[D521]

Yes, you were right with both assumptions regarding the typos

[Collin M]

Just wanted to clarify that I had a few suggestions/questions in my last post in addition to clarifying the typos.