NI USB-8452 as an I2C slave - maximum operating frequency

[DanB1983]

Hello,

I am using the USB-8452 as an I2C slave to capture updates to a 32 character LCD.  On the whole I have been successful.

However, every once in a while (roughtly 1% of reads) it will drop a byte.  The failures seem to coincide with times when the test PC is busy doing other CPU intensive operations.

My question is this:

My I2C master clock SCL (on the UUT) is running at 100kHz.  Is this likely to be too fast for the USB-8452?  If so, is there a recommended maximum frequency?

Many Thanks,

Dan

[DanB1983]

Bump.

Anybody have any thoughts about this?

Source code attached.

[Chris_Garratt_NIUK]

Hi Dan,

I will take a look at this for you and get back to you. In theory, that device should be capable of much faster data rates so it is likely the issue is somehwere in the code. Can you provide a MAX System Report for me? This can be done from the Help menu in in MAX.

It is NI Days this week so unfortunately I wont be able to take a proper look at this until Thursday. If you have an SSP contract please try phoning in to NI Technical Support who may be able to provide quicker assistance.

Best Regards,

Chris

[DanB1983]

Thanks Chris

Yes I have a support contract, and have already been in touch with Nabilah Farhat in tech support, but to no avail.

I have run an overnight test, capturing an I2C transaction every second, and acheived 98.8% success (514 failures in 42184 attempts). 

Furthermore, I captured the CPU untilisation (see attached screenshot) on each transaction, and found that the I2C failures corresponded with CPU utilisation of greater than 5%, wheras the passes were always <5%.  This would seem to indicate some issue with windows being unable to process the I2C events quickly enough, don't you think?

System report below:

Operating System(OS)                Windows 7 Professional
OS Version                          6.01.7601
OS Info                             Service Pack 1
Processor                           Intel(R) Core(TM) i3-3220 CPU @ 3.30GHz / Intel64 Family 6 Model 58 Stepping 9 / GenuineIntel / 3292 MHz
Number of Processors                4
Physical Memory                     3.79 GB of RAM
Drive C:\                           395 GB of 450 GB free
Drive Q:\                           3.67 GB of 13.6 GB free
                                   
National Instruments Software:      Version:
                                   
CVI Run-Time                        13.0.0.632
NI-DAQmx Device Driver              9.8.0f0
NI-DAQmx ADE Support                9.8.0
NI-DAQmx MAX Configuration          9.8.0
NI I/O Trace                        3.1.1f0
LabVIEW Run-Time                    10.0.1
Measurement & Automation Explorer   5.5.0f0
Measurement Studio                  Visual Studio 2010 Support - See individual versions below.
     DotNET                         
          Common                    13.0.40.190
          Common (64-bit)           13.0.40.190
NI-USI                              2.0.1.5249
NI-845x                             2.1.2f0
NI PXI Platform Services            3.2.3
NI-PAL Software                     2.9.1
NI System Configuration             5.5.0f0
NI TestStand                        5.1
NI-VISA                             5.4
NI-VISA Runtime                     5.4
LabVIEW                             13.0.0
LabVIEW Run-Time                    11.0.1
LabVIEW Run-Time                    12.0.1
LabVIEW Run-Time                    13.0.0
LabVIEW Run-Time                    8.2.1
LabVIEW Run-Time                    9.0.1

[JJJ2025]

Hi,

We encountered the same problem and solved the issue by moving the acquisition block to a time critical thread (VI Properties>Execution>Priority:"time critical priority"). 

However, it would be interesting to know the underlying root cause of this issue. Did you ever figure this out?

Thank you in advance.

[LVNinja]

Hi 

I would assume that the issue is with  windows not necessarly with the HW. 

Is there a way to give priority to the labview VI over other tasks that the PC is doing  ? 

[JJJ2025]

Hi,

The setting "VI Properties>Execution>Priority" seems to be in respect to all the processes running on the computer. 

In our heuristic experiment, when this setting was set to "normal", opening multiple Chrome tabs or opening large Excel documents lead to dropping of frames (by which I mean returning all 1's, so probably reading the bus when the slave is not sending anymore, in our case the NI8452 was in master mode). When this setting was set to "critical", this behavior was not seen anymore.

[DanB1983]

It's been 12 years since I posted this!

If memory serves, I never did resolve the issue with the NI-8452 dropping occasional bytes, but instead switched to a Total Phase Aardvark I2C/SPI device. I found this to be significantly more reliable (at least, it was as reliable as I needed it to be for my application).