Author Topic: USB VCOM host  (Read 7077 times)

ADB

  • Member
  • ***
  • Posts: 26
USB VCOM host
« on: October 02, 2019, 03:26:34 am »
Hello Jan,

I've successfully developped a USB VCOM slave program on my microcontroller and am able to communicate with it using a PC.

I would like to adapt this program so that I can communicate with a "USB-to-UART bridge controller" on another board, which I presume will be setup as a slave. What would I need to do to, to adapt my micrcontroller program to make it a USB VCOM host program? The ID pin is pulled high, so by default my microcontroller is the slave. My microcontroller has USB OTG.

Based on my reading, my host program will need to provide extra signalling packets (SOF, SETUP, IN/OUT packets) + schedule transfers.

I see that OTG has circuitry to provide HNP and SRP protocols. Can HNP work in my case with 2 slaves orginally? Or would it be better if my microcontroller was the host at the outset?

Do you have any code examples for any of the above?

Thanks in advance for your comments,

Regards,

Alan

Jan Axelson

  • Administrator
  • Frequent Contributor
  • *****
  • Posts: 3033
    • Lakeview Research
Re: USB VCOM host
« Reply #1 on: October 03, 2019, 09:41:12 am »
If both devices have available async. serial ports, the easiest solution is to cross-connect those.

Othewise, yes, one device will need to function as a USB host. A device with OTG hardware can negotiate to function as the host. You will also need firmware support for the VCOM function in the host.

Many chip providers offer example firmware for various functions.

ADB

  • Member
  • ***
  • Posts: 26
Re: USB VCOM host
« Reply #2 on: October 04, 2019, 05:34:30 am »
Hi Jan,

Thank you for getting back to me.

Looking through my microcontroller's user manual, I don't believe I can setup the USB as an async. serial port.

Does USB OTG work if both devices are slaves at the outset? My chip provider has an older USB library that the one that I'm currently using that has an example for a USB serial host (code is very different between the 2 libraries), but I don't think it is implementing OTG.

I'm thinking of changing the state of the ID pin to make my microcontroller the host, which will hopefully allow we to use the aforementionned USB serial host problem. If that works, I should be able to use my USB protocol analyser to log what happening. I could then write code to try and achieve the same thing with my chip vendor's more recent library code and then implement OTG, as my microcontroller allows needs to be able to communicate with a PC.

For testing purposes can a PC be the USB device slave?

Thanks again for your comments,

Regards,

Alan

ADB

  • Member
  • ***
  • Posts: 26
Re: USB VCOM host
« Reply #3 on: October 11, 2019, 02:55:29 am »
Hi Jan,

On an evaluation board of my microcontroller, I've pulled the ID pin low. My slave device for the time being is self powered. If I boot my host microcontroller first, followed by my slave board, an interrupt triggers on my host microcontroller indicating a state change, but my host remains in an unattached state.

Any suggestions?

Thanks again,

Alan

Jan Axelson

  • Administrator
  • Frequent Contributor
  • *****
  • Posts: 3033
    • Lakeview Research
Re: USB VCOM host
« Reply #4 on: October 12, 2019, 08:54:55 pm »
OTG requires at least one device that can function as a host. If the other device is device-function-only, the host device will be the "A" device and must take the host function.

USB ports on PCs, with series-A connectors, are always host functions.

For debugging, a hardware-based protocol analyzer can offer clues. Also refer to the data sheet for your device for device-specific information, plus any example code from the chip provider.

ADB

  • Member
  • ***
  • Posts: 26
Re: USB VCOM host
« Reply #5 on: October 14, 2019, 11:16:42 am »
Hi Jan,

Thank you for getting back to me.

The following website summarises the host ennumeration process: https://microchipdeveloper.com/usb:enumeration
I am still at step 1. As far as I'm aware the Vbus voltage is 5V on both the host and device. There is nothing appearing on my protocol analyser yet...

Regards,

Alan

Jan Axelson

  • Administrator
  • Frequent Contributor
  • *****
  • Posts: 3033
    • Lakeview Research
Re: USB VCOM host
« Reply #6 on: October 14, 2019, 11:52:32 am »
Consult the host device's data sheet to make sure the host device is configured as OTG.

ADB

  • Member
  • ***
  • Posts: 26
Re: USB VCOM host
« Reply #7 on: October 16, 2019, 11:39:14 am »
Hi Jan,

My microcontroller datasheet/manual doesn't provide much information...

In your "Mass storage" book, it says "The host provides power to all devices on power-up or attachment and works with the devices to conserve power when possible."

Does this mean that the host can't be "bus powered" and rely on the power from a "self powered" slave device?

Thanks again,

Alan

Jan Axelson

  • Administrator
  • Frequent Contributor
  • *****
  • Posts: 3033
    • Lakeview Research
Re: USB VCOM host
« Reply #8 on: October 16, 2019, 10:32:07 pm »
The host is the source of bus power.

ADB

  • Member
  • ***
  • Posts: 26
Re: USB VCOM host
« Reply #9 on: October 17, 2019, 02:46:05 am »
Thanks Jan.

Regards,

Alan

ADB

  • Member
  • ***
  • Posts: 26
Re: USB VCOM host
« Reply #10 on: October 22, 2019, 06:01:37 am »
Hi Jan,

I've been able to route the USB communication between my host and USB to UART bridge through a USB protocol analyser. In the analyser, I set the speed to "full speed" to match the USB to UART's capability. I got the attached log. Does this mean that the host is unable to reset the slave device?

Thanks in advance for your comments on this.

Regards,

Alan

Jan Axelson

  • Administrator
  • Frequent Contributor
  • *****
  • Posts: 3033
    • Lakeview Research
Re: USB VCOM host
« Reply #11 on: October 23, 2019, 03:53:47 pm »
Yes, the host is unable to get beyond Reset, often an indication of a low-level signaling issue.

ADB

  • Member
  • ***
  • Posts: 26
Re: USB VCOM host
« Reply #12 on: October 24, 2019, 04:28:54 am »
Thanks. Working with microcontroller manufacturer on this....

Alan