STM32 I2C read - every second fails (OS6)

[pilotak]

Description of defect

When trying to read a byte from I2C every first call read() is done. The second call is not actually done it only returns ACK: 1 even if i put a 1s delay between those two calls. This is a problem in OS6, in OS5.15 this works as intended.

Target(s) affected by this defect ?

STM32F412

Toolchain(s) (name and version) displaying this defect ?

GCC_ARM

What version of Mbed-os are you using (tag or sha) ?

483db06

What version(s) of tools are you using. List all that apply (E.g. mbed-cli)

mbed-cli

How is this defect reproduced ?

An example read from I2C eeprom

#include "mbed.h"

I2C i2c(PB_7, PB_6);

int main() {
    char buf[1];

    for (size_t i = 0; i < 2; i++) {
        int ack = i2c.read(0x50 << 1, buf, 1);
        printf("ack=%i\n", ack);
        // ThisThread::sleep_for(1s);
    }

    return 0;
}

add debug to I2C read()
https://github.com/ARMmbed/mbed-os/blob/master/targets/TARGET_STM/i2c_api.c#L914-L920

if ((timeout == 0) || (obj_s->event != I2C_EVENT_TRANSFER_COMPLETE)) {
    DEBUG_PRINTF(" TIMEOUT or error in i2c_read\r\n");
    /* re-init IP to try and get back in a working state */
    i2c_init_internal(obj, NULL);
+   printf("timeout\n");
} else {
    count = length;
}

Results:

This is OS6

ack=0
timeout
ack=1

This is OS5.15.6 (b114a9c)

ack=0
ack=0

[ciarmcom]

Thank you for raising this detailed GitHub issue. I am now notifying our internal issue triagers.
Internal Jira reference: https://jira.arm.com/browse/IOTOSM-2879

[jeromecoutant]

This is a problem in OS6, in OS5.15 this works as intended

Is it possible to check before and after #12626 ?
Thx

[pilotak]

@jeromecoutant I can confirm it works fine before (e8208c0) and if fails after CUBE update (6678efe)

[pilotak]

@jeromecoutant any update?

[jeppefrandsen]

We are seeing the same issue. Tried to update STM32Cube to 1.25.2 but same issue. Will try to revert and check.

[jeppefrandsen]

It works for me with 1.23.0 but not 1.24.0. Maybe you can check also @pilotak?

[ikmdani]

Reproducing the problem:
From the “description of defect” I understand that you want to read EEPROM using i2c bus operations. Here I try to reproduce the problem using the code as below, using an accelerometer instead of EEPROM as i2c slave device connected to NUCLEO-F29ZI target platform with mbed-OS 6.8.0.

Below is the bus activity for the above code, it is exactly as mentioned in the problem description.

Analysis:
After looking at the code and executing the code, I can confidently say that the code mentioned is not the correct way of reading data from i2c slave devices.

The correct way to perform i2c read is to first call i2c.write() with a mention of register offset (0x2C in my example) to be read and followed by i2c.read() with last parameter mentioning number of bytes to be read. The below code reads 2 bytes of data starting from register offset 0x2C. Here i2c.read() function is called only once and after successfully executing this line, the buffer cmd contains the bytes read.

Below is the bus activity for the above logic, data read is 0x0A (at 0x2C) and 0x00 (at 0x2D).

If multiple i2c read operations needs to be performed then the followed shall be the way. Here I am trying to read 2 bytes of data starting from register offset 0x2C, three times.

Below is the bus activity for the above logic. I could not capture the complete timing diagram here.

Conclusion:
I didn’t see any problem as such here, it is working as expected. So this ticket can be closed if this justification is acceptable.

[pilotak]

There are devices where you don't need to specify offset you want to read from - it is increased in slave device automatically. So i don't think you are right. Another example: you have a limited buffer to read to (which could be the ie. reading 4k data from slave with 64 bytes allocated buffer, you just process it gradually - you don't need to waste 4k of RAM), there is no need to set the offset again.

The problem here is that this worked fine before upgrading the STM32Cube, not if the code is correct - it was only for reproducing the issue!

[0xc0170]

The fix was referenced above, please review