Unable to configure 7210 as an active controller and CO bit not getting set

[500017]

Hi collin,

     I am developing a board with Atmel 90S2313 microcontroller with NEC 7210 gpib controller chip.

I followed the procedure given in the manual of NAT 7210 ( chapter 5 and 6).   i configured 7210 in active controller mode as follows:

  chip reset (set pon) ) 0x02 to AUXMR

  no addressing mode 0x30 to AUXMR

 disabling the interrupts  0x00 in IMR1 and IMR2

 reset pon 0x00 to AUXMR

ldi AUXMR,0x1E  ;set IFC

   delay

 ldi AUXMR,0x16  reset IFC

[HERE I AM ABLE TO GET THE ATN* ASSERTED AND IFC UNASSERTED AS EXPECTED]

[I CUD EVEN GET CIC BIT IN ADSR REGISTER HIGH]

but as per the manual, the CO bit in ISR2 must be set when it is configured as an active controller.

I am unable to send the addressing commands mta0 and mla5 as CO bit  is to be monitored for sending them.

i am struck up at this CO bit ... (being not set)

please  help me to solve the problem.. I need to submit the project within 3 days..

[Andy L]

Hi,

For questions about programming the 7210 GPIB chip, please use our Request Support page to send an e-mail to our GPIB support engineers.

Regards,

[Steven_T]

500017,

As you can probably see from the 7210 manual, the CO bit is supposed to set when CACS & SGNS & ~nba (page 3-56).

Since the controller in charge bit is set, you should be CACS.  This alone should transition you to SGNS.  We should check the other status registers to see the current configuration.  Please post the values of ISR0, ISR1, ISR2, BSR, SASR. 

This should give us enough information to debug the issue further.  The only other question is if there is a byte currently available.  If you have a byte available it should show up in SASR (a paged register at offset +5).

I hope this helps,
Steven T.

[500017]

Thank u for the guidance,

I am now getting theCO bit set . But my value of ISR2 register is 1E that menas the REM ,LOKC and REMC are also set. Is it correct to get them set? Because I never enabled the remote mode.

Can we make 7210  as addressed talker by sending MTA command to gpib device? (made it as the listener by through MLA command). I mean how can we use MTA and MLA commands?

And also, can we directly send the multiline interface messages to the device without configuring it as the addressed listener while the 7210 is acting as an active controller?

Kindly clear my above doubts..

Thanking you

swathi

[500017]

Hi,

    I amdeveloping a board with NAT7210 and a microcontroller. I am able to configure NAT7210 as active controller and trying to send the multi line interface messages like DCL to the gpib device. Before the first byte transfer CO bit in ISR2 was set. But after the first byte transfer, inorder for sending the next command, the CO bit is not setting and also the condition of the handshaking lines are as follows:

DAV* -not asserted

NRFD*-not asserted

NDAC*- asserted

This indicates that the handshaking has not taken place and the device has not accepted the byte, since the controller did not make DAV*low after detecting the NRFD* high.

Please helpme to solve this problem.

[Steven_T]

Hello Swathi,

What did you change to get the CO bit set (or were you getting it set the whole time)?  The other bits mean that you were in local mode, but changed to remote at some piont.  Are you clearing these interrupt bits (REMC and LOKC) manually or do they clear when reading ISR2 (what is the state of SISB)?  I would need to know this information before knowing if that state is expected.

MTA and MLA commands will configure the instruments ont he bus to behave as talkers or listeners.  One of other posts has steps taken to perform communication (including sending the MLA and MTA commands).  This post is completely correct.

When sending multiline interface messages, many of them will only affect instruments addressed as listener (DCL, SPE).  You will need to configure the devices as listener for them to react to some of these bus commands.

Also for your next post, what are the values of the registers I asked for in my first post on this thread?  These will go a long way in helping us figure out this problem.

I hope this helps,

Steven T.

Message Edited by Steven T on 11-12-2007 09:24 AM

[500017]

Hi,

    Thank you for your prompt reply. In the first post, the values of ISR2  was 0x1E and ISR1 was 0x00.

After getting your reply, I changed the program and this is the actual procedure I followed now and the results that i got.

ldi AUXMR,0x02  ;set pon

ldi ADMR,0x31  //normal primary addressing

ldi ADR,0x00  // loading ADR0 with primary address 0

ldi ADR,0xE0  //disabling ADR1

ldi IMR1,0x06// setting CO interrupt and clearing all others
ldi IMR2,0x08// setting DO bit and clearing all others
ldi AUXMR,0x9C ;source handshaking normal in AUXMRA

ldi AUXMR,0xA0 ; T1 delay >2micro sec AUXMRB

ldi CDOR,0x00; emptying the CDOR

ldi AUXMR,0x00; clear pon

ldi AUXMR,0x1E  //set IFC

ldi AUXMR,0x1F //REN (since i read that some commands respond only in remote state)

wait for CO bit to set  --- I got ISR2 register value at this point as 1E and CO bit got set

ldi CDOR,0x3F // Unlisten UNL

[But there is only one device on the bus]

wait for CO bit to set

ldi CDOR,0x25  // MLA 5

wait for CO bit to set   ...........................My code got struck up at this point waiting for CO bit to set and the DIO lines have 25 on them and  DAV* not asserted, NRFD* not asserted and NDAC* Asserted.

[Does this mean that the command MLA5 is not accepted by the device?? since the program got struck up at this point while waiting for CO to set??]

ldi CDOR,0x14 // DCL

...........................................

I dont understand why the CO bit is not setting for the third time which stopped me to proceed further????

............................

Also to my surprise, if I write the first command to CDOR as MLA5 instead of UNL , the program is strucking up at the first byte (MLA5) read itself..

 Does it mean that MLA  command is not accepted by the device??

If the device accepts the MLA and DCL and respond to it, my work will be completed.

So please help me to cross this hurdle..

2.  And also, how does the device indicate that it has accepted DCL command? How can we recognise that?

Thanking you

swathi

[Steven_T]

Swathi,

Sorry for the late response.  On page 6-5 of the manual "Sending Remote Multiline Messages" item 1 doesn't look like it is happening in your code.  NTNL should be 1.  You are correct about the CO bit.  It is not set if the command byte has not been output.  You can find out about this by the status of the handshaking lines.  It would be best if you had an analyzer of some kind so that you can see the status of each of the handshaking lines.  This way you can compare the lines when a command is sent vs when the command is not sent.

I would also recommend exactly there is no reason to set REN if you only want to become the active controller on the bus.  Page 6-4 in the manual shows how to transition between each of the controller states.

Good luck!
Steven T.

[500017]

Hi

Thank you for your suggestion, but i dont have an analyser to check the signals. I have been reading the status of the lines in CRO and multimeter.

It looks like my code sequence is correct and is according to the Ref manual itself. I  will anyway change the REN line . I sent that command REN because it was written in the device's(HP34401 multimeter) manual that some devices repond to the commands like DCL only in the remote state.

Actually it is enough for me if i can make my device respond to just one simple command like DCL. I could send the UNL because the CO bit got set after i sent that command. But I am struck up while sending the MLA5 command as CO bit is not getting set after sending the MLA5 command on the DIO lines.

Does it not mean that my device is accepting the first command UNL, but not the second MLA? What could be the problem for the device for not accepting my send command MLA? I could not trace it out. Can you please suggest some method in which i shud proceed to fix this problem. Please tell me a simple  procedure to send just DCL command to the device . I think it will be enough for me if  I can get atleast that done.

And also Can we flush the commands directly by giving the delay between the commands, manually, i mean in the code, without waiting for the CO bit to be set?

                                      Please help me as soon as possible!!

                                                                                                      Thanking you,

                                                                                                            Swathi

[Steven_T]

Swathi,

I looked through your register accesses again and realized something that could be happening.  You are clearing the CDOR in your initialization (0x00).  This is not necessary and could actually result in trying to output the 0x00 GPIB command. 

I also noticed that you asserted IFC, but never deasserted it.  The chips instrument's behavior for receiving IFC and a GPIB command is probably undefined.

Please unassert IFC after at least 100us.  Then the instrument will probably respond correctly to your GPIB commands.  If you had posted the status registers I asked for, we would have been able to see that IFC is still asserted while you are trying to send command bytes.

I hope this helps,

Steven T.