Instrument Control (GPIB, Serial, VISA, IVI)

cancel
Showing results for 
Search instead for 
Did you mean: 

USB-8451 SMBus communication problem

Hi,
 
I use an USB-8451 I2C/SPI interface to communicate with SMBus devices. Use 10K resistor and external 5V power supply to pull up SCL,SDA pins. In the LabVIEW code send the clock rate in 100kHz and set the correct device address. Try to read SMBus device information. The problem is that communication between LabVIEW code and SMBus device is very unstable. Sometimes it could read information from device and sometimes it gives the following error just by rerunning the same piece of code:
 
Error -301742 occurred at NI-845x I2C Run Script.vi:1
Possible reason(s):
NI-845x:  The slave did not acknowledge an address+direction byte transmitted by the I2C master. Reasons include the incorrect address set in the I2C configuration or the incorrect use of the 7-bit address. When entering an address to access a 7-bit device, do not include the direction bit. The NI-845x Basic I2C API internally sets the direction bit to the correct value, depending on the function (write or read). If your datasheet specfies the 7-bit device address as a byte, discard the direction bit (bit 0) and right-shift the byte value by one to create the 7-bit address.
 
I am kind of sure possible reason is not as above because the same hardware connection and same code, sometimes works and sometimes it does not. Has anyone the similiar experience. What may be the reason?
 
Thanks
Jason
0 Kudos
Message 1 of 10
(6,305 Views)

Jason,

I have a few questions that may help us get to the bottom of this:

So what all changes from when your code works to when it doesn't?  Does it work the first time and then not subsequent times? What is your code accomplishing, it is possible that it is not in the proper state to receive and acknowledge the address bits. What do you do to make it start working again?



Message Edited by MXI Master on 03-31-2008 01:45 PM
-Marshall R
National Instruments
Applications Engineer
One stop for all your NI-VISA Support

GPIB Support has a new homepage
0 Kudos
Message 2 of 10
(6,277 Views)

Hi Marshall,

Thank you for your reply.

Basically the code is to read information from smart battery. I need to get battery charging status, battery chemistry etc. LabVIEW code is standalone and I revise it from I2C read script example. I press "Run" button to run the code. Running may be OK at first time. When I press "Run" button second time, it is most likely that I get the error, I press "Run" button one more time, it may or may not be OK. Continue pressing "Run" button sometimes it is OK, sometimes it not. But if I press "Run" button too fast between the two running, chance to get error is much high. I did not change anything in the hardware and even I did not unplug and replug the USB-8451 from computer. Sympotom to me is that I2C reading is unpredicable.

What do you mean by "it is not in the proper state to receive and acknowledge the address bits". Do you mean the smart battery (SMBus device) is not ready? How could I make it ready or how could I detect it in which mode master or slave?

Jason

0 Kudos
Message 3 of 10
(6,269 Views)
Jason,
 
actually looking at your previous post, I see that you are using a 10k Ohm resistor as your pull-up, I would recommend trying something along the lines of a 2.2k or a 4.7k. That might solve your problem. Have you double checked all of your other connections to make sure they are solid and correctly wired for the address you are sending?
-Marshall R
National Instruments
Applications Engineer
One stop for all your NI-VISA Support

GPIB Support has a new homepage
0 Kudos
Message 4 of 10
(6,228 Views)
Hi Marshall,
 
I've tried 2.61K and 5K resistor pull-up, the symptom is the same. Luckily when I reduce the clock rate to 50kHz, it works. Then I tried 80kHz, it also works. And the pull-up resistor is 5K. Could it be noise to cause intermittent timing problem? If I'd like to work at 100kHz, what should I do?
 
I am not sure whether another problem I encounter for USB-8451 is related to the above. When I tried to set USB-8451 digital output. Some prots are able to be controlled while some not. What I mean port be controlled is that when I set "high", I measure it's high when I set "low", I measure it's low. The symptom is like that. For one USB-8451 device, port 0,2,3,5,7 can be controlled, port 1,6,4 cannot. For another USB-8451 device we just bought, port 0,1,3,4,6,7 can be controlled, port 2,5 cannot. What could it be?
 
Jason
0 Kudos
Message 5 of 10
(6,213 Views)
Hi,
 
It seems you discovered a Bug with the I2C Chip we are using in the 8451 box. Regarding to what we are seeing here, the I2C/SMBus minimum clock low time spec is violated at 100 k. The spec states a minimum value of 4.7 &micros while the measured time of the 8451 was 3.6 &micros. I can not see a workarount yet other then lower the rate.
But i promise to investigate this more and i will keep you updated about the results.
 
DirkW
0 Kudos
Message 6 of 10
(6,175 Views)

Hi DirkW,

Thanks. Looking forward to your answer.

Jason

0 Kudos
Message 7 of 10
(6,164 Views)
It would help if you had this bug also in your knowledge base. Is this problem valid on all 8451s or are newer ones not affected?
 
Regards,
 
Philip
0 Kudos
Message 8 of 10
(5,911 Views)

I am having a similar problem while trying to communicate with SMBus devices using the NI USB-8451.  It works fine when communicating with I2C devices, but when I try to communicate with an SMBus device, I get the same error that Jason described.  However, I have never been successful in communicating with the device using the NI hardware - the connection is not even intermittent.  There is a set of hardware and software that came with the SMBus device, which seems to work fine, so the SMBus device is not damaged.  Has a solution to this problem been proposed?

 

Thanks,

 

E

0 Kudos
Message 9 of 10
(5,382 Views)

Hello,

 

There are still issues with using the USB-8451 with SMBus devices at 100KHz.  Currently the only work around is to use the device at a slower baudrate.  Like Dirk mentioned, this is due to the low time spec being violated when running at 100KHz.

Message Edited by Caleb W on 12-04-2008 02:43 PM
Caleb W

National Instruments

0 Kudos
Message 10 of 10
(5,359 Views)