We are designing a daughter card which will enable our embedded product to communicate over GPIB. This GPIB daughter card must be able to receive the SCPI message send out by GPIB system controller and reply the message. In my current setup, system controller is a NI-488.2 PCI card installed in a PC running Windows XP.
On the GPIB daughter card side, we have NAT7210 with 75161 and 75160 transceiver chips. NAT7210 is connected to the Static Memory Controller (SMC) interface of an Atmel ARM9 running embedded Linux OS. We are using the Linux GPIB library from sourceforge - http://linux-gpib.sourceforge.net/ .
At the moment, NAT7210 chip initialization stage seems to be successful. Using the Measurement & Automation Explorer software that comes with the NI GPIB PCI card, it is able to detect the GPIB daughter card; the pad and sad values are correct. However, NAT7210 chip didn't manage to receive the *IDN message from system controller.
Below is what I did to Initialize the NAT7210:
1) Set 0x99 in SPMR register. To ensure that we are in 7210.
2) Set 0x02 (Chip Reset Aux command) in AUXMR. To assert local pon message.
3) Skip the step which sets the ICR and ICR2 registers because we are using the default clock 8Mhz.
4) Set 0x31 (Dual addressing mode) in ADMR register.
4) Set 0x01 in ADR register.
5) Set 0x40 in SPMR. Initial serial response. I'm not sure what are the reasonable values to set here.
6) Set 0x07 in hidden PPR register. Do not participate in Parallel polls.
7) Set CHES and NTNL bits in AUXRG register.
😎 Set 0x51 (hldi Aux command) in AUXMR register.
9) Enable interrupts; IMR0 = 0xC5, IMR1 = 0xBF and IMR2 = 0x4F (No plans for DMA transfers).
10) Set 0 (pon command) in AUXMR register. Final step.
Contents of NAT7210 Linux config file:
minor = 0
board_type = "gpib"
name = "gpib0"
pad = 1
sad = 96
timeout = T3s
eos = 0x0a
set-reos = yes
set-bin = no
set-xeos = no
set-eot = yes
base = 0x70000000
irq = 45
dma = 0
master = no
Any ideas on what might be the reasons NAT7210 did not manage to receive the *IDN message from system controller?
Solved! Go to Solution.
I'll try to attach a few screenshots of the GPIB signals captured using logic analyzer. The probes are attached to the NAT7210 pins.
I have a test program running on the Linux target before I attempt to send the *IDN? message from system controller (NI 488.2). Basically what this test program does is it has a infinite loop which will poll the status by calling ThreadIbsta().
If LACS bit is set, then start a gpib read by calling ibrda().
Else if TACS bit is set, then start a gpib write by calling ibwrta(). Just send out a few hardcoded characters.
Else if CMPL bit is set, then display what is received from the system controller if we've started a read previously.
Else do nothing. Go back to beginning of the loop and start over again.
Shows that the SRQ line is asserted only once during NAT7210 initialization stage. After that, it remains always high even when the system controller perform a read on the NAT7210.
Zoom in to look at NRFD, NDAC and DAV signals.
Shows what is happenning on the NAT7210 side when system controller (NI 488.2 PCI card) sends out the *IDN? message. ATN line goes low, I think this is the expected behaviour. REN line is always low.
Managed to coax NAT7210 to send out some hardcoded text today.
However, NAT7210 did not manage to receive *IDN? message from NI-488.2. The DI bit in ISR1 does not get set.
Below is the latest initialization steps I'm using.
1) SPMR = 0x99 /* ensure in 7210 mode */
2) AUXMR = 0x02 /* 7210 chip reset */
3) ADMR = 0x31 /* set ADMR to Normal Dual Addressing */
4) ADR = 0x01 /* Load primary addr = 1 and 0xE1 */
5) ADR = 0xE1
6) SPMR = 0x40 /* Initial serial response. Not sure what to set */
7) AUXMR= 0x70 /* Access hidden PPR. Do not participate in Parallel polls */
😎 AUXMR = 0xE0 /* Clear AUXRI */
9) AUXMR = 0x49 /* Set CHES and NTNL bits in AUXRG register. */
10) AUXMR = 0x51 /* hldi Aux command */
11) Enable interrupts; IMR1 = 0xBF and IMR2 = 0x4F (No plans for DMA transfers)
12) AUXMR = 0x50 /* Page-in */
13) IMR0 = 0x80 /* Set GLINT */
14) AUXMR = 0 /* pon command */
Any ideas why the DI bit in ISR1 doesn't get set?
When a data transfer occurs, the controller in charge must notify the instruments on the bus about which primary addresses are listening/talking...this is called addressing.
When you attempt to send *IDN? from the NI board to the NAT7210, what error is received by the NI-488.2 software. You can capture this information by using NI-Spy. Please attach the .spy file so I can see the exact error. This will be able to show if the controller thinks that the addressing worked correctly or if other problems happened.
On the NAT7210 side, I would like to see some of the status registers when your application notices that the DI bit is never setting.
This may be enough to tell where the problem is happening.
Steve, thanks for your input.
It turns out that disabling functions that prints debug messages in the library solves the receive problem.