Update 2079 -> 2081, XMEGA, I2C on twie problem

albertsm · Joined: 09 Apr 2004 Posts: 5098 Location: Holland

no, altering the dat will not help. the only thing that will work is what i posted earlier.
i will see if i can post a patch.

MDuprau · Joined: 13 Oct 2012 Posts: 30

But this bug is only inside the 2.0.8.x, not on 2.0.7.9 ?

I took also a bit time to understand your compiler switches for i2cstop, i think this can be a bit better if you split them up to three differend cmd, like "i2cstop", "i2cstopNoOwn", "i2cstopNoChk", or as parameter "noOwn" and "noChk".
The I2C bus is for multiple devices, some of them are a bit "different" inside the i2c state machine, so its a hardware implementation and cant be fix easy.
So some of them need a "other" stop-sequence, but not all, so if you bring up only one of them, it will be solution for a i2c bus with one device, but not like my hardware with a lot of different devices.

And if you change the "i2cstop" please add "i2creset" also, its a know secret that sometimes the i2c bus stuck and only way to "reset" the state machine in all connected devices is to make a i2creset.
https://community.nxp.com/thread/316813
Post from "TomE"
https://www.nxp.com/docs/en/user-guide/UM10204.pdf
3.1.16
The solution for a "i2creset" is to send a number of clocks, and code solution must check the timing from i2c clock setting, witch is not so easy, if you have different i2c clock settings.
The compiler know the clock settings and can be implement the i2creset right.

I know, only one theme inside one thread, so i must apologies, but i will not discuss this two "changes", maybe its only a brainstrom to add some themes on you roadmap.

Best Regards Mark