FT231X sending binary files strangeness

jmg

A weird one here, someone else may have seen...?

I have a FT232R on a QuickStart and a FT231X on a Prop Project Board.

Doing simplest File copy/echo tests with Prop = RST and TX-RX jumpered.

The FT232R is 100%, repeatedly echos ASCII and Binary files of a range of sizes.
FT232H also seems 100%, as does CP210x tests.
The FT231X echos ASCII files (eg 'U' repeated test patterns 100%,
but, it locks out on even small binary files, in an erratic manner.

Sometimes (rarely) it will send the smallest 896 bytes and echo, but usually fails at variable byte counts.
Recovery is to remove USB connector and re-attach.
Binary files are mostly $00H with some header/address bytes.

I can't find another FT231X to test, but it does seem weird.
It does not seem to be exact position or content, triggered, so what does that leave ? Average voltage of Chars ?
Is this a FT231X problem, or some power issue on  Prop Project Board ?

More:
The data is simple enough, usually 16+ lines as below, repeated 3 byte Hdr + 53 x 0x00 which fails.Test Baud rate is 250k


[code]Thinking about the average voltage angle, I changed a single 0 to 255, and slid-along in the file. (above is 35 test case )
Voila,
31 0x00 then 255, then more 0x00 never fails,
35 0x00 fails most of the time.
Looks
like between 31 & 35 is the 'magic trigger'- & maybe a power
supply issue ? (or some undocumented back-door on a FT231X ?)

Are there known issues with FT321X + Prop Project Board combination ?

Addit : The ProjectBoard has optional external power -> SMPS, so I connected 9V DC to that - and that helps a little.
Yields do go up, but not to 100% - something looks amiss in the FT231X implementation on PPB ?
I have only one, so cannot compare another, but it does not feel like a faulty chip as it is so data-content dependent.

jmg

A simple test case attached 
When I use

MODE COM9:57600,N,8,1 
copy /b Char_U_10000.txt \.COM9:
copy /b Bin5053.bin \.COM9:

The first file is 50% bit density ASCII and always works. (and text file seems to work)
The second file has many 0x00 bytes, and fails most of the time, only on FT231X + PropProject Board.
(FT232R, FT232H, CP2102 all do this fine )

Can anyone with a Prop Project Board, try a simple CMD copy on the attached small  binary file, and see if this is widespread issue ?
- A test on a FT231X, not on a Prop Project board would be great too.

Tubular

I remember there was an issue with early FT230's with repeated binary 00's.  Here's their note saying rev D silicon (and onwards, presumably) would fix this.  
I don't know whether the same affects FT231's, but it sounds along the same lines
http://www.ftdichip.com/Support/Documents/TechnicalNotes/TN_139_FT230X%20Errata%20Technical%20Note.pdf

jmg

I remember there was an issue with early FT230's with repeated binary 00's.  Here's their note saying rev D silicon (and onwards, presumably) would fix this.  


Aha ! Magic.
Here I was thinking 'Nah, FTDI would never ship a part with so fundamental a bug..."

I dug out the PPB SCH and it joins CBUS0.CBUS1, fired up FT_Prog and flipped CBUS0 from BCD_CHARGER# to KEEP_AWAKE#, which is driven by the PWREN# on CBUS1.

Seems to now work 100% on that Binary content test.

Not sure I can read the marking...but I think it says 1220 date code, which is pre RevD

Tubular

Never assume what FTDI would, or would not, do : )

Heater.

jmg,

'Nah, FTDI would never ship a part with so fundamental a bug..."

Ah, such sweet innocence.

FTDI are not a company to be trusted:
http://blog.erratasec.com/2014/10/the-deal-with-ftdi-driver-scandal.html#.Va87fHWlxBc

Tracy Allen

Interesting, troubling.   Here's a link to TN-140 for the FT231 specifically. 
TN_140_FT231X Errata Technical Note
In either chip the bug exists up to rev C, but was squashed in rev D, November 2012.   No known problems (yet?) with rev D.  Something to check when purchasing these parts.

Tracy Allen

Chip version identification...
43rd week of 2014, ver.D