Why am I only receiving the first address byte? (I2C Protocol)

Question

Expecting the slave to ACKnowledge and return data, but it does not. This is my protocol. This is my Datasheet

The datasheet mentions \"The slave will answer by sending

Answer 1

Your program has undefined behaviour. You have declared buffer as:

char buffer[1];

That's an array of one single character. The only null-terminated string you can possibly store there is empty string (i.e. where buffer[0] == '\0'). But you are using it to convert integers to strings.

You need to make the buffer large enough to hold the largest string you expect to store in it, including the terminator.

Answer 2

I'm not sure what your root issue is here. What are the symptoms you are having? What kind of output do you have on your UART?

As others have said, your buffer variable is too small to hold anything of value as a C string. itoa (AVR libc entry) usually provides a null-terminated string, so you'll need to be at least big enough for all the characters as well as the null value. You may be having an issue overflowing the buffer, in which case you should have a simple solution.

Your use of uin8_t means you should be allocating enough space for the representation of up to 255. You need 3 characters to represent the full range, as well as one character for the null character. Change your code to read char buffer[4]; and see if that improves the issues you are having.

If the I2C protocol implementation is in error, that will be harder to diagnose without accurate information on where the error is. A logic analyser should help here if you have access to one.

EDIT:

I just took a look at the datasheet and your method of i2c_start(0x5A) with consecutive i2c_read_ack()s seems to be correct. However, based on your linked protocol, you are probably just seeing "Error" on your UART as i2c_start() returns 0 for a successful start transaction and you check if(i2c_start(I2C_READ)) when you should be testing for if(! i2c_start(I2C_READ)) in getVal().

You also seem to have some unnecessary uint8_t casts based on your linked i2c_master.c gist. I'd suggest just using the Arduino IDE if this really is an Arduino compatible board and see if you can get a simple I2C example to work with the sensor to prove out your access methodology.

Answer 3

For I2C, it is very important to have pull-up resistors on both SDA and SCL pins. If these are not present, the bus will always read low or floating voltage. I do not know the AVR hardware enough to know how it would behave, but I would expect the "// check if the start condition was successfully transmitted" to fail if this is the case.

In general when developing for hardware like this, I do recommend to have a logic analyzer. It can help when you are blind to what the hardware bus actually does.

An example of such device is https://www.saleae.com/ ,but multiple vendors and/or open projects exists.

Answer 4

Difficult to tell without having details of the i2c library that is being used, but the one thing I'd be checking first is the i2c_start(I2C_READ).

The i2c address provided in the datasheet is 0x5a as you've put in your macro. But the first byte also contains the read/write flag as the least significant bit. The i2c_start() function has to be putting 0xb5 onto the bus (i.e. (0x5a << 1) + 1 for a read)

If i2c_start() is not, then your slave device is not actually being addressed and so won't ack.