Data corruption on FT245R links - Page 1
Forum section: electronics / projects

author: LeChuck42
author_rank: Newbie
timestamp: January 12, 2016, 09:34:29 am
content: Hi Forum!I have been in contact with FTDI support for some weeks now, but so far I havn't gotten much of an answer besides them never having heard of my problem. So I though maybe somebody else has...We are using the USB FIFO FT245R (both ...L and ...Q) in several designs. Recently we spotted some protocol errors on one device communicating with an embedded PC. After investigating the issue it seems as if our problem is caused by the combination of a somewhat picky USB-Host and the FT245R chip:Data is transmitted from the device to the PC. The data is transferred into the FIFO chip correctly and transmitted to the USB-Side correctly. For some reason the host controller decides the packet wasn't transferred correctly, i.e. it found a checksum error (even though my protocol analyzer said otherwise) and issues a retransmission of the USB packet. This is within USB spec, so no problem here. In the meantime further data was written to the FIFO by the uC on the device. Now when the FT245R "resends" the packet, it overwrites the first byte of the retransmission with the first byte from the next (yet to be send) packet and thereby corrupting the data. Even worse, it recalculates the packet checksum to reflect the corrupted byte. This time the USB-Host receives the packet correctly and because the checksum is correct, it forwards the corrupted data to the system.In the screenshot of my protocol analyzer I attached, you can see the capture of a test I did on another device. Here the FT245R is used to send log entries. The data to be send is split into two packets. Each packet begins with 0x31 0x60 which is some protocol header internal to FTDI's driver. The first payload byte is 0x4C. In the retransmission this byte is changed to 0x41, which is the first bytee of the following packet. I forced a retransmission by actively destroying the first packet (using a signal generator and some transistors I bodged into the USB wire)Note that the USB host used here is actually my PC with the most recent FTDI driver (2.12.10) so the embedded PC is not the issue here.Also I'm able to recreate this behaviour 100% using several layouts (including the FTDI eval modules) with the FT245RL as well as the FT245RQ. I tested some older chips with production date of 2011 as well as new ones.The problem is, because the FTDI universe is a black box, I have no control over the USB timings and therefore no control over where the packet boundaries are. Hence I cannot simply insert dummy bytes at specific locations. Waiting a fixed time to force the transmission of a single packet would slow down the communication too much, so this is also not an option.I'm hoping some of you have stumbled across this before, and were able to find a workaround.Thanks,Matthias

author: matkar
author_rank: Regular Contributor
timestamp: January 12, 2016, 06:52:11 pm
content: I have been using FT245BM (or BL) and FT240x for at least 8 years now and haven't seen anything like this. I haven't used RL type but as far as I can tell it's only the housing that is different.1. I don't know out of my head which driver I'm currently using but I doubt it's a driver issue. Try with an older driver to eliminate a possible cause anyway.2. Maybe the USB net lengths are not equalized (not necessarily on your device)?Does this happen on embedded PC only or on other PCs as well?Which OS does your embedded device have? I've used it on Win CE, XP, 7, 8, 10.Regards,Mat

author: LeChuck42
author_rank: Newbie
timestamp: January 13, 2016, 06:40:10 am
content: Thanks for your reply matkar!Quote from: matkar on January 12, 2016, 06:52:11 pmI havn't tried these ICs as we don't use them. My current replacement type would be the FT232H on which I don't see this problem either. But this would mean to scrap a lot of produced boards...Quote from: matkar on January 12, 2016, 06:52:11 pmYes, on the embedded PC I've used several older versions (1.0.1.3, 1.0.1.6 and the most recent 1.0.1.12), and on my Windows machine I first testet with an older version too, before I updated. So yes, I don't think it's a driver issue either, but hoping for FTDI to be able to fix this in the driver.Quote from: matkar on January 12, 2016, 06:52:11 pmThe net lengths should be equal and I don't think this to be the cause, as I've tried several layouts including FTDI's reference modules.Also I used different controllers feeding the data (ATmega system bus and two FPGA implementations with different timings)I was able to reproduce this on the embedded PC as well as my Windows 7 laptop. The embedded system is an ARM running WinCE.

author: matkar
author_rank: Regular Contributor
timestamp: January 13, 2016, 10:32:50 am
content: Make a bare minimum example (hardware (preferably including their own FTDI's reference module connected to a uC of yours) + software) where you can reliably repeat the issue. Try on several different PCs.If your results are consistent over multiple PCs, ask FTDI if you can send them a setup where this event occurs so they can test it.I believe this is the best chance to get to the bottom of this.

author: LeChuck42
author_rank: Newbie
timestamp: January 13, 2016, 10:53:44 am
content: Quote from: matkar on January 13, 2016, 10:32:50 amYep, I've done exactly that, but their support is not the fastest...I used a cheap available FPGA development board and the UM245R mini module. To be fair, one still needs a protocol analyzer or some other way, to cause the host to request a retransmission to trigger the effect.I guess I just have to wait.

author: mich41
author_rank: Regular Contributor
timestamp: January 13, 2016, 12:46:11 pm
content: I have this feeling that it's a bug in FTDI chips which went unnoticed because USB bit errors are too rare. Maybe your embedded PC is more sensitive to noise or clock jitter than your analyzer? I wonder if a USB hub would eleminate those CRC errors?

author: LeChuck42
author_rank: Newbie
timestamp: January 13, 2016, 01:39:35 pm
content: Quote from: mich41 on January 13, 2016, 12:46:11 pmThanks for your thoughts!Yes, that's what I thought. Although I didn't think the errors would be considered as rare...The device will be used in a noisy environment, so I can't rely on perfect transmission. But indeed, the embedded PC seems very finniky. We changed the PC and saw the error-rate getting affected. So this was the first thing I concentrated on while investigating the problem. We have some limited control over the PHY on the host, but the configurable values mostly influence the transmitter and not the receiver. So I didn't get very far.As it turns out it is the combination of1. The host asking for a retransmission while2. further data is present in the FIFOtriggering the bug (?) in the FTDI chip.I tried a hub, which indeed helped getting rid of most retransmissions, because the embedded PC was now talking to a different PHY, that it seemed to like better.But as soon as I forced the retransmissions, the same error came up again.So this could be a solution for quiet environments, where no errors are to be expected, but sadly this is not the case for me.

author: mich41
author_rank: Regular Contributor
timestamp: January 13, 2016, 03:09:52 pm
content: Did you double check that there is enough delay between strobing WR and sampling TXE? Theoretically, the TX buffer should overflow after four 64B packets, not just one. But maybe there is a bug in buffer overflow behavior

author: marshallh
author_rank: Unknown
timestamp: January 13, 2016, 04:38:24 pm
content: 1. Are you 100% positive they are genuine FTDI silicon?2. As far as finding errors in the pcb layout and such, any pcb info you can post?

author: station240
author_rank: Unknown
timestamp: January 13, 2016, 04:43:40 pm
content: Is it an option to reduce the USB speed to the "low speed" 1.5 Mbit/s , that might reduce the error rate.

author: LeChuck42
author_rank: Newbie
timestamp: January 14, 2016, 06:31:57 am
content: Hi all!Quote from: mich41 on January 13, 2016, 03:09:52 pmThe data is transmitted correctly the first time, I think that transmission from the uC to the FIFO should be fine. I checked on the scope that all timings are met. I'am near the limits but within datasheet specifications. To be sure on one of the boards I reduced the speed of the controlling state machine in the FPGA to allow a greater margin, but the behaviour stays the same. One USB packet contains 62 Byte of payload (the other 2 are protocol overhead) so the 63rd byte replaces the first byte of the transmission when the first packet is retransmitted.Quote from: marshallh on January 13, 2016, 04:38:24 pmThe ICs I tested came from multiple vendors over a period of 4 years. While I'm not 100% sure, I still belive they are genuine. But maybe the fake ones don't have this bug, would be nice to test one...As for the PCB layout, that was also the first thing FTDI support asked for, I sent them schematics and parts of the layout and they didn't complain. I'm sorry but I can't post them here.Quote from: station240 on January 13, 2016, 04:43:40 pmI haven't found a way of doing that. I can limit the host to Full Speed, but not Low Speed.

author: matkar
author_rank: Regular Contributor
timestamp: February 29, 2016, 07:19:19 pm
content: Have you had any progress on this issue?

author: LeChuck42
author_rank: Newbie
timestamp: March 01, 2016, 06:21:02 am
content: Nothing yet... The FTDI support forwarded the issue to their R&D at the end of January but I haven't heard from them since.