Why is my USB 8451 raising errors after working correctly?

[Daklu]

I'm using a USB 8451 to tap into an existing I2C bus.  This bus already has one master and three slave devices on it.  Periodically I use the 8451 to read or write the registers from one of the slaves.  The issue I am facing is that my application starts correctly and works for a period of time.  However, eventually the 8451 will generate one of four error codes and cease working.

The error codes I'm seeing are:

1. 301706 - Invalid device reference
2. 301721 - Unknown status code
3. 301740 - USB-8451 failed to seize the bus
4. 301742 - USB-8451 is not responding

It turns out the original master on the device doesn't play perfectly on a multi-master bus.  I believe error code 301740 is related to that.  I don't understand why the other errors would occur after the device has been operating correctly.  Any ideas?

Thanks,

Dave

[Andy L]

Hi,

It sounds like the first master on the bus is a singlemaster and does not support busy BUS detection.  As a result the USB 8451 is being interrupted causing unpredictable results.  You might want to try running NI-Spy to monitor the communication on the BUS to see what command stops the USB-8451 from responding.  NI-Spy can found by going to Start>>Programs>>National Instruments>>NI-Spy.  I have also attached a Performing a Good NI-Spy Capture for Debugging/Troubleshooting article that will help you better interpret the NI-Spy data. 

Regards,

[Daklu]

Thanks for the response Andy.  Unfortunately NI Spy didn't tell me anything I couldn't figure out for myself.  ("Could not perform operation because of I/O error.")    Maybe you can make something more out of it.  I hooked it up to a usb tracer and all I can see from that is that the usb host times out after ~30 ms and resets the 8451.  You can see the timeout on the Spy capture on line #121, viWaitOnEvent.

I connected the I2C lines to a decoding oscilloscope and I couldn't find any data transfers being blatently stepped on by either the embedded host or the 8451.  The only thing that comes close is the 8451 sending a restart condition and taking control of the bus from the embedded host.  This only happens when the host is writing a packet to a specific slave ('P').  These particular packets almost never conclude with an end condition.  The host *usually* sends a restart right away.  Several times I have seen where the 8451 issues its own (re)start condition and addresses the slave ("R") I am communicating with through my vi.  I'm not positive this is related to the errors I have seen.

With the errors I am getting is it possible to reinitialize the 8451 on the fly without forcing the user to disconnect and reconnect it?

[Andy L]

Hi Daklu,

I did not recognize anything out of the ordinary from the NI-Spy capture other than the I/O error, which you figured out on your own. In regards to your question about reinitializing the 8451 without unplugging it, the only other alternative that I can think of is to scan for hardware changes using windows device manager.  Doing this will take it off the network and give up control to the other master so I don’t know if it is an option for your application. 

I think you identified the issue in your original post when you said the original master on the bus does not play perfectly on a multi-master bus.  Is there a way you could modify the original master to support busy BUS detection?

Regards,

[Daklu]

Unfortunately it isn't feasible at this point to modify the original master or disable it for the testing I'm doing.  I'll work with it as is.

Thanks for looking into this for me Andy.  I appreciate your attention and timely responses.

Dak