3
\$\begingroup\$

I am new to USB and working on an USB-capable embedded device for a customer who has designed the hardware. The target is an STM32F4.

The use case is that this device A) When connected to a computer, should appear as a COM port. B) When connected to a peripheral device be able act as host to talk to it over a COM port. For example, the initial peripheral will provide a DB9 connection so there would probably be a USB to RS232 dongle between my embedded device and the peripheral. So, in this case our peripheral would be the dongle, I think. C) Longer-term goals would be to support other peripherals for example flash drives and user input devices.

Item A) above has already been implemented using ST's CDC class driver. I have lots of questions regarding how to approach this.

My understanding of the On The Go Supplement is that there are basically two ways to approach this- either as an embedded host or using OTG.

1) The spec seems to indicate that if using the embedded host model, one will have to support at least two USB connections, presumably going to multiple ports on the micro, one configured as a host connection, one configured as a peripheral connection. Is this correct?

2) The customer had planned to use OTG and hardwire the ID signal to ground (Host) at the micro with the plan being to switch roles (maybe via HNP, if both support OTG?) as needed. I don't believe this will work given that when connecting to a PC the PC will assume it is a host, correct?

3) I'm a little confused by the relationship between CDC(ACP) and VCP. It seems like VCP is a specific type of CDC but is not clear to me how it extends it. Given that the customer has already implemented A) above using the ST CDC driver, it seems odd to me that this works without VCP?

4) If I wanted to implement B) above (let's say using OTG) what is needed on my side given that the device already acts as a peripheral CDC? I.e. what is needed to act as a host of a CDC connection beyond what is already in the driver when acting as a peripheral?

\$\endgroup\$
0
\$\begingroup\$
  1. No you only need one USB connection. You change the operating mode of the USB peripheral between host and device mode. Only one of these can be enabled at the same time. STM32F4 supports both modes. If you use the OTG feature then the mode gets selected automatically.

  2. It won't work except in situations where you connect to another OTG device that supports HNP. Your PC is not an OTG device so it can't do this.

  3. Virtual Comm Port is just a windows driver that causes a certain configuration of CDC device (CDC is a USB spec class) to appear as a com port in windows. The underlying USB component is just the CDC protocol (well, a particular part of it, which I guess you could also think off as the VCP part).

  4. Being a host is really an entirely different thing. You need to enumerate devices, generate SOF packets etc. ST has examples for how to do this, but it's essentially an entirely new software stack.

\$\endgroup\$
  • \$\begingroup\$ Followup question for you. Regarding 1) your statement seems to conflict with this text from the OTG Supplement "Embedded Hosts: An Embedded Host (EH) product provides Targeted Host functionality over one or more Standard-A receptacles. Embedded Host products may also offer USB peripheral capability, delivered separately via one or more Type-B receptacles." Is this not stating that two ports are required? \$\endgroup\$ – sje Nov 14 '17 at 16:18
  • \$\begingroup\$ If you don't want to use OTG/USB-C then you can have two separate ports (a host and device). Your question mentioned OTG so I assumed you didn't want to have two physical ports. \$\endgroup\$ – Jon Nov 14 '17 at 16:24
  • \$\begingroup\$ Two ports is not preferable but it might be do-able. Could both external ports be routed to the same DM/DP at the micro and is there some way to know whether the host or device port is the one in use? \$\endgroup\$ – sje Nov 14 '17 at 17:02
  • \$\begingroup\$ @sje The ports couldn't be directly connected together, but with an analogue switch you could make something work. The micro can just cycle between ports once a second to see if there is anything connected to either one. I think some STM32F4 devices can route the DM/DP pins to different pins so you might be able to use this facility. \$\endgroup\$ – Jon Nov 14 '17 at 18:56
0
\$\begingroup\$

You need to have the correct hardware implementation if you/your customer wants to accomplish the dual-role functionality of a device based on STM32F4.

First, if your customer has designed the hardware, they should be able to answer all your questions. But at least "hardwire the ID signal" for OTG implementation is completely wrong: the ID pin is controlled by A-B cable if one wants a role switch. The role of OTG device is controlled by ID pin, which is externally supplied from a cable plug. This is the most common and most reasonable implementation of dual-role devices (formerly OTG, the wordings that don't make sense).

To do even the simplest OTG form, your device must have a special dual-role "AB" connector, which can accommodate both Type-uA and -uB plugs. A peripheral device should have Typa-uA plug (a squarish one), with ID pin grounded. The ID pin should be connected to a GPIO in your STM design, which should be sensed by firmware and activate USB host functionality. You should have some proprietary code for this, the STMicro likely provides it.

In case of OTG-Host functionality, your hardware must have a power switch that gets activated when it determines that ID=O on the port.

A normal cable between basic PC (Type-A receptacle) will have the other end of cable as uB type (the half-rounded one), which has the ID pin floating. Floating pin should be sensed by the same GPIO and activate your CDC software stack, making it a communication device for PC host.

If your PC host has an OTG port as well (a rare case), then the cable between two u-USB devices should be uA-uB type, and only this kind of cable should exist.

If your customer-designed hardware doesn't have the above functionality (ID pin sense, VBUS power switch), then it has to be re-designed.

\$\endgroup\$
  • \$\begingroup\$ Thanks. I think you have confirmed everything that I understood with regard to OTG. Ideally this would have been understood earlier but I believe the ID signal was designed the way that it was with the thinking that the roles could be reversed if needed. Of course, that creates a problem for a PC Type A -> the product uB. \$\endgroup\$ – sje Nov 14 '17 at 17:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.