NAT7210 to host data transmission problem

[MaSta]

Hello!

Years ago, our company developed a GPIB interface board, using a NAT7210 GPIB controller which is hosted by an Atmel 8 bit MCU. For a test, the board is connected to a NI GPIB PCI interface, using MAX and NI-488 Communicator for communication.

Everything works fine so far, except one thing: a customer complained about occasionally "distorted" responses to the *IDN? query. We verified this to be true.
The response sometimes contains one additional character. For example, if the response string to the *IDN? query would be 70 bytes (including end token 0xA), sometimes it is 71 bytes and the additional character, which is mostly a ">" (0x3E), is inserted in random position.
Sometimes it's even worse. Then the NAT7210 sends the string twice, making it 139 bytes. This error occurs every few times when querying *IDN?.

The MCU that controls the NAT7210 does not send this additional character. I can verify in the debug mode, that the buffer content that is sent to the GPIB controller is OK and the code is OK, so that sending data is not interfered. We don't have any clue how to stop this. The NAT7210 has no command to flush its output buffer, nor we know if it does automatically after sending the message via GPIB.

Does anybody have any idea what's causing this and how to stop it? TIA

[MaSta]

The damn richt text editor here is broken!

When I start a topic, the button strip above is missing and when I switch to PREVIEW and back to RICH TEXT, the text I wrote is cleared and the topic, too.

[Lunatic]

Hi Maik,

could you describe the conditions the nat7210 is used in?
So every few times the *IDN? is sent, the nat7210 returns strings with additional characters, or repeats to send the characters. After how much querys does this happen?
Can you ensure that there is no noise on the bus?

Greets Markus

And regarding the "damn" rich text editor:
Try to use Internet explorer or firefox with add-ins disabled. Maybe they mess up the interface...

[MaSta]

About NAT7210:

The problem with those GPIB controllers is that there are too many "ORs" in the manuals. "Do this OR do that". Too many options when setting up the config of a controller making it almost impossible to find the right one. We strictly adhered the initialisation sequence as told in the manual. But NI or other GPIB controller manufacturers don't mention a word about timing of the control data between host MCU and NAT7210. I also couldn't find example code for best configuration. 

However, the chip and the GPIB device are working smooth on the bus, except that one single problem. So I doubt if the controller is set up incorrectly.

I can not ensure that there is no noise on the bus, but I only have that one controller chip as talker/listener on the bus.

The number of queries after the problem occurs again is arbitrary. Sometimes 1, sometimes 5, sometimes 10 queries. The frequency of the double string is not so high as that of the additional character.

About rich text editor:

I'm using Chrome. The behaviour with the missing button strip and mode switching only happens when starting a new topic after searching the forum and pressing the blue button "Post" above the search result window. When replying to a thread, everything is fine, even switching between Rich Text and Preview modes. In the other case, the windows contents were deleted when switching view mode.

Best regards,

Maik

[Lunatic]

Sorry to hear that! I already recognized that the documentation doesn't tell you much about timing and stuff.
So you think that you maybe have the wrong timing when requesting the *IDN?
Or did I get you wrong on that point? Do you think that the problem is created by the wrong timing talking to the nat by the mcu or do you think that the NAT7210 messes something up?

Is there any possibility for you to check the bus communication with an analyzer or a scope?
Maybe there's an interruption on the bus and its starting to resend data.
What happens to the bus signal when the ">" is sent?

Regards

Markus

[MaSta]

There is some sort of timing when sending data to the NAT. In a DO-WHILE loop a certain bit from the controller is tested. The bit is read from the NAT in an interrupt routine, which is called after sending one byte.

The host controller has a buffer with the IDN string. That buffer is just sent byte by byte to the NAT, with waiting for that certain bit to be set.

The rest is up to the NAT. The NAT also has a buffer, of course. The problem occurs when the NAT sends the data to the PC, from its own buffer.

So I wonder why the NAT would do that and if there might be something wrong with the configuration. Whereas, all other SCPI commands work fine.

Perhaps, when querying a certain command often enough, the error will also occur, but it definitely occurs with *IDN?.

We can not analyze the bus communication, because we have no hardware for that. The GPIB interface is only a small, unimportant product.

The interruption idea is a start. Problem is, even if I can definitely find out - how to solve? I have a NI GPIB card in the PC, directly connected to our interface running the NAT. The GPIB is standardized, so it has to work. Unless it's a setup issue...

But I will try to measure the bus signals with a scope. 

[Lunatic]

Knowing that I wouldn't think anymore of a problem caused by the communication between mcu and the NAT...

It would be nice to know what happens in the NAT when you query the *IDN? (or any other command) repeatedly!
Is there some kind of stack overflow?

Why are you repeatedly requesting the *IDN? ?

If you try to repeatedly send other commands, is there also a strange behavior?

Maybe when we isolate the behavior, we can find a workaround you're comfortable with

Greets Markus

[MaSta]

I don't know what happens in the NAT7210. This is a client controller, hosted by my Atmel MCU. It just does what I tell by commands.

There are status bits that are read from the NAT after sending a byte, this is all I can see from what it actually does.

Why querying the *IDN? multiple times? In order to test how often this happens. As I said, this is random. The error can also occur with the first and only query.

Other commands are not tested yet, but it doesn't matter. There is one command doing so, and this is not OK. Customers programming application are usually querying IDN string for device detection and indication. They analyse and seperate the string. But with extra characters, this gives errors.

A workaround, well. Would be nice. I still think the setup, the initialisation may be wrong. At least for long strings like with IDN. But then, I suppose, the problem

would occur everytime the IDN is sent.

[Lunatic]

How many board are affected by this behavior?

Please post the results of the scope measurement!

[MaSta]

All boards, of course. This is a software related problem, I'm pretty sure.

But how to solve? The 7210 controllers have too many options. I still suppose there is something wrong in our software, but what is right?

Whether NI nor Measurement Computing provide example code for a talker/listener setup, so I can have a clue what we did wrong.

It could be initialisation, data sending, interrupt handling...