I2C corruption when using ESP CAN (IDFGH-3307)
Posted: Mon May 11, 2020 4:46 pm
release/v4.1 SHA-1: 5dbabae9dc32da3e639a0531b5337848a9e3317a
The I2C bus is used to read GPIO inputs and is properly pulled etc. Every now and then an incorrect GPIO port value is returned. Reducing I2C clock does not help.
The error happens every hour or so with a properly terminated CAN bus. Removing CAN termination resistors significantly increases the error rate to maybe an event per minute. Switching the ESP CAN off (can_driver_uninstall) possibly removes the error entirely.
I get the impression that the I2C module freezes during the event as I tried to send a logic analyser trigger command down the I2C bus and that took several attempts. TBC.
Nothing glitchy on the I2C bus.
This issue does not happen on v4.0-dev-562-g2b301f53e. Our application difference between IDF build are minor, mainly network stack related (which was the point of the IDF upgrade).
There are a lot of HAL/lld restructuring changes between the IDF versions and so its hard to find material changed.
The I2C bus is used to read GPIO inputs and is properly pulled etc. Every now and then an incorrect GPIO port value is returned. Reducing I2C clock does not help.
The error happens every hour or so with a properly terminated CAN bus. Removing CAN termination resistors significantly increases the error rate to maybe an event per minute. Switching the ESP CAN off (can_driver_uninstall) possibly removes the error entirely.
I get the impression that the I2C module freezes during the event as I tried to send a logic analyser trigger command down the I2C bus and that took several attempts. TBC.
Nothing glitchy on the I2C bus.
This issue does not happen on v4.0-dev-562-g2b301f53e. Our application difference between IDF build are minor, mainly network stack related (which was the point of the IDF upgrade).
There are a lot of HAL/lld restructuring changes between the IDF versions and so its hard to find material changed.