Embedded USB-to-serial converter

I could use some help thinking through what options I may have, if any, for embedding a CP2102 USB-to-serial converter into a MSP430 microprocessor project, so that updating the flash could be done with just a USB cable. The processor would be a MSP430G2231.

This function is built into Arduino boards, which have more powerful processors with dedicated pins for all the USB and serial stuff. But the

2231 only has 14 pins.

The idea is to embed a CP2102 module like this one:

formatting link

on the project board, with its USB socket accessible through a port in the case.

99.9% of the time, the CP2102 will not be connected to USB, and will therefore be powered down. The problem is that the serial input and output pins of the CP2102 will be permanently connected to processor pins normally used for other things. I had hoped that when powered down, the CP2102 would go all nice and tristated, but alas, that's not the case. I guess it's mostly the protection diodes, but when the CP2102 is powered down, its 3.3V regulated output pin will sink 9 ma of current when 3.5V is applied to it from the project. TXD and DTR sink the same, but RXD will sink over 12 ma. I had expected to need a diode for the 3.3V supply, but the other pins were a disappointment. Anyway, any processor pin directly connected to these CP I/O pins will be effectively grounded, at least down to a diode drop above ground.

For a moment I thought I had a very simple cure, which was inserting a diode in the CP2102's ground connection to the project ground. That would indeed prevent all that current from flowing backwards. But that still leaves the problem that the processor pins connected to TDX and RXD are still connected to each other though those two pins and all the CP2102 circuitry behind them, and the effective resistance between them measures fairly low.

So I've tentatively concluded that all four lines need to have diodes to prevent any interference with the project circuit when USB is not connected. Then I would need to enable the processor's built-in pulldown resistors for the processor pins connected to DTR and TXD, and add a physical pullup resistor on the CP2102 side of the diode on the RXD pin since the processor output pin will only be able to pull it down when transmitting because of the diode.

And leaving the CP2102 powered up would use up way too much current. The whole point of the MSP430 stuff is micropower.

Well I'm just curious whether there's something I haven't considered that would be a more elegant solution. Of course the typical solution for these MSP430 chips is to have a female header in the circuit, and only connect the an external USB adapter when it's time to flash. But I would rather embed the adapter if I can get away with it. At this point I'm looking at the adapter module, four diodes, and a resistor, which would certainly be fine if that's the best I can do. But if anyone has a better solution, please let me know. I've got all the software written for both ends to implement this bootstrap loader protocol, but should have considered the hardware earlier. But if I can get it all to work, I plan to post it all on Github in case someone else might make use of it.

Reply to
Peabody
Loading thread data ...

Den torsdag den 23. marts 2017 kl. 23.35.29 UTC+1 skrev Peabody:

tried keeping it in reset and or pulling VUSB(sense) low?

5.8V abs max on io doesn't sound like it has esd diodes to Vcc

-Lasse

Reply to
Lasse Langwadt Christensen

First, I'd use an FTDI chip, but only because I've used them.

Second, at least with the FTDI chips, you can power them from the board side and enable them with the USB 5V supply -- this would probably leave the output pin at low impedance, but the input pin would be high impedance.

Third, you could use analog switches tri-state buffers, enabled with USB power.

--
Tim Wescott 
Wescott Design Services 
 Click to see the full signature
Reply to
Tim Wescott

We use the FTDI FT230XS USB-to-serial chip on our boards when we want to add a slowish USB interface to a small ARM chip, through a uP serial port.

--
John Larkin         Highland Technology, Inc 

lunatic fringe electronics
 Click to see the full signature
Reply to
John Larkin

Using the analog switches would be my vote. I use them for level shifting between 5 and 3.3 volts. I've also used some parts before that go tristate when powered down so you could put them on the power rail of the USB chip and not even tristate them, just power them down. I don't know the part number off the top of my head, but I could look it up for you if you are interested. They were Maxim parts which makes some people spit when they say the name. To pass the 3.3 volt power you would need to power the switch from a higher supply like 5 volts.

--

Rick C
Reply to
rickman

I don't know what the OP's priorities are for designing this board, but surely by the time you are adding analogue switches, it would be smaller and cheaper just to use a microcontroller with a couple more pins?

But I agree on the FTDI choice - they are the nearest there is to an industry standard.

Reply to
David Brown

The same function is built into the MSP430 launchpad.

--
This email has not been checked by half-arsed antivirus software
Reply to
Jasen Betts

The FT230X has a reset pin which puts the output pins into a high Z state when asserted. John

Reply to
jrwalliker

FTDI says the FT230X operates at 8 ma. The MSP processor in this case runs at full bore at 8 MHz on less than 1 ma, and the power draw for the entire circuit on my last project using this chip was under 3 ma. So the USB adapter chip has to be powered by USB.

Reply to
Peabody

If you don't mind looking it up, I would be interested in the Maxim part you used. I don't know why people would spit. Is there something wrong with them?

And as Tim Wescott said, a non-inverting buffer would also work, but even the low-voltage ones that are "tolerant" still appear to have some kind of ESD protection that would sink current when they are powered down. Instead of a protection diode from the input or output to Vcc, it needs to have a 3.6V or even 5V zener to ground. That wouldn't get in the way when powered down. But I haven't found one like that.

Reply to
Peabody

I may have found one that would work. Maybe.

MC74VHCT50A

hex buffer, non-inverting.

formatting link

Reply to
Peabody

Didn't they have a faux-pas where they released a version of their driver that would brick the knock-offs? Or was that Prolfic? Or it may have been both, lol.

formatting link

formatting link

God! I hate the Hackaday site. I almost go blind looking at their pages.

You see the problem with FTDI, right? If you buy their product you have no way of knowing for sure you don't have counterfeit parts... until you update drivers and the parts stop working. Best in my opinion to buy parts that *aren't* FTDI at all and your drivers will keep working.

I have USB serial adapters using the CH430/CH431 chips and they work fine. I will never have to worry about them getting bricked by a software update.

--

Rick C
Reply to
rickman

the cp2102 datasheet says max 5.8V on any io pin with respect to ground, that sounds like a zener to ground

Reply to
Lasse Langwadt Christensen

The part I was thinking of is the MAX4662. But I can't find in the data sheet that it says the parts go hi-z when powered down. A customer used this part on one of his boards to isolate from the outside world and wanted me to do the same. Then he changed his mind and I used an ADI part that should have cost less, but was new and when we did our production run the ADI part was just as expensive. Liars...

So I never tested or even used the Maxim parts, but he said they could have two systems wired together and just power one down with no interference because of these chips. The ADI chips definitely don't do this. But the power consumption of the chips is sub-uA. No real reason to not power them from the CPU supply and get isolation by tying the enable to the CP2102 power and/or a CPU output. You can use a resistor to power and an open drain output from the CPU.

--

Rick C
Reply to
rickman

I was just guessing about it being protection diodes that caused the problem, but not guessing that when I apply 3.3V to the RXD pin when it's powered down, 12.8ma flows. For the 3.3V regulated output, TXD and DTR it's only 9ma.

Reply to
Peabody

Thanks very much. I'll look it up.

Reply to
Peabody

We did not see any problems - but then, we haven't used counterfeit devices.

I think in this case, the parts were known counterfeits - cheap alternatives to the real devices.

There is always a risk of someone making counterfeit parts, and always a risk of someone managing to con them into the supply chain somewhere. The best you can do is to get your parts through reliable distributors who do their best to check /their/ suppliers - if you buy your parts from eBay, Alibaba, or

formatting link
then you are at high risk.

How do you know that? You have no greater assurance than you did for FTDI devices - the same folks making drivers for those chips could have ideas to stop the same type of counterfeiting. You can look up on the web for the problems people have had with cheap Arduino clones that don't work with the CH430 drivers. And of course you will always have to worry that future versions of Windows will not support the chips (or the chip drivers will not support future versions of Windows - either way, you have the same problem).

I can't see any way in which this is better than using FTDI.

Reply to
David Brown

I don't buy these parts, at least not yet. I buy boards with serial converters on them. All of the USB serial ports I buy these days have the CH340 chip which seems to work just fine.

Because a counterfeiter won't make CH340 parts they can only sell for $0.25 when they can make FTDI or Prolific parts they can sell for $1's.

--

Rick C
Reply to
rickman

they are used on Arduino clones and I've seen numerous people have problems with bytes lost when there is lots of duplex traffic

Prolific where the ones that started putting out drivers that didn't counterfeits so everyone stopped using Prolific because you never knew if they would work or not, everyone switched to FTDI because that just worked then FTDI started doing the same, taking it a step further and pushing it through windows update, first was deleting VID/PID then even worse sending garbage on the serial side

-Lasse

Reply to
Lasse Langwadt Christensen

[...]

If anything, that should teach us the real worth of interfaces that need a specific driver for every damn gadget. Down with

Jeroen Belleman

Reply to
Jeroen Belleman

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.