diff options
| author | bors[bot] <26634292+bors[bot]@users.noreply.github.com> | 2023-04-10 14:49:12 +0000 |
|---|---|---|
| committer | GitHub <[email protected]> | 2023-04-10 14:49:12 +0000 |
| commit | 53c60df9979f32a7bfca3fe5c30b47850ee295df (patch) | |
| tree | f4040d4134f37a4b877dedcf5f5d86834f75a7c9 /embassy-sync | |
| parent | df17a88448752ba73b25f0d09667888b863190ca (diff) | |
| parent | 6760258ec39c629b911a417d0a554bc6167c5b5b (diff) | |
Merge #1346
1346: fix I2C controller problems after NACK r=Dirbaio a=Juravenator
While tinkering with I2C on a NUCLEO-H723ZG, I noticed that when trying to communicate with a non-existent device you do receive a proper NACK error, but afterwards any future communications with any device no longer works as expected.
The use case is auto-detection of devices, in this case a series of Adafruit 24LC32 I2C EEPROM boards.
On closer inspection with a logic analyzer, I observed that after the NACK, any data bytes sent out by the board to the devices are just zeros. Even though the embassy code specifies the correct data in `set_txdata` in `write_internal`. Something seems to be going wrong with the controller or buffers on the board itself.
Then I noticed what seems to be a logic error in `flush_txdr`, which is called when issuing a NACK.
After flipping the if statement, I2C communications keep working as expected after issuing a NACK.
Co-authored-by: Glenn Dirkx <[email protected]>
Diffstat (limited to 'embassy-sync')
0 files changed, 0 insertions, 0 deletions