Instrument Control (GPIB, Serial, VISA, IVI)

cancel
Showing results for 
Search instead for 
Did you mean: 

TNT4882 - finding it from MAX

OK, in that case we have a problem.

I have now detected very strange things and apperently I am shocked to find out that I am actually not reading back the register in that instruction that follows the setting of the ADR0. I won't go into it but I saw the assembly equivelant and I now see the problem. I changed some stuff so I now am really reading ADR0 and I am not reading back 0x3 but 0x01. there seems to be a contant 0x01 in ADR0 register. if this is so, why didn't MAX detect a device at address 1. any thoughts?
0 Kudos
Message 41 of 65
(1,729 Views)
Have you tried doing a scan for instruments after you read 1 from ADR0? Be sure to set the GPIB controller's primary address to something other than 0, 1, or 3. You can set the controllers primary address with ibpad n, where n is the primary address.

Also, have you reviewed the assembly to be certain that you are writing 3 to the ADR0?

Could this problem with the compilation affect any other register accesses?
0 Kudos
Message 42 of 65
(1,726 Views)
It doesn't look like I have any other problems, I know what was the cause of the problem so I can verify that evertything else is fine. I've probed the data, and addr bus between the DSP and the TNT4882 with the WR and RD signals. I've verified with the scope that I am writing the right values to the registers. I've checked when writing to the admr and adr registers. when I read back the adr register, I do see that I am reading a 0x01. just as I am seeing in the code. I see that I have no way of verifying admr since its a write only register. It seems that the 0x01 in the ADR0 is constant. I tried setting the ADR0 to 0x08 and I still read back 0x01.
0 Kudos
Message 43 of 65
(1,720 Views)
Are you able to capture the state of the entire bus between the DSP and TNT with a logic analyzer? It seems that there may be a problem here that may also cause problems elsewhere.

I do know that if you write 0x03 to offset 0x0C, and then read offset 0x0C you should read 0x03. If not, there is a fundamental problem somewhere.

It seems the best way to proceed is to capture the write and read cycles with an logic analyzer.

Do you have any other of your boards you can test?

Also, when you do a scan for instruments while you are reading 1 from ADR0, does MAX detect anything at address 1 or any other address?
0 Kudos
Message 44 of 65
(1,715 Views)
When I scan for instruments, it only finds the device at 0 (not device at 1)

I've actually captured the data with a digital scope. seing each bit with respect to the WR signal. I did this for every bit (out of the D7-D0) I see all of the data bits making transitions at the same point. I don't really have access on the board to capture all of the data at once with a logic analyzer, but I think what I've done with the scope is basically equivelant, sometimes it's actually better because I see a more realistic picture of how the signals look like. I didn't try this on another board simply because getting the board to this point requires some work, but I can tell you that through out this past week I've replaced the DSP once and the TNT4882 twice. Is there some state or mode that the TNT4882 won't enable to write into the ADR0 register?
0 Kudos
Message 45 of 65
(1,713 Views)
There is no mode I can think of that would prevent writes to the ADR. I am also concerned that whatever problem is occuring could affect other things. From what I understand you still need to finish writing the firmware for this device.

What is the model number of the DSP you are using. I'll take a look at the datasheet and see if anything jumps out at me.

Also, did you consider the setup/hold times for the TNT? Data not being setup or held long enough relative to RD/WR and CS may cause this type of problem. If you have at least a 2-channel scope you can also measure this.

Have you tried writing something other that 3 to the ADR? You can try different values and then do a scan for instruments to see what value was stored in ADR0. That may reveal some pattern.
0 Kudos
Message 46 of 65
(1,708 Views)
I am not at my work place now but here is some more info/thoughts. maybee by tomorrow you or I will have a idea of what can be wrong.
when I probed all of the data , address, rd and wr I was also looking at the timings. I didn't take down exact timings but in general it seems that I have quite a slack on the obvious parameters; for example the wr goes down before data is available and the wr goes back up (trailing edge) to lock the data. the data stays quite a while on the bus after the trailing edge of the wr signal. Also, don't forget that it seems like I am definetly writing and reading/verifying most if not all of the other registers; e.g the counter registers that you asked me to check. I've tried basic stuff way in the beginning like with pon not cleared, I sense no activity on the GPIB bus so I know I'm writing to that register (forget which one). Now that I am detecting my device at address 0, and I send the \x20 command, I read in the adsr that I am addressed to read, so I know I am reading that register and the others.
I am using the TMS320F2812 DSP from TI in case you think it may help you. Also, I was wondering, is it possible that if I was by some reason not entering one chip mode for something like this to occur, like if I was in the 9914 mode. I know that the registers are different, I don't have the registers table to cross reference.
0 Kudos
Message 47 of 65
(1,702 Views)
In your firmware you can delete the following two lines of code. They should have no effect on your firmware but shouldn't be causing any problems.

TNT4882[R_auxmr]=0x80;
TNT4882[R_auxmr]=0x99;

The MODE pin on the TNT should be left unconnected to select 7210 mode, can you verify this?

Also, the datasheet for your DSP specifically states the DSP inputs are not 5-V tolerant. Do you have a voltage translation circuit between the TNT and DSP?

Are there any other devices on the bus between the TNT and DSP?
0 Kudos
Message 48 of 65
(1,687 Views)
I've checked the MODE pin several times and I've verifyed that it is not connected.

You are right, the DSP is not 5V tollerance, I was concerned about that in the beginning when I realized this, however the tnt4882 is outputting about 3.6V and not 5V, which should be well within the spec of the DSP.

Yes, I do have some one on the same data,address busses between the TNT and the DSP - it's a SMSC LAN91C111 (ethernet MAC). I've had a concern about that also, but because I believed that I am writing and reading into the registers with out any problem, and I've probed the signals and they look good, I decided not to do anything until this morning. just in case, I am having this chip remove as I am writing this. I'll see if it has any effect shortly.
0 Kudos
Message 49 of 65
(1,685 Views)
The GPIB-side signals will be driven to about 3.3V but the TNT should drive the processor-side signals to the TNT core voltage, typically 5V. Are you measuring the voltage when the TNT is driving? Driving 3.3V to the TNT from the DSP should be ok because the TNT Vin-high can be anything down to 2.0V.

The maximum Vin-high for the DSP is still only 3.47V so even 3.6V may be a problem.

Are there any unused processor-side outputs of the TNT you can measure the voltage of? Sometimes CPUACC or RDY1 may be no-connects. I would expect these to be at 5V.

Can you ask TI what the implications are of driving 5V to the DSP?
0 Kudos
Message 50 of 65
(1,679 Views)