Cypress CY7C65213 - A pin compatible FT232R replacement?

[PeterFW]

Hello!
The FT232R was for the longest time my device of choice.
But for a number of reasons i would like to switch to another one.

I came across the Cypress CY7C65213 and the manufacturer says that it is pin compatible to the FT232.
It has a number of features wich make it more desireable over the FT232R.

It has USB Charger detection, it runs of 3.3V out of the box and has a nice interface to tell the connected Lithium charge IC what current it may draw.
It lacks the RS485 direction IO but i do not need that.

That all sounds to good to be true, were is the catch?
I only found two references on the forum to this chip, nothing negative.
This is all to good to be true, why is annyone still using the FTDI chip?

Greetings,
Peter

[kizzap]

This is all to good to be true, why is annyone still using the FTDI chip?

Not sure, but at a guess, market saturation.

Give it a try and definitely give us a review. :-)

[SL4P]

Driver support & availability?

[PeterFW]

This is all to good to be true, why is annyone still using the FTDI chip?

Not sure, but at a guess, market saturation.
Give it a try and definitely give us a review. :-)

Ok, after a good nights study of the datasheet i can say, in some situations it could replace a FT232R without anny change to the layout.
But it looks not like a drop in replacement.

For one, the CY7C65213 lacks the on board 3.3V regulator.
If you use the 3.3V output to supply VCCIO it looks like this will not work.

If you run the FT232R on 3.3V with a external resonator, just do not populate the resonator, the CY7C65213 will run at 3.3V with the internal one.
In fact the CY7C65213 does not have and does not need capability to run of a external resonator. The pins on the CY7C65213 are used at two additional IO.

The support at Cypress was very quick to answer my question about the different layout in a "self powered design" when compared to the FT232R.
There might be a difference in power consumption, but since i have no data on that it is a wild guess in the dark.

Currently i have two other solutions to my "USB LiIo charging problem" but for now the CY7C65213 looks like my best bet.

Currently i am waiting for a reply from Cypress on one other question, since i do not want to buy a few chips on a wim.

Greetings,
Peter

[PeterFW]

Welll... got a new reply from Cypress, looks good so far.
I will be ordering a few for testing.

If annyone is interested i could post a update when im finished.
Anny things someone would like to know in perticular keeping in mind that i only have a Scope Meter and Bench supply at hand?
Sadly i will not be able to measure the current consumption, i do not have annything sensitive enough, i considered buying a µCurrent but that is way out of my budger 

Greetings,
Peter

[miguelvp]

I would like a follow up on how it went.

[PeterFW]

I would like a follow up on how it went.

No mayor update.
The samples should be here some time next week, the cypress support/sales team is very quick and helpful.
I routed a small adapter board, the shop were i once ordered PCBs has jacked up the price considerably. And the other one seems not keen on my bussiness. :-(
Might have to order in china and shelf this until the PCBs arrive...

[PeterFW]

The chips would have been here yesterday.
But noone told me that i was alone, so i dit not go downstairs when the Fedex man got here.
I routed a small board with a 3.3V regulator, a bunch of leds and things to plug in.
Either i wait till the boards get here or i wack one of em on a dil adapter, there should be a couple left.

[PeterFW]

Ok... today the mail man handet me a little envelope with a bunch of great stuff:



Yes, there are two bodge wires in there... do not ask. 
My experience with the chip so far:

I put the whole thing on the breadboard, shorted RX and TX and powered it from the bench supply to see if anny magic smoke will be released.
No smoke, everything went fine.

Then i connected it to the powered USB hub and to my delight it was imediately registered by my Windows 7 as a USB-Serial adapter.
No driver installation required, awesome!
Then i opend the terminal and as expected the data send was echoed by the board without problems. All hunky dory!

I paid close attention at this point, if there was anny problem with missing drivers.
None was reported.

I noticed the that the LEDs for power and sleep dit not behave as expected, i checked and i had wired them not to the default pins.
That was ment to be that way, i then remembered, the layout demandet it.
The sun is still shining!

Now for the battery charger detect feature, it is turned of by default.
And since i have to assign the right pins to the sleep and power pin, i have to get to know the configuration utillity.

The CY7C65213 product page led me to the right one, after a brief stay with google and the wrong utillity.
I installed the "USB-Serial Software Development Kit" and then there was a problem.
For one, it dit not install a menu shortcut.
The Cypress folder only contained the link to the update manager, i had to locate the binary and link it myself.

I opend the SDK and... no device found.
The board plugged into the Hub was no were to be seen.
Re-powering the board dit not help either.
Since i installed the "USB-Serial Software Development Kit" i thought everything i need should be installed.
I checked again and there was a "USB-Serial Driver Installer - Windows" listed on the downloads for the SDK.

So... download that, install this... aaaaand?
No dice, still no device found.

At this point i was a bit, disgruntled.

"There has to be a driver problem" i thought to myself and checked the device manager.
Bingo! Missing/Faulty driver for the "USB-UART LP Vendor MFG".
Ok... i just have to (re)install driver, then everything will be fine.

It was not, the driver could not be installed.
What do you do at this point?
Yes, indeed, turn it of and on again!

I closed all my windows, saved all data and prepared to reboot the computer.
After closing the last window there it was!

A little tiny promt, wich had been pushed to the last window layer, no indication on the task bar. Just a tiny promt wich said:

"Installation successfull, windows has to be restarted!" or something like that...
Yea, that should not have happend. Bad, bad SDK!

After that, the clouds lifted, the birds started singing again and the SDK worked as promised.
The CY7C65213 was re configured, the BCD enabled and set up in unter a minute.
The SDK is very self explanatory and not bloated.

A few screenshots:
http://shiosai.de/gallery3/index.php/Electronics/USB-Serial

After enabling it, the BCD feature works as advertised.
When connected to a Charger port it reports 1.5A, when connected to the USB hub it reports 500mA, and not initialised it reports 100mA.
When only powered from the bench supply, without anny resistors or hub on the USB connector, it will say that it is in USB suspend and report 2.5mA.

I will put the board into use on a devboard and continue to use it over the next days and will write an update after that.
But for now, i am very happy with the little thing.

Pro:
3.3V compatible out of the box but requires 3.3V to be supplied by the target.
Battery charger detect.
Cheaper
Not manufactured by FTDI
In most situations fully FT232 pin compatible

Con:
My SDK installation was a bit bumpy.
A few odd configurations will not be 100% pin compatible.

I think this will be my new go-to chip for this task.

[miguelvp]

Thanks for sharing, I did play with it's cousin, the CY7C65211 that comes with the $4 4200 prototype board but to configure it as an I2C bridge, and I don't think it's FT232R pin compatible.

https://www.eevblog.com/forum/microcontrollers/cheap-easy-i2c-dev-kit/msg618200/#msg618200

But I already had the drivers and everything setup from a while back since it requires the drivers to use the prototyping board, so I didn't experience your painful driver install.

I'm glad you got it working.

[PeterFW]

I'm glad you got it working.

And it still is, i have been abusing the board and everything is fine!
There are two things wich had me a bit stumped but seem to be normal behaviour.

If you write code on a µC wich puts out data on a regular interval and you have a LED connected to the CY7C65213 on the TX/RX indicator pins it will flash happily everytime data is send to the board.
If you now rely on this flashing as a "still alive" indicator you might have a bad time

If nothing is connected to the virtual serial port on the PC the RX/TX led will stop flashing and will stay on as long as nothing is connected to the port after a short time.
Even if the µC is still sending data, it might look like the program has crashed but it has not.

The other thing...
If you are connected with a terminal to the port while the device is connected to the PC and you remove the device but keep the terminal open you will get a "windows usb disconnect" sound when you close the terminal program.
This had me terribly confused because my mind would not connect the "sound" to the closing of the program and i thought another USB device was makeing trouble.

These are not problems or bugs but things different to the FT232R.
I still would recommend the CY7C65213 as a FT232R replacement.

Half the price.
More features.
Less power (not measured yet).
Same footprint.
Greater operating range.
Not made by FTDI.
Good techsupport.
As as of writing this, in stock at digikey, mouser and farnell.

[nctnico]

Looks good! I went with Silabs' CP210x as a FT232 replacement because the Cypress part doesn't have the RS485 direction signal.

[miguelvp]

I noticed on your screen captures that you did set the unused GPIOs as inputs (or at least you have the selection highlighted) I usually leave those as tri-state.

I'm jumping into getting libusb to talk to the device directly since the source I found for the USB Serial Library seems to be using that and I found a github with the code, it does seem like the Cypress code, but not available via the Cypress site

https://github.com/cyrozap/libcyusbserial

For windows on top of needing libusb-1.0.9 or higher, it does need pthreads and replacing the #include <unistd.h> entry in CyUSBCommon.h with #include <io.h> (the windows equivalent)
Also I had to add an #include "config.h" at the beginning of that header so the right defines are used.

But I haven't get it compiling all just yet, I'm in the process of adding the pthreads code so I'm not done yet, or I can use libusb /os/threads_posix.h defines (in reverse) to use libusb/os/threads_windows.h instead, so I'm still trying to figure out the best less redundant way to get it all compiled with full source.

The reason for this is because I want to be able to do things the API won't let me, like a continuous burst mode write via I2C without a given size. I know yours is UART only but having source doesn't hurt

I also noticed that the author has an eagle footprint library for the Cypress USB-Serial Bridge chips, which I have not try to use, so I don't know if it's complete for the CY7C625(11, 13 & 15) series and all of the variations.
https://github.com/cyrozap/Cypress-USB-Serial-Eagle-Library

And funny enough he has a depot for:
https://github.com/cyrozap/ftdi-unbricker


Edit: mystery solved on where the source came from. If you download the Linux or Android (and I bet the same goes for osX) it comes with full source. Only the Windows distribution doesn't come with the full source.
http://www.cypress.com/?rID=83110

[BrianB]

Hi there, this is the most relevant topic i could find without starting a new one.

I've been working and a private project and needed a USB-UART transceiver. The place i buy from decided to still only supply the CY7C65213 instead of the FT232RL. Not that it matters i have no experience with either one of them standalone.

So i soldered the transceiver IC on a breakout board and hooked it up on a breadboard the basic self powered way like on the datasheet described. After connecting it Windows gave me a device unknown error and saw that i twisted the transmission wires on the USB side. Fixing this had no effect as windows gave me nothing anymore and didn't recognize any device being connected. I tried multiple times so in the end i thought i zapped the thing somehow and gave up on it.

I soldered a new IC of the same type to a breakout board and tried again. This time Windows did recognize a USB device being connected and started the automatic driver install procedure. It just didn't recognize the "USB-UART LP Vendor MFG" part of the device and so i tried a reboot as suggest in this topic. That did work and USB-UART LP Vendor MFG was recognized making me able to start and connect the cypress configuration utility. I configured the device as self powered and went on to the next step.

I wanted to test the Serial functions, that didn't work as the "Virtual Serial Port Device 00"(I think this is the virtual COM port ?) was still not being recognized by Windows. I tried to reinstall the official drivers without any success, with a frustrated feeling i gave up for the day. The next day i connected my setup once again to my PC just to tell me that the device was again not recognized. I tried again many times without success and so i am here now.

I don't have a proper way of grounding here on my floor but i don't think that could be the cause of issue. Is this my Windows install giving up on me or did i break something essential. All i'm trying to do is setup and bare bones ATMEGA328P(with arduino bootloader firmware) to connect with the IC as way for me to connect to my PC.

Here some pictures as illustration. Many Thanks, Brian.

[cyrozap]

But I haven't get it compiling all just yet, I'm in the process of adding the pthreads code so I'm not done yet, or I can use libusb /os/threads_posix.h defines (in reverse) to use libusb/os/threads_windows.h instead, so I'm still trying to figure out the best less redundant way to get it all compiled with full source.

I've made a lot of progress on this issue (https://github.com/cyrozap/libcyusbserial/tree/fix-windows-build) but the Appveyor build is still failing for some reason. If you want to help test this at all, I'd really appreciate it, especially when it comes time to package the whole thing since I don't actually run Windows myself.