FTDI LibFT4222 1.4.7 improved but broke my PIC24 code ;-)

[allenhuffman]

Passing this along in case anyone else uses the FTDI I2C Windows drive to talk to a PIC24.

I have had I2C code running the past few years that suddenly started having issues after updating the FTDI drive to 1.4.7. The release notes have no details, but I observe when things break the STOP bit happens right after the last clock pulse of the final byte the Master is READING. When this happens that quick, my code that looks for the STOP/IRQ bit and is doing enough that it misses it.

In earlier drivers, the timing has always been sporadic with "random" gaps between bytes now and then. Normally there is a small gap after the final byte is READ by the FTDI driver and when the STOP bit is seen. When there is a gap before the STOP is seen, it works great as it has the past few years.

Now the gap seems to be gone "most" of the time, and those break my code. I am working on improving my code now.

Just sharing this in case anyone else has jumped from 1.4.5 to 1.4.7 like I just did and ran into issue...
_________________
Allen C. Huffman, Sub-Etha Software (est. 1990) http://www.subethasoftware.com
Embedded C, Arduino, MSP430, ESP8266/32, BASIC Stamp and PIC24 programmer.
http://www.whywouldyouwanttodothat.com ?

Using: 24FJ256GA106, 24EP256GP202 and 24FJ64GA002.

[temtronic]

so, the cynic in me has to ask... WHY did you update something that has worked for YEARS ???

[allenhuffman]

[Ttelmah]

Comment.
If your device is reading, it should be stretching the clock until the read has
been done. It sounds as if possibly your code is relying on the default
CCS behaviour, and resetting the IRQ, when it exits the subroutine, rather
than handling this yourself?. Problem is that if the clock is released, and then
there are a few uSec delay before you exit the sub, another event can
arrive in this interval, and the IRQ for this then gets reset.... :(
On my own code I handle resetting the IRQ the very next instruction to
releasing the clock. If another event then occurs the IRQ gets called
again to handle this.