I2C issue: data byte is shifted by LabJack | LabJack
 

I2C issue: data byte is shifted by LabJack

2 posts / 0 new
Last post
Calibrator69
Calibrator69's picture
I2C issue: data byte is shifted by LabJack
:edit: Oops, posted in T4 but I'm using a T7 Pro

Hello,

I'm having an issue with my LabJack's I2C. My LabJack is communicating with the bootloader of a slave (atmega uC). Sending commands to this slave is not 'register-based' meaning that after writing the slave's addresss with the write-bit enabled (so set to zero) the next data byte is the command ('E' in this case) and not a register pointer. After sending a command I must read a single byte from the slave.

Initialization of LabJack I2C:

LJM_eWriteName(m_handle,"I2C_SDA_DIONUM", 13);

LJM_eWriteName(m_handle,"I2C_SCL_DIONUM", 12);

LJM_eWriteName(m_handle,"I2C_SPEED_THROTTLE", 65516.0);

LJM_eWriteName(m_handle,"I2C_OPTIONS", 3.0);

---------------------------------------------- My code: --------------------------------------------

int err = 0;

int errAddress = 0;

const char txData[1] = {'E'};

uint8_t rxData[1];

// Slaves address is 0x42

LJM_eWriteName(m_handle,"I2C_SLAVE_ADDRESS", 0x42);

LJM_eWriteName(m_handle,"I2C_NUM_BYTES_TX", 1);

LJM_eWriteName(m_handle,"I2C_NUM_BYTES_RX", 1);

LJM_eWriteNameByteArray(m_handle,"I2C_DATA_TX", txData, &errAddress);

LJM_eWriteName(m_handle,"I2C_GO", 1);

LJM_eWriteNameByteArray(m_handle,"I2C_DATA_RX", 1, &rxData,&errAddress);

However, the LabJack is doing something with my data byte. See the included image of a capture with my logic analyzer. Instead of writing the character 'E' it's sending 0x8B. Now coincidentally, this is equal to 'E' (0x45) shifted by one and with the LSB set to 1. An operation that would be performed when reading from a slave with address 0x45. Additionally, i'm also missing a start bit after the write.

I hope anybody could help me figure out why this is happening. 

Thank you

 

 

 

 

File Attachment: 
LabJack Support
labjack support's picture
Hello,

Hello,

One thing you could try is sending 0x45 rather than 'E' to your tx bytes. I would think 'E' is just interpreted as 0x45, but it might be worth a shot anyway.

I am not sure if I understand what you mean by missing a start bit after the write, but your I2C_OPTIONS is currently set so that no stop condition is sent after a command (bit 1 in the options).

    https://labjack.com/support/datasheets/t-series/digital-io/i2c