USB检测与连接过程

过程"/>

USB检测与连接过程

1、插入检测

流程图标注说明：

      （1）驱动端每间隔50ms读取一次DM的电平，DM在读取之前会内部上拉，电平有0-->1,读取完后，会关闭上拉,DM电平为0；在设备没有插入主机时，会读取到高电平；在

设备插入主机时，DM会被主机的下拉电阻拉低，驱动端的上拉就不会拉高DM，DM电平为0，会读取到低电平，此参数TCFG_OTG_SLAVE_ONLINE_CNT配置读取次数；

    （2）在检测到DM为低时，设备USB状态为PRE_SLAVE_MODE，如果在2.5S内没有收到SOF包，则进入CHARGE_MODE（如，充电适配器），

如果收到了SOF包，则进入从机模式。此参数设置这么长，是因为有些电脑，比如MAC电脑，自协商的时间比较长，防止进不了从机模式，此参数

有接口，可配置。

    （3）USB在PRE_SLAVE_MODE状态时，USB进行初始化，协商，配置阶段，不会发送sof包。由于一些电脑的协商时间较长，比如MAC，所以SOF相关的状态判断，要注

意时间设置，否则造成识别异常；

2、拔出检测

流程图标志说明：

     （1）在USB处于从机状态时，3ms内未收到SOF包，触发SUSPEND事件，会开启一个定时器，如果在2S内未收到SOF包，则判断为USB拔出，

挂起OTG，发送device out 事件，此处理主要是解决一些HUB的兼容性问题。设备接HUB，HUB插入PC，在HUB拔出时，DM仍为低电平，检测不

到USB拔出；

      （2）在USB处于从机状态时，会有一个定时器，50ms执行一次，DM的电平和SOF包的读取，都是这个定时器，如果连续三次读取到DM为高

电平，并且没有收到SOF包，则判断为USB拔出。此参数TCFG_OTG_SLAVE_OFFLINE_CNT配置读取次数；

      （3）只要主机设备检测到DM,DP的电平异常，认为有断连，就会发送reset信号到从机；

3、标准USB连接检测流程

 

4、USB知识点

USB状态：

enum {

    IDLE_MODE = 0, ///<空闲模式

    DISCONN_MODE = 1, ///<断连模式

    HOST_MODE = 2, ///<主机模式

    PRE_SLAVE_MODE, ///<成为从机模式前的一个中间模式

    SLAVE_MODE_WAIT_CONFIRMATION, ///<从机模式还需等待再次确认

    SLAVE_MODE, ///<从机模式

    CHARGE_MODE, ///<充电模式

    OTG_USER_MODE, ///<用户模式，暂时未具体定义

};

        1、离在线检测

        online是读DM电平的次数，累计够了，1 -> 3，然后，等sof，有收到1次sof就会3->5，推设备上线消息到应用层；

        offline是读DM与sof的次数，就是DM是高电平，且sof num == last sof num，就会累计，累计满了，就推设备离线消息出去；累计还不够，有其中一个条件不满足，就把计数值清零。

        2、在3ms内，没有收到SOF包，则判断为suspend，就会推送suspend中断消息。连续检测到3次DM为低电平以及连续检测到3次没有SOF包（次数和定时器周期自定义），判断为断开；只是没有收到SOF包，则判断为SUSPEND状态；

        3、USB初始化、协商与配置过程

        （1）、USB的SOF包是在整个连接过程都会一直发吗？1ms一次？如果USB在传输数据，SOF包是和数据一起组包发下来吗？

        （2）、DM的电平和SOF包读取的定时器时一直在跑的吗？

         答：（1）按照正常的来说，主机在usb reset释放后就会持续发，1ms一次。目前我知道的会停的情况：

        A、开了remote wakeup，主机会在音频流停的时候过一会suspend，sof会停，播歌/录音开始前resume;

        B、电脑休眠的时候，会suepnd，sof会停；

        答：（2） otg状态机是SLAVE_MODE的时候，dm和sof包就一直跑，直到状态机切到其他状态；

        sof包和数据包是一起的，先sof包，然后后面跟着各种数据包。

        USB进入PRE_SLAVE_MODE，会打开usb的硬件，然后是协商，不过full-speed对协商其实是不回应的，后面就是主机发reset，然后是sof。

下面是协商的过程：

high-speed协商：

1）主机读到DP上出现高电平（设备的1.5k上拉）；

2）主机发reset，后面的都属于reset过程中发生的协商；

3）从设备通过电流源输出，在信号线上呈现一个800mV的电压，即k信号（DP 0, DM 1）；

4）主机看到信号线上出现k信号，就会开始连续发KJKJKJKJKJ....，电平是800mV；

5）从设备看到信号线上出现KJ，会在第3对KJ（即KJKJKJ）后挂上差分驱动器，信号线上电平变成400mV；

6）主机看到差分信号电平变化，就认为是high-speed从设备；

7）释放reset，开始数据交互；

full-speed协商：

1）主机读到DP上出现高电平（设备的1.5k上拉）；

2）主机发reset，后面的都属于reset过程中发生的协商；

3）从设备由于不是high-speed，没有电流源驱动DM；

4）主机在reset期间没读到DM上800mV电平，直至超时释放reset，认为是full-speed；

        这边3->5，会有一个打开usb硬件，接收sof，然后状态切到5，会关usb硬件，然后推消息，应用层收到消息之后会usb_start()。

       4、打印“g_write_ot"，设备给主机发送数据发送超时了。usb都是主机请求，从机回复这样的。设备发送超时，可能是主机没有发请求拿数据；接触不良也会，情况是类似的。

        5、设备端驱动层是怎么区分是USB播放音乐还是USB进入通话啊？驱动层会发对应的mic open和audio open事件上来。

单个usb audio(audio + mic)没有区分播歌还是通话的，有录音（通话）就打开mic，有播放就打开audio。进入录音，PC端会有指令下发；

1. 以下参数含义

    static const u8 uac_mic_feature_desc[] = {

    7 + (MIC_CHANNEL + 1) * 1,     //Length

    USB_DT_CS_INTERFACE,      //DescriptorType:audio interface descriptor

    UAC_FEATURE_UNIT,       //DescriptorSubType:Audio Feature Unit

    MIC_FEATURE_UNIT_ID,       //UnitID

    MIC_INPUT_TERMINAL_ID,      //SourceID: #Microphone

    0x01,      //ControlSize:1 byte

    0x43, 0x00,  //   bmaControls[0] (Mute,Volume,Automatic)

#if MIC_CHANNEL == 2

    0x00,

#endif

#if MIC_CHANNEL == 4

    0x02, 0x02, 0x02,

#endif

    0x00,       //Feature String

};

        ControlSize是下面bmaControls[n]的大小，1是1字节1个，2是2字节一个。下面0x43, 0x00是两项，bmaControls[0]，bmaControls[1]，单声道需要两项，双声道的时候需要三项。可以理解为bmaControls[0]是中央声道，bmaControls[0]是左声道，bmaControls[2]是右声道，后面的mute, volume是每一项的bit

        Automatic Gain这个bit是这个功能的使能开关，使能了，在麦克风设置界面那里会多一个选项卡，选项卡里面有一个复选框，勾上和不勾上，就会发命令下来，然后上面截图那里收命令，目前接收命令那里是空的，没有做实际的行为

.设成0的话，就看不到那个选项卡

1. 如果进入了PRE_SLAVE_MODE，是主机会主动发送SOF包，还是从机会发指令，请求主机发包啊？

        主机主动发sof的，USB是reset释放时候，立刻就会发sof的

   8、701的设备，USB通话在关闭和打开麦克风的时候，不会马上有USB_AUDIO_MIC_CLOSE/open指令下发下来，可能是秒级，设备端才会收到指令，这是什么逻辑啊？是USB标准逻辑还是你们的驱动层或者应用层逻辑啊？

        是兼容性考虑。不过应该close是有delay，open不会有delay。驱动层的开关事件是很快就会下发，应用层逻辑。有些安卓设备（Window听同事反馈，也有少部分电脑，在客户那边的，不在我们这边），刚连接USB的时候，在usb分析仪上能抓到安卓打开mic是close-open-close-open-close-open这样来回几次，中间有几次时间间隔是1~2ms的，这样不过滤直接推消息给audio / bt(dongle产品)，它们处理不过来这么短时间的反复打开，会出问题。现在代码里usb部分的逻辑是收到close命令的时候，设一个1s超时，超时了才真正推close消息给audio / bt，如果中间遇到open，close超时回调就会被打断不被执行。“close-open-close-open-close-open”-> audio / bt的消息就变成了只看到open。同理，有时候会出现主机不用mic，但是又短时间内open-close-open-close-open-close了，经过代码的逻辑过滤，就变成了只看到一个open - close。

还有一些情况，看见延时关闭，指的是usb spk，是windows上播放器行为，例如网易云，播歌暂停，它会发一段时间的全0数据下来，然后停了，但是不发close命令。这种的话，会导致audio拿不到数据但是又没关闭，就有问题，所以逻辑流程在audio_dec_pc.c里面，注册了一个定时器定时检查，如果没有数据了，会挂起解码器。

        9、如果USB通话，上行没有送数据，会有什么问题吗？通话会关闭吗？

        上行是我们自己给数据，没数据的话也会填0，给够这么多数据量，不会停。数据是主设备主动来要，从设备不会主动发送数据。

        10、PC的插入检测

        PC是检测DP或者DM有其中一个是高电平，认为有设备插入。如果要抓波形，逻辑分析仪连着PC那端，再接701看会看到是DP拉起来的。如果逻辑分析仪连着701那端，再接PC，看到的是DM间隔50ms拉高一下，但是接到PC它不是高的，701的DM的上拉电阻是180k（非标，DP的是1.5k标准），PC的下拉电阻是15k，两个连接上的时候，DM是低电平，PC察觉不到（默认下拉），只有701知道了DM被拉低了。这里是1---->3。后面3---->5，是开了usb，DM上拉关了，由usb IP把DP上拉打开，示波器上看到是DP是高电平，PC察觉到DP高电平。

        检测到USB插入->reset->自协商->枚举->reset信号->数据交互。