Mbuino as self powered device

I’m not an expert on this, but it appears that P0.3/ISP_COMMAND_USB_HIGH is not correctly implemented for the scenario where mbuino is self powered, but occasionally connected to USB. In this case, the LPC cannot correctly detect the USB connection. This signal should not be generated from +5V, but rather directly from VBUS_5V+.

Geoffrey

@ geoffreymbrown - I am uncertain as to what you mean by “self powered”, but for our design purpose, we have the pin High by +5V to ensure that the board is USB enumerated when the firmware is to be changed or updated.

PIO0_3/USB_VBUS (processor pin 9) has two functions.

This is from page 9, revision 2.3 of the LPC11U2x datasheet:

[quote]PIO0_3 — General purpose digital input/output pin. A
LOW level on this pin during reset starts the ISP
command handler. A HIGH level during reset starts
the USB device enumeration.

USB_VBUS — Monitors the presence of USB bus
power.[/quote]
That pin is required to be high if you want to enumerate USB. We are uncertain if the alternate USB_VBUS function was implemented in the base LPC11U2x firmware from mbed and subsequently has never been tested.

I understand why it’s pulled high – but you used the wrong voltage source. Imagine the following scenario:

I build a battery powered data logger. At some point (while powered up) I connect it to USB. The change – VBUS going high – will not be detected. Therefore the device will not attempt to connect to USB.

Rather than 5v, the pin should be connected to VBUS. The presence of a diode in your circuit then guarantees that pin will be pulled high only when the device is connected to USB.

Geoffrey

I see your point about the ISP. Not sure what the right answer is.

Geoffrey

I understand what you mean now. If you power the device by a battery, you do not need to worry about PIO0_3/USB_VBUS. That pin is only for when you need to actually load the program binary to the mBuino or probably use the debug libraries mbed provides. Once the program is on the chip, a regular battery will allow it to run as normal. You should be able to use all peripherals via a standard 3.0V coin cell battery.

Right, but I planned to use an external 5v source. Looks like I’ll have to use an external 3.3v regulator as well to ensure that pin only sees Vbus.

Geoffrey

The 5V pin on the header is for an external 5V power supply (it is not an output). That pin is connected to a diode to prevent feed back from the USB powered connector and vice versa. There would be no need for an external 3.3V regulator.

I think that geoffreymbrowns point is that P0.3 should be connected to the USB 5V before that diode instead of connecting to the combined USB/header 5V after it.

That way you could use an external 5V voltage source and still detect when a USB cable was connected / disconnected.

As the board stands in order to get that functionality you would have to remove R18 and connect a 1k resistor between P0.3/ISP_COMMAND_USB_HIGH and VBUS_5V+

Add this to the list of issues with that pin, the 100k pull down on that pin causes a 120uA increase in power down current consumption, that doesn’t sound a lot but it’s a 60 fold increase on the 2uA is should be.
Fortunately that one can be fixed in software.

2 Likes

:think:
How can you run all of the peripherals from a standard 3.0V coin cell battery?
According to the schematic the Piezo Buzzer is connected to the 5V line.

To which schematic are you referring? mBuino does not have a Piezo buzzer on it.

The RETRO version.

@ Experimenter - Why are you suggesting to run the RETRO from a coin cell battery? This topic is regarding the mBuino. The RETRO is not intended to be powered by a coin cell battery. It needs 5 volts to control the Piezo and the back light of the LCD as well as the regulator that gives the processor 3.3V.

I thought the pull down is required to protect the pin in accordance with the Application information from the datasheet.