Looks like it might be a 24 pin package with a 20 pin lead frame. Maybe it was designed as a 24pin and they opted for a 20pin lead frame at the last minute, then updated the datasheet to match.
Just got a notice from FTDI that there is a design flaw with the current X-chip family.... Ouch...
Seems sending a certian bit pattern will make it go into suspend mode...
Workaround is to force it to stay awake by disabling suspend...
You know I was just thinking yesterday of changing a couple of designs over to the new chip.
Oddly, I feel more comfortable now that they have found a reasonable sized bug (so long as suspend mode is not required). I'm surprised though that something that big wasn't found earlier... guess it depends on the size of the vector pattern
Looks like it might be a 24 pin package with a 20 pin lead frame. Maybe it was designed as a 24pin and they opted for a 20pin lead frame at the last minute, then updated the datasheet to match.
I think that is just a quirk in the SSOP20 package generally, as you say, they have one molding machine for two pin counts.
FYI: The first two versions of this FT230X chip have issues and are being recalled. A partial snippet from the notice:
As part of our business’ quality management system, we have identified an issue with the
X-Chip Product family that in certain user applications can cause the transfer of data over
USB to stop unexpectedly.
Our investigations into this matter have identified that the device may go into suspend
mode during a transfer of certain data patterns most notably with binary zeros. This can
halt the data transfer in certain circumstances and will require the device to be reenumerated
to recover.
Analysis has revealed that the issue is application specific, and where devices have been
utilised within a new design specification and functioned correctly, there is likely to be no
subsequent issue; however we would not recommend the use of current revision B and C
devices for mass production volumes.
I thought it might be worth posting the recommended solution here:-
"This issue can be avoided by utilising the keep awake function of the chip. This will disable the USB
suspend function of the chip and is therefore an intermediate workaround until revision D silicon is
released with a permanent fix.
NB. With the workaround the chip will never enter lower powered suspend. However the keep awake
current will be approximately 3mA.
To enable the keep awake function in the EEPROM, one of the CBUS pins needs to be configured as KeepAwake#. This pin then needs to be tied to ground on the PCB. The FT_Prog utility can be used to
configure the CBUS pin."
Tubular, I completely agree. Fortunately, my board with this FT230X (designed mostly by a colleague) appears to be working fine without using KeepAwake#. The FTDI chip is powered from the 5 volt output of the buck/boost switcher circuit (not Vusb 5V). Then, CBUS3 is pulled to 3.3v through a voltage divider circuit off of 5V and CBUS3 on the FTDI is reprogrammed to VBUS_Sense. In effect, this prevents the FTDI from being powered down as well, but with the resistor voltage divider circuit, you can pull the CBUS3 pin high or low (by changing resistors loaded) and set CBUS3 to one of the other options to change the operation of the FTDI depending need.
After debugging a reset issue on our prototypes tonight, the board is working fine. From that, I can say that the FT230X chip has been proven as usable with the Propeller. (of course you must change the reset drive in PropTool to "RTS & DTR" so it works with both FT230X circuits and the normal FTDI USB circuit used on all other USB Propeller boards) I hope to share details of our design in a few weeks.
Though I can see that I can reverse RTS# in its MTP memory, there is no settings for Push/Pull vs open drain.
As I have no push-reset button, but I guess the Prop can pull the RESn line to ground in software and causing a short.
Is the cap in series, plus pulldown and transistor still the best (least parts) option?
If you can invert the RTS then a Cap (~1nF) between RTS and RES input is all you need. BOEn must be connected to Ground to enable the internal PullUp at the Reset input.
The Propeller pulls the RES line only to Ground if a BrownOut occurs, and with BOEn Low this is disabled.
Note: After adding the FTDI FT230X to a design, I am rather frustrated, as it is rather buggy. Nothing like the proven ft232 so far. I have rev D, which is supposed to be fixed from something. My suggestion is to avoid this chip like the plague.
Problems:
Randomly quits working after 5-30 minutes, just quits passing data, dying on the chip level perhaps, the TX/RX lights quit blinking.
As of this writing, I have a chip that windows won't recognize, from nothing more than unplugging and replugging after a problem. I have never seen anything like this in the ft232 series.
I think Parallax now use the FT230X on a number of boards, so you could check one of theirs, or one of the UMFT230X modules, to see if the same issues appear ?
The new FT51 looks interesting too, slightly more in price, but much smarter. with i2c and ADC and DAC, so a Prop board could add that for Fast Serial as well as a i2c ADC/DAC expander.
Comments
The QFN versions of both are 4mm x 4mm, so its not the die size
Seems sending a certian bit pattern will make it go into suspend mode...
Workaround is to force it to stay awake by disabling suspend...
Oddly, I feel more comfortable now that they have found a reasonable sized bug (so long as suspend mode is not required). I'm surprised though that something that big wasn't found earlier... guess it depends on the size of the vector pattern
Thanks for sharing...
I think that is just a quirk in the SSOP20 package generally, as you say, they have one molding machine for two pin counts.
As part of our business’ quality management system, we have identified an issue with the
X-Chip Product family that in certain user applications can cause the transfer of data over
USB to stop unexpectedly.
Our investigations into this matter have identified that the device may go into suspend
mode during a transfer of certain data patterns most notably with binary zeros. This can
halt the data transfer in certain circumstances and will require the device to be reenumerated
to recover.
Analysis has revealed that the issue is application specific, and where devices have been
utilised within a new design specification and functioned correctly, there is likely to be no
subsequent issue; however we would not recommend the use of current revision B and C
devices for mass production volumes.
I had assumed the bit pattern might be something more complicated than all zeros! That sounds nasty.
I hope they'll patch it up for rev D and we can be up and running again.
"This issue can be avoided by utilising the keep awake function of the chip. This will disable the USB
suspend function of the chip and is therefore an intermediate workaround until revision D silicon is
released with a permanent fix.
NB. With the workaround the chip will never enter lower powered suspend. However the keep awake
current will be approximately 3mA.
To enable the keep awake function in the EEPROM, one of the CBUS pins needs to be configured as KeepAwake#. This pin then needs to be tied to ground on the PCB. The FT_Prog utility can be used to
configure the CBUS pin."
After debugging a reset issue on our prototypes tonight, the board is working fine. From that, I can say that the FT230X chip has been proven as usable with the Propeller. (of course you must change the reset drive in PropTool to "RTS & DTR" so it works with both FT230X circuits and the normal FTDI USB circuit used on all other USB Propeller boards) I hope to share details of our design in a few weeks.
http://www.mouser.com/ProductDetail/FTDI/FT230XQ-R/?qs=sGAEpiMZZMvVkErl6zY%252bqeI5xuGNHfx4
Though I can see that I can reverse RTS# in its MTP memory, there is no settings for Push/Pull vs open drain.
As I have no push-reset button, but I guess the Prop can pull the RESn line to ground in software and causing a short.
Is the cap in series, plus pulldown and transistor still the best (least parts) option?
The Propeller pulls the RES line only to Ground if a BrownOut occurs, and with BOEn Low this is disabled.
Andy
Problems:
Randomly quits working after 5-30 minutes, just quits passing data, dying on the chip level perhaps, the TX/RX lights quit blinking.
As of this writing, I have a chip that windows won't recognize, from nothing more than unplugging and replugging after a problem. I have never seen anything like this in the ft232 series.
The new FT51 looks interesting too, slightly more in price, but much smarter. with i2c and ADC and DAC, so a Prop board could add that for Fast Serial as well as a i2c ADC/DAC expander.