Open RobMeades opened 8 months ago
CC @Mierunski @awojasinski
This issue has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this issue will automatically be closed in 14 days. Note, that you can always re-open a closed issue at any time.
FYI @kl-cruz Triaged internally
@bjarki-andreasen We need to check whether this configuration is possible in our hardware
This issue has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this issue will automatically be closed in 14 days. Note, that you can always re-open a closed issue at any time.
We are users of the nRF52/nRF53 and its I2C drivers, with which we had no problem.
When getting the same code to work on STM32, we raised issue https://github.com/zephyrproject-rtos/zephyr/issues/69290 on the STM32 I2C driver as we had found that the STM32 driver forced
I2C_MSG_STOP
at the end of every transfer; we didn't want this as we wanted to perform a write without a stop bit, followed by a read, as separate transfers.@teburd has pointed out that the STM32 behaviour is the correct one,
I2C_MSG_STOP
should be forced by the I2C driver at the end of every transaction and a note has been added to the I2C API to this effect (see https://github.com/zephyrproject-rtos/zephyr/pull/69484/files).We have changed our implementation to work with this but @teburd asked if we could raise on issue on the nRF52/nRF53 drivers for NOT forcing
I2C_MSG_STOP
at the end of a transfer.Issue hereby raised.