8451 "timeout expired before operation completed"

[groz]

I'm using the NI-8451 to communicate with an I²C device (24LC16B). Everything works fine on a good unit. With a bad device, I get a "timeout expired before operation completed" then the 8451 disconnects itself from the PC i.e. just like you removed the USB cable. In order to recover, I have to remove the USB cable then reconnect it followed by a software re-init process. The I²C signal levels are within norms...

The below is the general flow for the write script for reference (note, works just fine on good units):

1) Set clock rate-> ni845xI2cScriptClockRate
2) Issue start-> ni845xI2cScriptIssueStart
3) Write 7-bit address and direction bit 0 (write)-> ni845xI2cScriptAddressWrite
4) Write the I2C lower Address and Data bytes-> ni845xI2cScriptWrite
5) Issue stop condition-> ni845xI2cScriptIssueStop
6) Set Milli-Sec Delay After Writing Byte-> ni845xI2cScriptDelay
7) Run the script & capture errors-> CommandStatus = ni845xI2cScriptRun

After executing, I'll get a timeout error which I can handle. What I cannot handle, is dealing with the 8451 device disconnect. It appears that the 8451 uP is getting locked in a state that the pc responds to by disconnecting it. Is there a firmware issue?

Here are some things I've already tried:
1) Tried using another "powered" hub
2) Shut off power down options on root hub
3) Reviewed event logs, no issues
4) Scanned forum..etc for clues

By the way, on a good unit I can program and verify the entire device..etc.

Please, let me know if anyone has suggestions.

Thanks
Mike

[EricS.]

Hi Mike,

There was a firmware update a few years ago, but I'm not sure if this would be something fixed by it.  Any Rev C or newer will have the corrected Firmware.  Can you check what revision of the 8451 you have? The part number of the device will be in the format 0000000X-000 where X is the revision.

If you do have a rev B, in need of a the update, can I have your permission to pull your email from our database and send you the firmware update information? You could either do this or call NI support to get it.

Also, what version of the 845x driver do you have installed?

[groz]

Eric,

The driver was at 1.1.2 (reported under Measurement & Automation Explorer->Software). After upgrading to 1.1.3, the problem is still the same i.e. 8451 disconnects from PC.

Here is the info printed on the 8451:

PN: 192317D-02L, SN: 0147E7CF

Since its at Rev D, the firmware upgrade should not apply. In addition, the NI845x.dll under windows/system32 is at 1.1.2.3000.

Its hard to find a work around as one does not expect the module to disconnect itself from the PC. I'm pretty confident the disconnect is occurring within the script process. I say this because the device disappears from Automation Explorer before acknowledging the timeout.

P.S. - you have my permission to contact me through email.

Thanks
Mike

[EricS.]

Mike,

Do you have an other USB-8451s?  I found an old service request with the same question, getting the same timeout error (most other questions and forum posts about resetting the 8451 were after random hangs, not a specific timeout error).  The previous question resulted in an RMA, and with a new 8451 the device did not disconnect after the timeout error.

If you have another 8451 to test, please try it and let me know.  

[groz]

Eric,

We just got another 8451 in today and tried it out. I'm getting the same problem i.e. disconnects itself from the PC.

Any suggestions as to why the module would ever do this?

Mike

[EricS.]

I don't actually, I'm going to forward this question on to R&D and will let you know when I hear back from them.

There may be one other option as well.  When this timeout occurs, can you check the Windows Device Manager?  After the unit times out, it disconnects itself from the computer and no longer appears in MAX.  Can you see if it also removes itself from the Device Manager?  If it is no longer present in the Device Manager, try doing a "scan for hardware changes" and see if the unit re-appears.  If it does, you should be able to start your tests again without needing to physically un-plug the device.

[EricS.]

Also, could you please do two things the next time you run a test:

take an NI Spy Capture (From the start menu go to Programs»National Instruments» NI Spy.  This tool monitors all of the VISA driver calls that are happening on your computer (you have to press the green start button first).  After your test, stop the capture, save the log file, and post it here.

Also, could you monitor the SCL line with an oscilloscope when the problem happens, and ideally post that information here as well?  What we are looking for is if the SCL line is being held low by the chip.

Thanks,

[groz]

Eric,

I verified the device is still reported as "present" under Device Manager but does drop from Max. Even performing a refresh in Device Manager shows that the device is present. Note:This was an interesting test since I just assumed it was being dropped from the device manager.

I look forward to seeing what your R&D group comes up with.

Thanks

Groz

[groz]

Attached is the SPY capture of:

1) program load

2) read operation of single address <-Fail condition happens in this step

SCL and SDA levels found on scope:

1) Power-up (uP put into tri-state via reset): Both lines go to 3.3v static

2) During read operation, the SDA line=0.114v static, SCL=0.681v static

Note:

- Both lines have a 100 ohm series resistor going to UUT device

- During the fault condition, there is NO voltage drop across the 100 ohm resistors so the level is being set by the 8451.

Thanks

Groz

[groz]

Eric,

I've not heard back with a solution to my 8451 problem. Please check on status and let me know what the next step is.

Thanks

Mike