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.

[allenhuffman]

I am using an ISR with NOCLEAR since I needed to check for the stop bit and that apparently was required. I handle the byte then spin in a loop checking for the next incoming byte (IRQ bit) or a stop (P bit). This was a bit wasteful for CPU cycles, but it let me know when a message was complete. (Original code would look at a special header byte in the message and then read that many more. Worked fine, until you got a bad byte ;-)

My code apparently was missing the now-faster (sometimes) stop bit, so I removed it. I still have it in there for master writes (so master can write messages of different sizes) but I was only using it in the master read code to toggle an LED on/off during the TX session. Removing it was enough to get past this.
_________________
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.

[Ttelmah]

OK, so where do you clear the interrupt, relative to where you release the
clock????. The key point is that once the clock is released, then the stop bit
can come. Ideally you want the interrupt cleared ASAP of this point. That
way the subsequent interrupt can still be detected.

[allenhuffman]