I2C 845X - Error Code -301742

[strider0202]

Hi,

I've tried both of your vis and I got the same error I originally got erro code: -301742.

Your VI looks very straight forward, we write our fixed slave address: 0X16, and the SBS command (0X00) and read. But it doesnt work! Could it be that the interface is different? Since my DAQ USB-8451 using I2C and what I'm trying to talk to (TI bq20z80) uses SMBus?

The first attachment I posted was a more general information about my device. The last one I posted with a Hyperlink was a more detail reference I found in TI website. According to the manual section: 2.9 (communication) the slave is to be read from address: 0x16 on SMB for communication. And I verifed from the same link, section: A.1 (SMS Command) that the (SBS Cmd) address for (Manufactuer Access) is (0X00). 

SO...with all that said, we got the right address, the right SBS command...but why the hell are we still erroring out? Could it be that we have configured our I2C device incorrectly? I heard we have to send 7bit address at a time or something because the I2C line only takes up to 7bit, and we are suppose to shift our register to the right one place to leave a bit for read and write. I'm not familiar with programming I2C in LabVIEW. Do we have to do all that or does the VI (I2C configured) and (I2C write/read vi) take care of all that internally?

Please Advise.

[smercurio_fc]

---

strider0202 wrote: 

Could it be that the interface is different? Since my DAQ USB-8451 using I2C and what I'm trying to talk to (TI bq20z80) uses SMBus?

---

If you look at the I2C spec and the SMBus spec you would see that the communication protocol is essentially the same. The main difference between I2C and SMBus is clock rate.

---

the slave is to be read from address: 0x16 on SMB for communication.

---

I worked on the assumption that the address given is a 7-bit address. Some manufacturers provide the address in 8-bit format. This means that the value you have to give to the I2C Configuration Property node is a 1-bit shifted value. In other words, if the address of 0x16 is an 8-bit address, the value that you would have to use in the code is 0x0B. I'm not saying this is the problem, but we may need to check on this.

---

I heard we have to send 7bit address at a time or something because the I2C line only takes up to 7bit, and we are suppose to shift our register to the right one place to leave a bit for read and write. I'm not familiar with programming I2C in LabVIEW. Do we have to do all that or does the VI (I2C configured) and (I2C write/read vi) take care of all that internally?

---

The 8451 software takes care of all that.

Now, in looking a bit more at the first spec you posted, it seems your device uses SMBus v1.1 with Master Mode and package error checking (PEC) options. The last bit is the important part. Since it uses PEC this means that transmissions require an addition byte for error checking. Also, a read will have an additional byte which is the PEC byte returned by the device. The PEC is a CRC-8 error-checking byte, and it's calculated based on the bytes that are sent, including that first byte that has the address. This means that in the examples I had provided you need to add an additional CRC byte to the 3 bytes that are written to the device and you need to read 3 bytes instead of 2. I can't modify the VI right now since I don't have LabVIEW at home. However, the modification is relatively simple. There's a few examples of VIs that can calculate a CRC-8 floating around - a search should yield them.

[strider0202]

Hi,

I've looked more into the spec sheet provided in the "Hyperlink" there is a section that talks about CRC-Error.

According to the spec: the BQ20Z80 device will (should) still work with or w/o PEC.

2.9.2 Packing Error Checking

The bq20z80 can receive or transmit data with or without PEC.

In the read-word protocol, the bq20z80 receives the PEC after the last byte of data from the host. If the

host does not support PEC, the last byte of data is followed by a stop condition. After receipt of the PEC,

the bq20z80 compares the value to its calculation. If the PEC is correct, the bq20z80 responds with an

ACKNOWLEDGE. If it is not correct, the bq20z80 responds with a NOT ACKNOWLEDGE and sets an

error code.

In the write-word and block-read in master mode, the host generates an ACKNOWLEDGE after the last

byte of data sent by the bq20z80. The bq20z80 then sends the PEC, and the host, acting as a master

receiver, generates a NOT ACKNOWLEDGE and a stop condition.

I've tried to use a 8-bit address, by shifting my address (0x16) to (0x0B), that doesn't work, I got the same as before.

 CRC-Error Packaging

I've looked into the forums and have found the "attached" CRC data validation. I've opened up the "8-bit" CRC validation VI and simply copied and pasted onto the existing "Gas Gauge read manufacture vi" and did some basic modification. I'm still getting the same error.

I'm very new at this CRC and I2C programming, please verify and see if I've wired everything in correctly.

Thanks,

Strider0202

[smercurio_fc]

If that's what the datasheet says, then you can safely not worry about the CRC for now. Besides, you did not modify the VI correctly. In order for the device to recognize that PEC is being used, then you need to have a PEC byte following the command in the first place. This means that for the read example you need to write two bytes. The first is the register to read, and the second is the CRC byte.

At this point if I had the device in our lab here I'd stick a scope on the lines to make sure the transmission is getting to the device and to verify voltage levels. I honestly don't know what else to tell you. Perhaps someone else may be able to offer additional suggestions. You may also want to try contacting NI tech support directly.