zephyr/tests/drivers/i2c/i2c_slave_api
Peter Bigot e0fd918bbd tests: i2c_slave_api: make dual role support optional
Not all I2C controllers that support dual roles allow a controller to
be used in both modes without reconfiguration: for some, registering a
slave device prevents use in master mode.  Refactor so that dual-role
operation is opt-in, and select it for the ST devices currently in the
allow list.

Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
2021-01-21 09:27:35 -06:00
..
boards tests: i2c_slave_api: Add test for mec1501modular_assy6885 board 2021-01-20 14:16:27 -05:00
common tests: i2c_slave_api: make dual role support optional 2021-01-21 09:27:35 -06:00
src tests: i2c_slave_api: make dual role support optional 2021-01-21 09:27:35 -06:00
CMakeLists.txt
Kconfig
README.txt tests: i2c_slave_api: make dual role support optional 2021-01-21 09:27:35 -06:00
prj.conf tests: i2c_slave_api: rework diagnostic output 2021-01-21 09:27:35 -06:00
testcase.yaml tests: i2c_slave_api: make dual role support optional 2021-01-21 09:27:35 -06:00

README.txt

I2C Slave API test
##################

This test verifies I2C slave driver implementations using two I2C
controllers on a common bus.  The test is supported by a test-specific
driver that simulates an EEPROM with an I2C bus follower ("slave")
interface.  Data is pre-loaded into the simulated devices outside the
I2C API, and the Zephyr application issues commands to one controller
that are responded to by the simulated EEPROM connected through the
other controller.

This test was originally designed for I2C controllers that support both
leader and follower behavior simultaneously.  This is not true of all
I2C controllers, so this behavior is now opt-in using
CONFIG_APP_DUAL_ROLE_I2C.  However, the devicetree still must provide a
second EEPROM just to identify the bus.

In slightly more detail the test has these phases:

* Use API specific to the simulated EEPROM to pre-populate the simulated
  devices with device-specific content.
* Register a simulated EEPROM as a I2C follower device on a bus.  If
  CONFIG_APP_DUAL_ROLE_I2C is selected, register both.
* Issue commands on one bus controller (operating as the bus leader
  (master)) and verify that the data supplied by the other controller
  (as bus follower) match the expected values given the content known to
  be present on the simulated device.  If CONFIG_APP_DUAL_ROLE_I2C is
  selected, do this with the roles reversed.

Transfer of commands from one bus controller to the other is
accomplished by hardware through having the SCL (and SDA) signals
shorted to join the two buses.

Presence of this required hardware configuration is identified by the
`i2c_bus_short` fixture.  If the buses are not connected as required,
or the controller driver has bugs, the test will fail one or more I2C
transactions.