Let’s code with STM32 NUCLEO. One of the first aspects that we can note is the presence of many contacts on card’s border, including the now famous female contacts connector compatible with the Arduino shield. Externally, however, two double strips of male contacts (one per side) are what STM calls “Morpho” pinout, used on other STM development boards.
$begingroup$I have a wireless-transmitter module connected to a Nucleo board. The sensor draws power (~200 mA) from the Nucleo board's 3.3V out pin.
Case A (successful): When I connect/power the Nucleo board with a standard USB (5V) cable connection to my PC, then:
- the transmitter module successfully transmits (I successfully receive packets on remote unit)
Case B (unsusccessful): But when I connect/power the Nucleo board with a USB cable to a Battery pack (one of those phone backup-battery packs with 5V output @ 1A), then:
- I get 1.1 V for the multimeter reading on the 3.3V out pin of the Nucleo board
- the transmitter module isn't transmitting (I'm not receiving packets on remote unit)
- the Nucleo board's LD1 (LED) just continuously blinks at 1 Hz
Question: Is there some physical re-configuration I have to do to allow the Nucleo to be USB-powered by a 5V-Usb-out battery pack, and to successfully draw power (about 250 mA in my case) from the board's 3.3V out pin?
Here is the schematic of the Nucleo board including its power circuitry:http://ds.arm.com/media/resources/db/platform/st/nucleo_f401re/MB1136.pdf
boardbite
boardbiteboardbite
$endgroup$2 Answers
$begingroup$A few options from simple to complex:
- JP1 is the usb power limit bypass jumper. When OFF, the ST/Link part of the board attempts to enumerate with high power request. If it successfully enumerates with the requested power, it enables the USB power Mosfet. When ON, it signals the ST/Link that External Power is being used, and should enable the power mosfet anyway. Simply putting this jumper on should do the trick.
- Cut a usb cable, and wire the V+ to the either the E5V pin (Make sure JP5 is set on pins 2-3, for external power.), or the 5V pin, depending on if you want the ST/Link side of the board to be on as well or not. If you don't need the Programmer and Debugging while on a usb battery pack, use the 5V pin. Otherwise it's a waste of power, as small as it may be. (Additionally, remove the JP5 jumper just to make sure)
- Solder the SB1 (USB Power Management Bypass). This is a normally open jumper trace. When soldered, it physically bypasses the USB Power Management mosfet, connecting USB 5V directly to the target board and 3.3V regulator.
PasserbyPasserby
$endgroup$$begingroup$[Note: User Passerby interpreted the datasheet differently than I did, and he is correct. My answer will work, but his is the better way to do this. My answer does have some good info, though!]
The quick answer is that you need to create a short across SB1 ('solder-blob 1'). As you can see by the name, they intend that you just drop some solder between the two contacts.
Here's why:
![F103rb F103rb](/uploads/1/2/6/2/126252330/620657002.jpg)
First, the rules of USB:
The USB specification dictates that a device (the Nucleo in this case) will only draw 100mA max when first connected to a host (the computer or power source). After connection, if the device determines that it is allowed to take more current, it can do so. Generally this higher current is 500mA (max) although there are further exceptions that allow more current.
The host device dictates to the device how much current it can draw. It is the responsibility of the device, not the host, to limit current consumption.
There are various methods for the device to know how much current it is allowed to draw. Here is a nice document by Maxim that describes the details. Here's my quick and incomplete summary:
- If the device is plugged into a computer, USB hub, etc, then there is an intelligent conversation that takes place between the device and host. This is called 'enumeration'. During the enumeration the device can let the host know that it wants more than 100mA. The host may then grant permission for the device to draw more.
- If the device is plugged into a non-intelligent port (wall wart, battery pack, etc) then enumeration can't take place. There are a few schemes where the device can determine that high-current is available. They are shown in that Maxim doc.
Second: How the Nucleo implements these rules:
However, the Nucleo board doesn't implement the second option. It simply won't power up the main microcontroller until an enumeration takes place. This is described in the user manual, section 5.3.1. There is a jumper (JP1) that you can use to enable the main microcontroller without enumeration. Unfortunately this jumper also limits the current draw to 100mA! You can't have high-current and non-enumeration at the same time. Here is a portion of that section:
There is a solution, however! Find T2 on the schematic. It's the MOSFET in the lower-left of the first page. SB1 is right next to it. If you short over SB1 then the main microcontroller will always be powered. It is now your responsibility to always plug into a 500-mA capable port :)
Note also that the doc says that 300mA is all that is possible. Perhaps they've used a voltage regulator that can't regulate the full 500mA, or maybe they're reserving the extra current overhead for the non-user-accessible features of the Nucleo... Either way, I wouldn't try to exceed it.
W5VO♦
bitsmackbitsmack
$endgroup$Not the answer you're looking for? Browse other questions tagged batteriesusbstm32nucleo or ask your own question.
I'm trying to implement UART over a USB interface on the STM324x9I-EVAL development board. The purpose is to send commands to a servo controller (or other hardware, for that matter) serially. I've successfully implemented the USB_Device_CDC example on the development board but am unsure exactly how this works without a PC with drivers on the other end. As far as other hardware is concerned, will the USB port now simply look like a serial port? Or is there still a need for a driver or some sort of interface on the other end?
![F103rb F103rb](/uploads/1/2/6/2/126252330/757226257.png)
I do want to point out that I'm aware of the following post:
but I don't believe my question is fully answered within the context of that answer.
Community♦
mbanmban
2 Answers
A USB connection is not a peer-to-peer connection like a UART. It requires a host and a device in a master/slave relationship. The device cannot initiate data transfer; it must be continuously polled by the by the host.
A CDC/ACM class device presents a virtual COM port on a PC host, but that does not allow the device to communicate with a UART interface. It looks like a serial port at the software level, but does not implement a UART physical layer. There is an awful lot going on under the hood to make it look like a PC serial port, but none of it resembles UART communications at the physical level.
There are devices that act as UART/USB bridges (from FTDI and Prolific for example), and you could (somewhat expensively) build your own from a microcontroller that has a USB device controller and a UART, but the bridge is a USB device and must still connect to a USB host; these are normally used to connect a PC to a microcontroller that lacks a USB controller or where the software/CPU overhead of using a USB controller is too great.
In theory you could connect a microcontroller that has a USB host controller to one that has a USB device controller, but you need host and device software stacks on each respectively, and once you have the USB connection, implementing CDC/ACM is a somewhat inefficient use of the available bandwidth. The purpose of the CDC/ACM class is primarily to allow 'legacy' software to work on a PC.
If you need to connect to a 'real' serial port, you should use a real UART - which are far more ubiquitous than USB controllers on microcontrollers in any case.
CliffordClifford
You should learn a little bit about USB device classes. CDC is a USB device class, and ACM is a subclass that I assume you are using. The device you made could be called a 'CDC ACM device' because it uses the CDC class and the ACM subclass.
These classes and subclasses are defined by the USB Implementers Forum in documents that you can find here:
These documents specify things like what USB descriptors a CDC ACM device should have in order to describe itself to the host, and what kinds of interfaces and endpoints it should have, and how serial data will be represented in terms of USB transactions and transfers.
Note that CDC ACM only specifies some USB commands for transferring data between the host and the device. It does not specify what the device will actually do with that data. You can use CDC ACM to implement a USB-to-serial adapter, or you can just use it as a general purpose communication interface for whatever data you want to send.
Yes, you do need a driver on the PC side. The driver needs to be designed to run on your specific operating system. It needs to create some kind of virtual serial port device in your operating system that other software (which only knows about serial ports) can find and connect to. It needs to translate serial port operations performed by other software on the serial port (e.g. writing some bytes to the serial port) into low-level USB commands according to the CDC ACM specifications (e.g. sending some bytes out to the device on a particular endpoint in the form of USB packets). It needs to somehow know which USB devices it should operate on, since not every USB device is a CDC ACM device.
For Windows, you will probably use the usbser.sys driver which comes with Windows. For versions of Windows older than Windows 10, you will need to write an INF file to associate your device to usbser.sys and sign it. For Windows 10 and later, there is a new INF file called usbser.inf already included with Windows which will automatically match any valid CDC ACM device. This means you don't have to write or distribute a driver for CDC ACM devices if you only intend to support using the device on Windows 10 or later. The partnership between Microsoft and Arduino which began in 2015 gives me hope that Microsoft will continue supporting and improving usbser.sys in the future. In fact, they claim that in Windows 10 'the driver has been rewritten by using the Kernel-Mode Driver Framework that improves the overall stability of the driver', so that is good news.
For Linux, there is the cdc_acm kernel module, which has been a standard part of the kernel for a long time and should work automatically with any CDC ACM device you plug in.
For Mac OS X, there is the AppleUSBCDCACM driver, which should work automatically with any CDC ACM device you plug in.
Note that for any of these drivers to recognize your device and work with it, your device has to have certain values in its USB descriptors, and the requirements can vary depending on what exact driver version you are talking about.
Will the USB port now simply look like a serial port?
No, that's the wrong way to think about it. The USB port will still look like a USB port, but the various USB drivers provided by your operating system will recognize that a CDC ACM device is plugged into that port and create a new entry in your operating system's list of serial ports. Then if you run some software that only knows about serial ports, it can connect to that port.
In fact, if you make a composite device, you can have a single USB device plugged into a single USB port that actually has two or more virtual serial ports.
David GraysonDavid Grayson