USB-8452 I2C Script not Working

[Filipe_Altoe]

Hello Fellow LVers;

I'm trying to implement a I2C script in LV to run on the USB-8452 and am stuck. The script runs with no errors, but I only get 0xFFs at the final read function (which means I am not getting the appropriate bytes (the bytes are supposedly the serial number from the device). The exact same functionality programmed in C running on a microprocessor based custom board works fine. What am I missing?

I am attaching a snapshot of the LV code as well as the C code snippet that works on the cutom device. The idea is to replicate exactly what is running on the custom micro board to run on the USB-8452.

As extra information, the command 0x33 that is sent prior to the reading of the 8 bytes is sent to a 1-wire memory device (DS2505 - User Manual attached as part of the zip file) through the I2C bridge (DS2482 - User Manual also attached as part of the zip file); which is the device I am talking to via I2C. The 1-wire device returns 8 bytes that get stored in the data register of the DS2482 bridge. My feeling is that I'm having some sort of timing problem, since the eight bytes are stored in the same 1-byte data register in the bridge. Any ideas welcome!

Thanks guys.

Filipe

[Vijay_J]

Hi Filipe,

For me, issue seems to be a "Protocol" or "Sequence" one.

I assume system has the Latest LabVIEW Driver supported by 8452 Device installed. 8452 Device functionality is verified independently.

Did you have a chance to capture the Digital SPI waveform from C program and LabVIEW code, It might give a better Clue?

LabVIEW sequence does not issue the stop command ("NI-845x I2C Script Issue Stop.vi") similar to the C code any specific reason?

Regards,

Vijay.

[Filipe_Altoe]

Hi Vijay;
One thing I didn't mention was that I am able to write and read back from other registers in the i2C bridge. So, the functionality of the device has been verified.

The stop command from the C code is a stop transfer command; which is how the bytes transmission was implemented in the C code. It doesn't necessarily match the scrip stop function in LanVIEW. Unless I am misinterpreting the functionality of the stop acript VI. In my interpretation, the stop script VI is to be called just once at the end of the script, to indicate the acript has finished at that point.

[Vijay_J]

Hi Filipe;

In that case, i would highly suggest to use the Oscilloscope to capture the waveform and compare.

Out of the box question: Ensure the code writes all the commands and data in Hex. 

Regards,

Vijay

[GPIB_Guru]

Let me interpret the commands in text to try to understand:

Create Script

Set Clock rate at 100k

Start

Address+Write

Write Data

Wait 1ms

Loop 8 times

(Re)Start

Address +Write

Write Data

Wait 100us

(Re)Start

Address + Read

Write Data *** (why write after addressing as read - this seems strange to me)

Read 1 byte

Stop

The other thing that seem strange is that there was no stop after the first write of [WR1_WR, 33].

[SteelyDad]

Filipe_Altoe, 

Did you ever get this issue solved? I am having a similar issue with I2C communication that I developed in LV 2015 (Where it works fine) but the test station where the code is deployed is LV 2014 and when I "save for previous version" and try to run the code on the LV 2014 station, I get all 0xFF's as a response, instead of the data I can accurately read at my 2015 development station.

Thanks in advance! 

[RenKylo2]

Hi SteelyDad,

Is the LabVIEW version the only difference between the two stations? Does the LabVIEW 2014 station have the NI-845x driver as well?

Since this post is fairly old, it is also a good idea to start a new thread.

[SteelyDad]

Ren, 

Yes, we have tried with both the 2014 and 2015 NI-845x drivers suspecting that may be the issue, but no luck. We slowed down the baud rate to 25k instead of 100k and began seeing intermittent data, instead of just 0xFF's so now we are thinking our issue may be noise / comm speed related. If we don't have any progress in a day or so we will start a new thread with all of the relevant info. 

Thanks! 

SD