nat 7210 dual addressing problem

[Rona]

hi

I am working on embedded gpib device.

Our implementation is using the nat 7210 in dual primary addressing mode.

With the last byte of my messages I send EOI to the CIC.

My device can be only talker or listener.

My problem  is that if I swirch between the 2 adresses using read and there is data in the second device address buffer my first byte is received from the previous device and then I get the rest of the message from the correct address.

For example if I get 1245 the 1 belongs to the previous address.

Reading continuesly from the same address is OK.

The byte that was transfered will be missing from the next address and so on.

It seems that the first interrupt is using the old address.

Does any one can think of a reason?

Thanks

Rona

[ScottieB]

There's no concept of a "buffer" in the 7210...You just read from the CDOR a byte at a time.  Unless you're doing DMA, in which case you would see the data in memory all at once.  So I'm confused by your use fo the term "buffer".  Are you using DMA?  Or is this some internal software buffer?

You should be able to tell pretty easily which PAD has been addressed as a listener by examining the MJMN bit in the ADSR prior to reading each byte.  Are you doing this?  When?

Scott B.
GPIB Software

[Rona]

hi

Maybe I did not explain my self good enough.

The buffers are SW buffers and we made 2 buffers one for "Minor" primary and one for "Major" primary.

When we receive interrupt from the NAT7210 we first look at the MJMN  bit to determine which address we need to serve.

When the messages are coming from the same address everything works OK . but when we do a read from the "Minor" and the next read is from the "Major" the first byte is sent from the "Minor" buffer and then we receive the rest of the "Major" buffer as we expected. the problem is the first byte that comes from the wrong address (buffer).

It is like the NAT7210 changes the MJMN bit only after the first interrupt.

[Collin M]

Is it possible that there is a byte loaded into the CDOR, but that byte is not transferred because the bus is readdressed?

For example, one of the addresses has the following data to send "ABCD". It sends "AB" and then loads "C" into the CDOR but does not send it because the controller has asserted attention. The controller readdresses the bus. The other address has the following data to send "WXYZ". "C" is still in the CDOR so it sends "C" and then "WXYZ", so the listener receives "CWXYZ".

Is it possible that the NAT7210 is being readdressed while it still has data to send from one of its addresses?

[ScottieB]

I see what Collin is saying, but I think I confused the matter by talking about the CDOR.  In fact, we're talking about the CDIR, right?  Because this is when the NAT is receiving data from the GPIB?

I think this is what you're doing, please correct me if I'm wrong:

-You setup dual addressing at, say, PAD 4 and PAD 5.
-Your controller begins to write "ABCD" to PAD 4
-You do a read of the MJMN bit and see that it's the Major addressed as a listener.  You read the CDIR and get A, B, C, D.
-Your controller now writes EFGH to PAD 5.
-You read MJMN, see that the Minor address is listening, and read the CDIR 4 times to see E, F, G, H.

At what point are things messing up and going awry?

Scott B.
GPIB Software

[Rona]

hi

the problem is from the device to the controller so CDOR is the right term

Rona

[Rona]

I do not think that I send more data.then i need

My interupt code for the minor output is:

if (Results_buffer_out_counter < Results_buffer_in_counter) 
 {
     temp = Results_buffer[Results_buffer_out_counter];                  /* get the character to send  */
     if (temp == LF)                                                                              /* see if it's the end of message */
     {     
         send_eoi();                                                                                /* send EOI if end of message  */
     }  
     CDOR = temp;                                                                              /* send the byte of data               */
     Results_buffer_out_counter++;                                                    /* inc. the pointer   */
 }

Line feed is the last byte I think I send, it is the last byte of my message.The next byte is the problem. If after message is received at the controller, the controlleri changes from Minor to Major, the Major answer contains the first byte of the next minor message and then the Major real answer attached.

like id the Minor always sends ABCD and the Major EFGH it will look like:

ABCD,CR,LF (Minor)

AEFGH,CR,LF (Major)

BCD,CR,LF (Minor again....)

and so on....

Rona

Message Edited by Rona on 02-25-2006 11:42 PM

[GPIB_Guru]

With the 7210, I recall that you get an interrupt after every byte has been transferred. Is it possible that when the linefeed is sent that during the next interrupt you are putting a data byte into the CDOR register, even though the reply message has really been completely sent?

[Rona]

Hi

This can be the problem...

Is there a way to detect this interrupt and seperate it from data request interrupt?

Rona

[GPIB_Guru]

Typically a device would have a state machine that dictates when it is ready to send a data byte or when it is not ready to send a data byte. A 488.2 device follows the Message Exchange Control State Machine (chapter 6 of the IEEE 488.2 standard) which dictates when it can talk and when it can listen. Essentially, IEEE 488.2 fixes your specific problem by not allowing the device to respond unqueried. In other words, if the host wishes to read data from the device, it must first send it a query and then it can read the response. Therefore, when the device has sent the last byte (LF+EOI), it knows that it has to receive at least one data byte before it would send another reply. This type of thing would fix your problem.

If this is not possible, let me know and I can think of other options. None of them are really super, but there are some options if you need to reply without a query...