USB-UART bridge IC - powering VDDIO when VDD unpowered

[HwAoRrDk]

I am wanting to incorporate a USB-to-UART bridge IC into a project design, and the one I will probably use is the Holtek HT42B534.

This ICs has several power pins. One is the main VDD, intended to take power from the 5V USB VBUS. Another is the core voltage, V33O, which as I understand it is only made available externally for decoupling and as a convenience for any other parts that need a 3.3V supply. The last is VDDIO, which is used to power the UART RX/TX pins at a voltage of the user's choice (i.e. whatever your micro is running at).

I have doubt about the relationship between VDD and VDDIO, and whether how I have things set up will work properly or cause problems. Basically, I'm unsure as to whether it's okay to have VDDIO powered when VDD is not.

My design is such that the USB is not the main source of power, and has it's own 5V supply. Currently, I have VDD fed from the USB VBUS, and VDDIO from the board's 5V rail (i.e. not from USB). But I'm not sure if this is a good idea.

The Holtek datasheet linked above has an application example (page 10) showing the main circuitry powered from 3.3V battery, supplying the chip's VDDIO, and the VDD coming from VBUS. However, they have a diode between VDDIO and VDD to supply VDD when the USB is disconnected. Should I do the same? But one confusing thing here though is that the specs say that VDDIO must be no higher than VDD, but with the example circuit VDD will clearly be below VDDIO due to the diode's forward voltage drop.

[Ian.M]

They're using a 1N5817 1A Schottky diode.   Its Vf drop at under 20mA will be a couple of hundred mV at most, far less than the voltage at which the silicon PN base junctions of any parasitic transistors present in the interface between the core and the I/O will start to conduct significantly and possibly trigger latchup.  The datasheet is less than clear on this point as they don't quote an abs. max. voltage rating for Vddio - based on what's typical for MCUs and complex logic etc. from various manufacturers, there's typically 0.3V margin outside the rails.

N.B. you'll also need a 1N5817 in series with USB Vbus so it cant back-power the USB port on the host if the host is off or in power-saving.

[HwAoRrDk]

Ah, okay, thanks.

So, out of curiosity, are you saying that if a diode was used that had a higher forward voltage, it might be troublesome, but a schottky is fine?

I guess I could use a common-cathode schottky pair in SOT23, like a BAT54C - common-cathode to VDD, one anode to VBUS, other to 5V rail. Ah! And I realise as I type that this will essentially be an OR-ing arrangement.

My understanding of the back-feeding with USB power is that it's generally not an issue when connecting to desktop/laptop PCs, as they commonly feature back-feed protection, but other devices may not, and who knows what someone may plug in, so probably prudent to always avoid back-feeding where possible.

[HwAoRrDk]

Actually, I'm just thinking: why power the USB-UART bridge IC from VBUS at all?

Is there a need to do that? Can I not just leave the VBUS pin on the USB connector unconnected, and power the HT42B534's VDD pin from my internal 5V rail? Then no extra diodes needed at all.

Edit: Ah, if I do that I'm going to need a bigger 5V regulator. The SOT89 I was planning for will be marginal on power dissipation with an extra 16mA.

Could I do the opposite, and power VDDIO from VBUS? The only problem I can imagine with that arrangement is if: a) USB and rest of my circuit don't share a ground (they will), or b) 5V levels from VBUS and my regulator vary too widely, and I get excess current flow through the UART pins on the HT42B534 and/or my microcontroller. For the latter, could put series resistors on RX & TX to mitigate this possibility, though, right?

[Peabody]

If you power everything from the project's supply, you would need to determine the idle state of the UART outputs when USB is not connected - to make sure they won't confuse your processor.  In theory they should all be high.  But I think this would be a good idea if the power usage isn't a problem.  It eliminates having to deal with what happens when you apply voltage to devices which aren't powered up.   Everything comes up at the same time, so protection diodes don't come into play.

[Ian.M]

I would be a bit careful about using a low current single package Schottky pair - the datasheet's speccing a 1A part just for its low Vf drop.

Actually, I'm just thinking: why power the USB-UART bridge IC from VBUS at all?

Is there a need to do that? Can I not just leave the VBUS pin on the USB connector unconnected, and power the HT42B534's VDD pin from my internal 5V rail? Then no extra diodes needed at all.

Edit: Ah, if I do that I'm going to need a bigger 5V regulator. The SOT89 I was planning for will be marginal on power dissipation with an extra 16mA.

Could I do the opposite, and power VDDIO from VBUS? The only problem I can imagine with that arrangement is if: a) USB and rest of my circuit don't share a ground (they will), or b) 5V levels from VBUS and my regulator vary too widely, and I get excess current flow through the UART pins on the HT42B534 and/or my microcontroller. For the latter, could put series resistors on RX & TX to mitigate this possibility, though, right?

Personally, I'd power the whole bridge chip from USB Vbus then use 74LVC1T45 level translating buffers (or 74LVC2T45 for a pair of signals in the same direction) for data line isolation when one side is powered down.  Add pullups/pulldowns on the MCU side to force the desired 'No USB' state on inputs to the MCU.  That gives you the lowest possible power consumption when USB isn't connected, and guarantees the USB UART bridge power-on resets each time its physically connected.   

[HwAoRrDk]

If you power everything from the project's supply, you would need to determine the idle state of the UART outputs when USB is not connected - to make sure they won't confuse your processor.  In theory they should all be high.  But I think this would be a good idea if the power usage isn't a problem.  It eliminates having to deal with what happens when you apply voltage to devices which aren't powered up.   Everything comes up at the same time, so protection diodes don't come into play.

Hmm, good point about levels of RX & TX, that I guess applies to either scenario (USB- or device-powered). The datasheet doesn't mention whether the HT42B534 has internal pull-ups.

It is my understanding that common practice with serial UART communication is that it should be the receiving device's responsibility to pull-up its RX line (I don't remember where I read it). I normally configure a micro's RX pin with the internal pull-up enabled, but not on the TX pin, under the assumption that the opposing device will be pulling up it's own RX pin.

In the scenario where the HT42B534 is totally powered from VBUS, and I implemented pull-ups as above, then any lack of pull-up on the HT end will be irrelevant, as it can't get confused state when un-powered, and the micro won't get confused because of it's own pull-up on RX.

I would be a bit careful about using a low current single package Schottky pair - the datasheet's speccing a 1A part just for its low Vf drop.

Erghh, you're right. BAT54C specs are all the over place for Vf, depending on which manufacturer you happen to choose. Varies from 0.2 to 0.4V at 20mA.

Personally, I'd power the whole bridge chip from USB Vbus then use 74LVC1T45 level translating buffers (or 74LVC2T45 for a pair of signals in the same direction) for data line isolation when one side is powered down.  Add pullups/pulldowns on the MCU side to force the desired 'No USB' state on inputs to the MCU.  That gives you the lowest possible power consumption when USB isn't connected, and guarantees the USB UART bridge power-on resets each time its physically connected.   

Wouldn't a 2T not work, as it only has a single DIR pin that applies to both A and B? A and B would need to have opposing directions, surely. Not sure I would have room on the layout for either, anyway.

But what about what I said earlier about a direct RX/TX connection with series resistors? Any reason not to do that?

[Ian.M]

The two channels of a 74LVC2T45 share one DIR pin and they both go in the same direction, controlled by its level.  Therefore you wouldn't use it if all you want is RX and TX, but if you want handshake lines as well, it will keep the component count down.

Resistors to limit the partial power-down current through internal protection diodes can work, but you can still run into issues with the device on the un-powered side being partially powered via its I/O pins.  This can lead to problems with power-on reset  and/or unexpected RAM contents.   If you make the resistors large enough you can avoid trouble but may run into data integrity issues at high baud rates.      I'd use LVC...T buffers for a one off or small volume  for a solution that 'just works', but resistors for high volume after thorough testing if I had a penny-pinching manager breathing down my neck or if I was *extremely* board area constrained.

[HwAoRrDk]

The two channels of a 74LVC2T45 share one DIR pin and they both go in the same direction, controlled by its level.  Therefore you wouldn't use it if all you want is RX and TX, but if you want handshake lines as well, it will keep the component count down.

Sorry, I don't quite get what you mean. I "wouldn't use it if all you want is RX and TX"; 'it' being the DIR pin or the component as a whole? No handshaking, just RX/TX - I would be using the 8-pin version of the Holtek, which doesn't have any DTR, RTS, etc.

If you make the resistors large enough you can avoid trouble but may run into data integrity issues at high baud rates.

As in, too large a value and it will make the rise/fall times too slow, which won't meet requirements for higher baud rates? I would probably put a 10K in. I don't plan on going above 115.2K (probably 57.6K). If one wanted to work it out, I suppose it would depend on the pin capacitances?

I'd use LVC...T buffers for a one off or small volume  for a solution that 'just works', but resistors for high volume after thorough testing if I had a penny-pinching manager breathing down my neck or if I was *extremely* board area constrained.

The only penny-pinching manager is myself.

I'll probably only have about a 20x25mm area to fit bridge IC, ESD diodes, USB Mini B connector and supporting passives, so board space will indeed be tight, so I'm favouring the resistors right now. (And before anyone says "20x25? Pah, luxury!", I want to be able to hand solder this, so I'm not using minuscule components. )

[Peabody]

What I've found with other bridge chips is that pretty much all their pins will sink current when the bridge chip is powered down.  They don't tri-state.  If the Holtek also works that way, then a good bit of current could flow out of your processor TX pin when USB is not connected, and your RX pin could still be pulled low even with a pullup resistor.

I would suggest you get a couple Holtek chips and play with them before making a final decision.  One test would be to apply a 5V source to the bridge's TX or RX pin while it's powered down, and see how much current flows.  I did that with the CP2102, first using a series resistor, but finally with no resistor, and ended up with it drawing about 11ma for TX, but current through RX was even higher.  Of course the Holtek may be completely different, but you need to know for sure.

[HwAoRrDk]

I have decided to go with using a pair of 74LVC1T45 in SOT23-6. There was enough room in the layout to squeeze them in, and the chips are pretty cheap (pennies each).

Both DIR pins connected directly to ground, giving B as input, A as output; on one IC, micro's TX in to B and A out to HT42B534's RX, with VCCB on 5V and VCCA on VDDIO (i.e. VBUS); the other with HT42B534 TX in to B and A out to micro's RX, with VCCB on VDDIO and VCCA on 5V rail.

When my device is powered but USB is unconnected, UART lines will be tri-stated but RX will be asserted high by an internal pull-up on the micro (and TX is actively driven). If for some reason the opposite scenario occurs - where USB is plugged in but device is otherwise un-powered - the HT42B534 UART pins will be floating, but that shouldn't be a concern as the user won't be able to do anything with the device. I suppose there is the possibility of garbage characters being transmitted over the serial link, but who cares?

[Ian.M]

If for some reason the opposite scenario occurs - where USB is plugged in but device is otherwise un-powered - the HT42B534 UART pins will be floating, but that shouldn't be a concern as the user won't be able to do anything with the device. I suppose there is the possibility of garbage characters being transmitted over the serial link, but who cares?

Windows may care!  You'd be surprised what it can mistake as a serial mouse at bootup or when enumerating new hardware.
Usually its GPS receivers that are mis-enumerated but other low baud rate random datastreams can also cause issues.

See https://what.thedailywtf.com/topic/17599/serial-mouse-still-in-windows-10-trigger-warning-disabled

If you can sneak in a pullup on TXD from your MCU on the bridge side of the buffer I strongly recommend fitting one.

[Peabody]

The TI datasheet for the LVC chip says A&B go tristate if either Vcc supply pin is at "ground".  As opposed to floating, I assume.  If USB is unconnected, or your project supply is off, will the relevant Vcc be grounded?

I just wonder whether the flexibilty given to you by the separate VDDIO pin wouldn't allow you to connect the adapter directly to the MCU and avoid the need for two extra chips.  But I'm not really familiar with the Holtek, and maybe that won't work.

[HwAoRrDk]

Windows may care!  You'd be surprised what it can mistake as a serial mouse at bootup or when enumerating new hardware.
Usually its GPS receivers that are mis-enumerated but other low baud rate random datastreams can also cause issues.

I had heard of that. Yes, kinda stupid. My device is highly unlikely to be plugged-in during bootup/restart, though - it's something you'll plug in only as-and-when-necessary to tweak settings via a serial console, not remain connected at all times. But, still, I can appreciate the risk of this problem occurring...

If you can sneak in a pullup on TXD from your MCU on the bridge side of the buffer I strongly recommend fitting one.

You know, looking again at the datasheet for the Holtek (for the millionth time), I have come to the conclusion that it must have internal pull-up resistors on the RX/TX pins, as evidenced by a section of the DC Characteristics table entitled 'I/O Pins Pull-high Resistance' (figure given is typical 30K @ 5V VDD). The UART pins are I/O pins, are they not? All the other I/O pins - on higher pin-count versions - are flow-control and active-low too, so why would they put them on those and not also the actual RX/TX? So I don't think I need to worry about adding pull-ups on the bridge side.

The TI datasheet for the LVC chip says A&B go tristate if either Vcc supply pin is at "ground".  As opposed to floating, I assume.  If USB is unconnected, or your project supply is off, will the relevant Vcc be grounded?

This has been nagging the back of my mind the last couple of days.

When they say "at ground", I believe they mean that either of the VCCx pins is at the same potential as the GND pin. The datasheet for the NXP version of the 74LVC1T45 even specifically states this: "When either VCC(A) or VCC(B) is at GND level, the device goes into suspend mode" - suspend mode being with A & B tristated.

The whole device will share a common ground, so, I suppose the question is, when USB is disconnected, will VBUS be at the same potential as ground? I don't know. I am going to be using a TVS diode package on the USB (ST USBLC6-2), so maybe the VBUS would be gently pulled to ground via the leakage current of the diodes?

[Peabody]

The TI datasheet for the LVC chip says A&B go tristate if either Vcc supply pin is at "ground".  As opposed to floating, I assume.  If USB is unconnected, or your project supply is off, will the relevant Vcc be grounded?

This has been nagging the back of my mind the last couple of days.

When they say "at ground", I believe they mean that either of the VCCx pins is at the same potential as the GND pin. The datasheet for the NXP version of the 74LVC1T45 even specifically states this: "When either VCC(A) or VCC(B) is at GND level, the device goes into suspend mode" - suspend mode being with A & B tristated.

The whole device will share a common ground, so, I suppose the question is, when USB is disconnected, will VBUS be at the same potential as ground? I don't know. I am going to be using a TVS diode package on the USB (ST USBLC6-2), so maybe the VBUS would be gently pulled to ground via the leakage current of the diodes?

For what it's worth, I used the MC74VHCT50A in a similar situation using the CP2102 adpater.  That part also claims tristating when Vcc is grounded.  I specifically tested for that, and found that there was no tristating when Vcc is floating.  In that example, the solution was to drive the 50A's Vcc from the 3.3V regulated output of the CP2102, which itself goes to ground when the CP2102 is unpowered.  It's not low-impedance ground, but close enough.  So, you're going to have to physically test this in the configuration you want to use.  Also, it's not clear to me from the datasheet whether you still get tristating if one Vcc is grounded but the other is floating.  Taken literally, that should be the case, but I think you would want to test that.

So the LVC behavior is going to depend on what happens to the Vccx sources when they are powered down.  But if those sources don't go to ground when off, you may be able to power from other sources that do behave as you need.  For example, you might be able to power from one of the Holtek outputs, such as DTR, instead of VBUS. You just need something that is normally high when On, but will sink a little current when power is Off.

[HwAoRrDk]

I finally got a board designed, made and assembled with the Holtek chip, as well as a pair of 74LVC1T45s as discussed. It seems to work well, but there is one annoying problem: I cannot program my microcontroller while the USB is attached!

It's not the end of the world, but it's mightily inconvenient to have to un-plug and re-plug the USB cable every time I want to program the MCU.

I think I might know what the issue is, but I thought I'd check back here to see if others agree.

The microcontroller I'm using is an ATmega32M1, and the UART TX and RX pins on that are unfortunately shared with the MOSI and SCK pins for serial programming. Previously, on other projects that I've used the ATmegaXXM1 series on, when using an external UART-USB adapter, it's not been an issue, as all it meant was that a bunch of garbage got spewed across the serial terminal every time the microcontroller was programmed.

However, now with the Holtek USB interface, I think that things are not working for the following reason:

- The Holtek chip has an internal pull-up on its TX pin.
- The 74LVC1T45 transceiver on that line, as there is continuous power on both VCCA and VCCB, carries on replicating the signal from B to A.
- The A output is connected to the MCU's RX/SCK pin, and is actively being driven high.
- Because of this, during programming, my AVR-ISP MkII cannot apply a proper clock signal, so programming fails.

Is that likely to be the problem?

Any ideas on what can I do to resolve this? I have one idea myself, but it will involve tweaking the design and probably not do-able by bodging the current board.

I am currently running both 74LVC1T45s with the DIR pin grounded, so that signal goes from B to A. I could change the one that's on the SCK/RX pin to the opposite polarity (A to B) and connect its DIR pin to the MCU's reset line (where I have a discrete pull-up resistor), so it is normally pulled high. Then, during programming, while the reset line is pulled low for the duration of operations, the polarity of the 74LVC1T45 will be reversed (now B to A) and the SCK signal will be fed to the Holtek's TX pin, hopefully without issue.

Or am I over-thinking this and I just need to do something simple like add a series resistor to the MCU-side RX/SCK and TX/MOSI lines?

[Ian.M]

Contention with the strong drive from a '1T45 in output mode would *NOT* be good for the Holtek TX pin.

Personally, rather than increase the complexity and respin the board, I'd live  with the need to disconnect USB before doing AVR ISP, and put a bootloader on the MCU so I could flash it over the UART with a simple button to ground /RESET plugged into the ISP header to trigger bootloader entry.   If that doesn't fit your workflow, I'd suggest getting a USB switch, so you can connect/disconnect it at the push of a button.

The only reason to add the resistors is if you need to make it as idiot-proof as possible because you anticipate all the lUsers out there needing to program your board by AVR ISP.

[HwAoRrDk]

Contention with the strong drive from a '1T45 in output mode would *NOT* be good for the Holtek TX pin.

I had a fear that might not be a good idea either, hence the "hopefully without issue". Oh well.

One thought: are there any transceiver/buffer parts out there that are like the 74LVT1T45, but with an enable pin? That would be nice, to be able to 'shut off' the UART connections during ISP programming.

Personally, rather than increase the complexity and respin the board, I'd live  with the need to disconnect USB before doing AVR ISP, and put a bootloader on the MCU so I could flash it over the UART with a simple button to ground /RESET plugged into the ISP header to trigger bootloader entry.   If that doesn't fit your workflow, I'd suggest getting a USB switch, so you can connect/disconnect it at the push of a button.

I have been briefly looking at using a bootloader, to gain the possibility of firmware updates over the USB. There appears to be an adaptation of Optiboot for the ATmega32M1 (although not sure if the GitHub pull request got merged into the main thing). I think serial programming for that using the STK500 protocol in Atmel Studio might simply be a case of going to Tools->Add Target and choosing 'STK500' and the COM port the Holtek USB appears as. One question mark, however, is whether Optiboot being GPL licensed means I'll be able to sell this device in the future if I want to.

[Ian.M]

If you take your idea of reversing the '1T45 direction and add a 1K resistor between the '1T45 and the Holtek TX output, it will limit the current to what the TX pin can handle.  Put the resistor as close as possible to the '1T45 to minimise noise pickup and do least evil to the serial data edges.   

Another idea would be to power the MCU side of the '1T45 in the TX ine from the Holtek from another 1T45's output acting as a buffer for the /RESET signal.  That will make the inline '1T45's output Hi-Z when reset is low.   It may need 1nF decoupling on the power in powered from the output.