Attachments (0)
Nordic Case Info
  • Case ID: 340041
Options

i2c_write_dt stop

Simon

Hello,
trying this and that with a qwiic relay, first a test on i2ccl then VS using a 9160DK.
(i2ccl -> pip install i2cdriver)

Fullscreen
1
i2ccl /dev/ttyUSB0 w 0x18 5 r 0x18 1
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX


returns a status of 0x00 that relay is not activated.

then in VS,

Fullscreen
1
2
3
4
5
6
7
8
9
uint8_t wBuff[1] = {0x05};
uint8_t rBuff = 0x00;
uint8_t a = 0;
a = i2c_write_read_dt(&dev_i2c, wBuff, sizeof(wBuff), &rBuff, sizeof(rBuff));
if (a != 0) {
printk("I2C error %d\n", a);
}
printk("Status: %X\n", rBuff);
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX


Status: 0
same as i2ccl

Then when trying to activate the relay with a write,

Fullscreen
1
i2ccl /dev/ttyUSB0 w 0x18 1 p
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX


the relay clicks on ok

But in VS,

Fullscreen
1
2
3
4
5
6
7
uint8_t wArray[1] = {0x01};
uint8_t a = 0;
a = i2c_write_dt(&dev_i2c, wArray, 1);
if (a != 0) {
printk("I2C write failed with error %d\n", a);
}
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX


There is no click response.
The difference seems to be that i2ccl is sending stop 'p' at the end of the write which Zephyr might not be doing the same.
When trying write and read 0x05 status separately in VS, the result is ok and same as i2ccl without stop.
If it is the missing stop, how best then to get a stop into i2c_write_dt?

thank-you,

  • 0

    Hello,

    Looking at\zephyr\include\zephyr\drivers\i2c.h I can find in the implementation of i2c_write_dt()/i2c_write() that the flags are fixed for this api:

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    static inline int i2c_write(const struct device *dev, const uint8_t *buf,
    uint32_t num_bytes, uint16_t addr)
    {
    struct i2c_msg msg;
    msg.buf = (uint8_t *)buf;
    msg.len = num_bytes;
    msg.flags = I2C_MSG_WRITE | I2C_MSG_STOP;
    return i2c_transfer(dev, &msg, 1, addr);
    }
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    If you instead use the i2c_transfer_dt()/i2c_transfer() api directly you can set the flags yourself. I can see some drivers do this, and I just copy an example from \zephyr\drivers\sensor\maxim\max44009\max44009.c that might be useful as reference:

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    static int max44009_reg_read(const struct device *dev, uint8_t reg,
    uint8_t *val, bool send_stop)
    {
    const struct max44009_config *config = dev->config;
    struct i2c_msg msgs[2] = {
    {
    .buf = &reg,
    .len = 1,
    .flags = I2C_MSG_WRITE,
    },
    {
    .buf = val,
    .len = 1,
    .flags = I2C_MSG_READ,
    },
    };
    if (send_stop) {
    msgs[1].flags |= I2C_MSG_STOP;
    }
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    Kenneth

  • 0 in reply to Kenneth

    Tried using i2c_transfer_dt instead of i2c_write_dt (if that was the suggestion) but with no resulting click.

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    uint8_t wArray[1] = {0x01};
    uint8_t a = 0;
    struct i2c_msg msgs[2] = {
    {
    .buf = wArray,
    .len = 1,
    .flags = I2C_MSG_WRITE,
    },
    {
    .flags = I2C_MSG_STOP,
    },
    };
    a = i2c_transfer_dt(&dev_i2c, msgs, 2);
    if (a != 0) {
    printk("I2C transfer failed with error %d\n", a);
    }else{
    printk("a %x \n", a);
    }
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    Or was the suggestion to create my own custom relay driver using max44009.c as an example and add it to /ncs/v2.9.0/zephyr/drivers/i2c ?

    thank-you,

  • 0 in reply to Simon

    In this particular case it would help a lot with a logic analyzer trace of the working vs. failing, to find the exact difference (e.g. start, stop, restart conditions, length, transfer etc). Else I don't see any other way than to try and a fail a bit using i2c_transfer_dt() and various flags, but it could be something obvious we are missing here, so a logic analyzer trace would help a lot.

    Kenneth

  • 0 in reply to Kenneth

    Working ok examples of the relay using i2ccl:

    Fullscreen
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    >>>>>>>>>>>>>>>>>>>>>>>>

    Fullscreen
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX



    Then in VS using a 9160DK:
    i2c_transfer_dt
    Fullscreen
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX


    >>>>>>>>>>>>>>>>>>>>>>>>
    i2c_write_read_dt
    Fullscreen
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX


    >>>>>>>>>>>>>>>>>>>>>>>>
    i2c_write_dt
    Fullscreen
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX


    >>>>>>>>>>>>>>>>>>>>>>>>

    The PulseView output is showing different Addresses, like 18, 14, 10, where I think they should all be 18.
    For now, not sure why this is so.

    Reused DevAcademy code for this test.
    Changing the address of the i2c to 0x18.
    /boards/nrf9160dk_nrf9160_ns.overlay
    Fullscreen
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX


    thank-you,


  • 0 in reply to Simon

    For comparison, here is the PulseView BME280 output for DevAcademy Fund L6-E1 v2.9.0,

    thank-you,

1 2
Terms of service