Disable USB power without modifying the board.

I bought out of this with reply #3.

Seemed pretty clear to me.

It does seem straightforward...

Food for thought

COOL !

Good ol' Silicon Chip!

(Magazine.)

Backstage:
Less than ideal but at least shutting off the switch reduces the possibility of electrocuting myself. If anyone has any ideas that might help with re-establishing the serial comunication without messing with the cable, please let me know.

You've left UVCC floating on U3 (ATmega8U2) of your Arduino Uno -> https://www.arduino.cc/en/uploads/Main/arduino-uno-schematic.pdf

Figure 20-5 of the ATmega8U2 schematic shows the connections to the chip for a self-powered application -> http://www.atmel.com/images/doc7799.pdf

Figure 7-46 of the USB 2.0 specification shows why -> http://sdphca.ucsd.edu/lab_equip_manuals/usb_20.pdf

Why do you have the requirement to not modify your board?

raschemmel:
...
Everything is under the microcontroller's control, such that if the uC loses power, EVERYTHING loses power.
...

Exactly, raschemmel. Problem is, with the USB connection, when the power switch is shut off the uC doesn't lose power. That is my point. When this starts up it does so in a relatively "safe" state and then engages contacts and powers other components via relays. I don't want the STOP button to rely on the sketch to power everything down using an interrupt. No amount of software testing is going to replace a physical disconnect of power.

The uP has to disconnect it's I/O BEFORE power down because ANY I/O connected to the GPIO or ANALOG pins of the arduino when the arduino power is removed will cause BACK-FEEDING of voltage through the I/O pins , REGARDLESS of the absence of power to the arduino 5V pin or Vin pin. That's right. If you don't believe me, connect an analog input pin to a separate 5V source , with NOTHING CONNECTED to the arduino input (Vin) or the arduino 5V pin, and you will see that the arduino is powered through the analog pin connected to an external voltage. This "BACK-FEEDING" also occurs with digital I/O.

It is a mistake to think that it is even possible to "DISCONNECT" power to the arduino when you have I/O CONNECTED. The I/O will back-feed through the internal protection diodes and power the arduino.
I think you need to reread my previous post. I said the I/O power should be powered via N.O. contacts on relays that are powered by the arduino. If the stop button kills power to the arduino, it therefore kills power to the relays and contactors that were relying on the relay powered by the arduino. When THAT relay deenergizes, it kills power to the high power contactors as well. Either you didn't read what I said or you don't understand what I am saying.

1- ALL EXTERNAL I/O should be powered through N.O. contacts of a relay powered by the arduino. If the arduino loses power, the high power contactors lose power. This is strictly a HARDWARE INTERLOCK, (NOT A S/W INTERLOCK) I realize I did mention having a software shutdown procedure but if the design follows the guidelines I described a STOP button would kill everything.

2- Any voltage connected to ANY I/O pin (analog or digital) will BACK FEED THROUGH THE PROTECTION DIODES TO THE ARDUINO 5V and power the arduino. That's's why the I/O needs to be isolated by relay N.O. contacts. You can have I/O connected when the arduino is off only if that I/O is not a voltage that can back feed to the 5V pin.

Problem is, with the USB connection, when the power switch is shut off the uC doesn't lose power.

The whole USB power question is really a minor issue since it is so easy to cut a USB cable and splice the communication wires while leaving the 5V disconnected. It would take me about 15 -20 minutes to modify a cable. It's all the OTHER stuff that is trickier.

raschemmel:
The whole USB power question is really a minor issue since it is so easy to cut a USB cable and splice the communication wires while leaving the 5V disconnected. It would take me about 15 -20 minutes to modify a cable. It's all the OTHER stuff that is trickier.

I seemed to post #25 to chirping crickets, but it is not acceptable to just cut +5V out of the USB cable.

I posted links to the schematic and the AVR datasheet that show cutting +5V out of the cable results in a floating pin on the ATmega8U2 that can not be left floating as it's used for the state transitions in section 9.1 of the USB spec.

It seems in the OP's test with cutting +5V out of the cable, UVCC floated high resulting in an initial enumeration and then issues with re-enumeration. I wouldn't be surprised if it didn't work with all host controllers, however, or if it was inconsistent from AVR to AVR.

In general...never leave pins floating that the microprocessor datasheet says must be tied to something!

The USB 5V is disconnected from the 5V pin if the Ext power in connector has more than 6 V connected.

raschemmel:
The USB 5V is disconnected from the 5V pin if the Ext power in connector has more than 6 V connected.

That's only one place where USBVCC is connected. Check out pin 31 of U3. It's connected there because it needs to be, even in a self-powered device.

Honestly, removing T1 seems like the best way to do what he wants to do but he can't modify the board for some reason.

Possibly he could handle this more elegantly without any board or cable modifications. A diagram would help determine if that's possible.

What if the USB connection was through the N.O. contacts of a 4PST relay controlled bt a GPIO ?

Nope. The bottom line is if USB +5V cycles the device needs to recognize it and reset its USB state.

Something funny I noticed, is Figure 20-5 in the ATmega8U2 datasheet is wrong. It includes a pin that the IC doesn't have!

It seems to be reused from the ATmega32U4, which does have separate VBUS and UVCC pins. The Leonardo schematic matches Figure 20-5 of the ATmega8U2 datasheet, while the Uno schematic doesn't :slight_smile:

post a link to that. It may not be relevant since the UNO uses the ATmega16U2-MUCR

The ATmega8U2 and ATmega16U2 have the same datasheet -> http://www.atmel.com/images/doc7799.pdf

Figure 20-5 shows a VBUS pin, but the Pin Descriptions in Figure 2.2 don't list a VBUS. It seems like the way the Arduino Uno has it hooked up is correct, however, given the description of the pin. Table 26.1 shows that UVCC is completely separate from VCC too.

Compare that to the ATmega32U4 datasheet (http://www.atmel.com/images/atmel-7766-8-bit-avr-atmega16u4-32u4_datasheet.pdf), as used on the Leonardo (http://www.arduino.cc/en/uploads/Main/arduino-leonardo-schematic_3b.pdf).

The ATmega32U4 actually does have a VBUS pin, and Table 29.1 shows that it's the one that's completely separate from VCC. That's why the Leonardo was actually able to match Figure 21-5 of the Atmega32U4 datasheet.

The only explanation I can think of is basically conjecture and that is that “VBUS” is the generic name for “UVCC”, meaning it is the system name, as opposed to the chip pin name.

The 32U4 has both, as shown in the datasheet figure. The 16U2 only has UVCC, and it's actually hooked up to the wrong place in its datasheet figure.

The Arduino boards have them hooked up correctly (although not if +5V USB is cut!).

I still don’t see why the USB relay idea wouldn’t work if it only disconnected the USB on SHUTDOWN.

Well, even though this poster's Arduino seems to communicating with pin 31 floating, I don't see that as a viable solution. Look at the block diagrams in Figure 2-1 and Figure 20-1 of the 16U2 datasheet. It's hard to understand how his Arduino is communicating at all with UVCC floating, as it needs to be totally separate from VCC. Maybe it's somehow getting power from D+/D-? I bet the USB signals don't look right on a scope, and I bet it wouldn't work with every computer.

The lesser problem, honestly, is that its state machine isn't properly reacting to USB +5V. That signal can't be prevented from getting to UVCC with a relay, however.

Reply#2

The intent is when I switch the power off to the device I'm building, it will shut down the entire system including the controller. Depending on the state things happen to be in at that point, having it try to continue on USB power is not what I want to do. On the other hand, I don't want to have to disconnect the USB before shutting it down. It sometimes takes a while to reestablish the serial monitor connection when I start back up for testing.

The lesser problem, honestly, is that its state machine isn't properly reacting to USB +5V. That signal can't be prevented from getting to UVCC with a relay, however.

I think we should take a closer look at this statement :

Depending on the state things happen to be in at that point, having it try to continue on USB power is not what I want to do

If the USB power is not connected because the software has not turned on the USB relay, would that not meet the OP's requirements ?