完善资料让更多小伙伴认识你,还能领取20积分哦, 立即完善>
最近使用CH552遇到一个枚举失败的问题。大概过程如下:
枚举过程中,主机请求了一个设备不存在的描述符。 实际为:`80 06 00 06 00 00 0A 00`请求描述符`USB_DESCR_TYP_QUALIF` SETUP事务触发中断,大约22us以后,将EP0设置为STALL SETUP事务在设备ACK以后大约2us,主机又发起了一个IN事务,由于此时EP0还没有设置为STALL,设备应答NAK ISR中将EP0设置为STALL以后,主机再发起IN事务,设备应答STALL,然后主机重新请求设备描述符。过程如下图所示: 主机发起SETUP事务请求设备描述符,设备应答ACK并触发中断,在中断设置EP0之前,主机又发起来了一个IN事务,由于EP0还是STALL没有改变,设备应答STALL,枚举就失败了。 主要是主机的IN请求发送的太快,而MCU响应中断又太慢,有没有比较好的解决方法呢? 如果需要可以提供完整的逻辑分析仪抓包数据。 是这个问题,原作者给出了解决方案,但是感觉并不是太好。 |
|
相关推荐
2个回答
|
|
通常我会建议客户在进入USB中断前,不管进入原因是什么,先将用到的端点的状态都改成NAK,因为NAK肯定不是一种错误状态,改成NAK之后就有充足的时间来处理事务本身,再改成ACK或者STALL。
同样的这个问题也会存在于连续数据传输过程,如果不及时将ACK状态改回NAK,可能会发生意外的数据传输。 一般这样可以解决问题。 |
|
|
|
现在看来,似乎只能进SETUP的时候清除STALL来解决,如果USB的IP在STALL以后能发一个中断请求,在STALL的中断响应中处理会更优雅一些。这是我最终的处理方案:
case UIS_TOKEN_SETUP | 0: if((UEP0_CTRL & MASK_UEP_T_RES) == UEP_T_RES_STALL) { // STALL -> NAK // xxxxxx11 -> xxxxxx10 UEP0_CTRL--; } |
|
|
|
只有小组成员才能发言,加入小组>>
259 浏览 1 评论
CH579M+RT-Thread,RTC从Sleep模式唤醒失败是什么原因?
2737 浏览 2 评论
2250 浏览 1 评论
BLE-Dongle与CH9141-A核心板进行双向透传,无法接收到串口数据怎么解决?
486浏览 7评论
222浏览 4评论
主机NRF52832从机ch9141,ch9141断电后无法发送数据怎么解决?
404浏览 3评论
294浏览 3评论
278浏览 3评论
小黑屋| 手机版| Archiver| 电子发烧友 ( 湘ICP备2023018690号 )
GMT+8, 2024-8-17 09:08 , Processed in 0.854926 second(s), Total 50, Slave 44 queries .
Powered by 电子发烧友网
© 2015 www.ws-dc.com
关注我们的微信
下载发烧友APP
电子发烧友观察
版权所有 © 湖南华秋数字科技有限公司
电子发烧友 (电路图) 湘公网安备 43011202000918 号 电信与信息服务业务经营许可证:合字B2-20210191 工商网监 湘ICP备2023018690号