i2c_max32_rtio: Fails I2C RAM testsuite

[ubieda]

Describe the bug

The MAX32655FTHR fails to run the I2C RAM testsuite when configured for RTIO. I was, however, able to successfully run this on the non-rtio variant with #88664.

I was having issues with this platform while working on #88393, which is why I used this testsuite to provide repro-steps.

To Reproduce

• Pre-requisites:
  • An I2C FRAM breakout board (e.g: Adafruit's MB85RC256 breakout board: https://www.digikey.com/short/njtzwq2f).
  • Apply drivers: i2c: max32: fix i2c_configure to return 0 on success #88664 on top of upstream/main (in-flight fix PR).
  • Wire the I2C FRAM breakout board to MAX32655 FTHR board.
• Build command

west build -b max32655fthr/max32655/m4 tests/drivers/i2c/i2c_ram/ -- -DCONFIG_I2C_RTIO=y

• Overlay (boards/max32655fthr_max32655_m4.overlay)

/ {
	aliases {
		i2c-ram = &i2c2;
	};
};

• Output (test execution is hangs and does not ever complete):

*** Booting Zephyr OS build v4.1.0-2420-g8b54e8afa9f7 ***
Running TESTSUITE i2c_ram
===================================================================
START - test_ram_rtio
submitting write from thread 0x20010598 addr 7

uart:~$  PASS - test_ram_rtio in 0.007 seconds
===================================================================
START - test_ram_rtio_isr
timer submitting write, addr e

Expected behavior
Successfully complete testsuite execution.

Impact
Users (potentially) are unable to use this platform to work with RTIO-based applications.

[ubieda]

Marking as low since it doesn't seem a regression and it's platform-specific. Feel free to override if somebody disagrees.

[ubieda]

I'd appreciate if somebody else can attempt replicating @MaureenHelm @dimitrije-lilic

[ttmut]

I'd appreciate if somebody else can attempt replicating @MaureenHelm @dimitrije-lilic

Will it work on a small AT24 EEPROM? I do not have a MB85RC256 FRAM.

[ubieda]

I'd appreciate if somebody else can attempt replicating @MaureenHelm @dimitrije-lilic

Will it work on a small AT24 EEPROM? I do not have a MB85RC256 FRAM.

I glanced at the AT24 datasheet and it may be possible (It needs to be able to arbitrarily write bytes without requiring erasing to clear the zero's, with I2C address: 0x51).

To validate that assumption I'd suggest:

• Running the testsuite with CONFIG_I2C_RTIO=n and it should pass (Try on drivers: i2c: max32: fix i2c_configure to return 0 on success #88664),
• Then attempt replicating with CONFIG_I2C_RTIO=y.

[ttmut]

I'd appreciate if somebody else can attempt replicating @MaureenHelm @dimitrije-lilic

Will it work on a small AT24 EEPROM? I do not have a MB85RC256 FRAM.

I glanced at the AT24 datasheet and it may be possible (It needs to be able to arbitrarily write bytes without requiring erasing to clear the zero's, with I2C address: 0x51).

To validate that assumption I'd suggest:

• Running the testsuite with CONFIG_I2C_RTIO=n and it should pass (Try on drivers: i2c: max32: fix i2c_configure to return 0 on success #88664),
• Then attempt replicating with CONFIG_I2C_RTIO=y.

I could not find a MAX32655FTHR so I have tried this on a MAX32690FTHR and an AT24C08 eeprom. I had to modify the test to use 0x50 target address and I2C_SPEED_FAST (for RTIO).

Non-rtio tests pass.

*** Booting Zephyr OS build v4.1.0-2421-gc86f7caa6188 ***
Running TESTSUITE i2c_ram
===================================================================
START - test_ram_transfer
ram using i2c_transfer from thread 0x20000048 addr 7
 PASS - test_ram_transfer in 0.006 seconds
===================================================================
START - test_ram_write_read
ram using i2c_write and i2c_write_read from thread 0x20000048 addr e
 PASS - test_ram_write_read in 0.007 seconds
===================================================================
TESTSUITE i2c_ram succeeded

------ TESTSUITE SUMMARY START ------

SUITE PASS - 100.00% [i2c_ram]: pass = 2, fail = 0, skip = 0, total = 2 duration = 0.013 seconds
 - PASS - [i2c_ram.test_ram_transfer] duration = 0.006 seconds
 - PASS - [i2c_ram.test_ram_write_read] duration = 0.007 seconds

------ TESTSUITE SUMMARY END ------

===================================================================
PROJECT EXECUTION SUCCESSFUL

RTIO tests get stuck.

*** Booting Zephyr OS build v4.1.0-2421-gc86f7caa6188 ***
Running TESTSUITE i2c_ram
===================================================================
START - test_ram_rtio
submitting write from thread 0x20000348 addr 7

[ubieda]

@ttmut Yeah, looks like you've replicated the issue!

[ttmut]

In my case one of the issues is that the driver does not return properly if the address is NACKed. EEPROM needs some time after writing data, so a NACK is expected if a new command is sent immediately after. I can temporarily work around this problem by putting a delay after the first write.

test_i2c_ram.c:192
---------------------
wr_cqe = rtio_cqe_consume(&i2c_rtio);
zassert_ok(wr_cqe->result, "i2c write should succeed");
rtio_cqe_release(&i2c_rtio, wr_cqe);
/* Give EEPROM some time to sync */
k_busy_wait(1000);

However, the second test does not start after that. Not even the address is sent to the bus. That is the second issue.