This document describes the conditions that serve as triggers for starting USB services in a Symbian platform phone.
USB services need to be started in response to certain conditions. For example, on a peripheral-only phone, USB services can be started in response to a cable-insertion event, or possibly in response to a user instruction (in other words a function call from the phone's user interface).
On an On-The-Go (OTG) phone, the starting conditions are more complicated. All the conditions are described below.
Intended Audience
This document is for Symbian licensees who are implementing USB services, including host and On-The-Go (OTG) services, on a Symbian device.
Required Background
For details of, and links to, the USB and OTG specifications on the USB Implementers Forum website, see The USB Manager library.
If the Symbian platformphone you are developing code for support USB host/OTG services, then you need a thorough understanding of the USB host/OTG specification.
On a USB peripheral-only phone (in other words, a phone that will not support OTG services), the application that you start USB services from needs to monitor for when a USB cable has been inserted. For information on how to monitor for this, see Monitoring the phone's USB hardware.
The phone can also use the USB Manager's VBus publish-and-subscribe key to monitor VBus. (For information about using this property key, see Monitoring whether VBus is powered.) When the VBus property key indicates that VBus is powered, this means that a remote USB host wants the phone to perform as its peripheral. Therefore, it is time to start USB services.
On a USB host/On-The-Go (OTG) phone, when your USB control application detects any of the conditions listed below, it must start USB services.
Note: Whatever condition you are responding to (in the USB control application) as a trigger for starting USB services, you must start USB services before you call either of the USB Manager functions that can result in the phone becoming a USB host. (These functions are: RUsb::BusRequest() or RUsb::BusRespondSrp(); see Controlling when the phone is the USB host.) The reason you must start USB services before calling these functions is that the phone must be ready to perform USB communication as soon as it becomes host.
If the Symbian platformphone you are configuring is:
A local application has made a session request to USB Manager
This condition means that a local application has called the USB Manager's RUsb::RequestSession() function because it needs the Symbian platformphone to become the USB host in relation to a remote B-device (see Making requests from a local application for the phone to become USB host).
The USB control application learns of a session request made by a local application when a pending RUsb::MessageNotification() call completes with a KUsbMessageRequestSession message (see Monitoring requests for the phone to become a USB host).
The control application must then start USB services, if they are not already running, by calling the RUsb::TryStart() function (see Starting USB services). It can then call the RUsb::BusRequest() function to attempt to make the phone become the USB host (see Controlling when the phone is the USB host).
The phone is an A-device and a remotely attached B-device has issued an SRP message
This condition means that a remotely attached B-device has initiated SRP signalling because it needs to make the A-device into its USB peripheral.
The USB control application learns that the USB Manager has received an SRP message when a pending RUsb::MessageNotification() call completes with a KUsbMessageSrpReceived message (see Monitoring requests for the phone to become a USB host).
The control application must then start USB services, if they are not already running, by calling the RUsb::TryStart() function (see Starting USB services). It can then call the RUsb::BusRespondSrp() function. For information about the possible outcomes of calling this function, see Controlling when the phone is the USB host.
ID-pin is present
This condition means that the Symbian platformphone is an A-device and that the A end of a USB cable has been attached to it.
The USB control application learns when ID-pin is present by monitoring the USB Manager's ID-pin publish-and-subscribe key (see Monitoring whether ID-pin is present).
When ID-pin is present, the control application must start USB services, if they are not already running, by calling the RUsb::TryStart() function (see Starting USB services). It can then call the RUsb::BusRequest() function to attempt to make the phone become the USB host (see Controlling when the phone is the USB host).
The phone is a B-device and VBus is powered
This condition means that the Symbian platformphone is a B-device that is attached to a remote USB host (the remote A-device is the USB host and is powering VBus).
The USB control application learns when VBus is powered by monitoring the USB Manager's VBus publish-and-subscribe key (see Monitoring whether VBus is powered). It learns whether the phone is an A- or B- device by monitoring the OTG state publish-and-subscribe key (see Monitoring the phone's USB host/OTG state).
In this condition, the control application must start USB services, if they are not already running, by calling the RUsb::TryStart() function (see Starting USB services). The USB peripheral stack will load automatically. This is very similar to the case described above (see USB peripheral-only phones) where the phone is only capable of performing as a USB peripheral and can use the detection of a cable-insertion event as a trigger for starting USB services.