STM32F107的USBHOST问题---INtoken发不出去

yazi198166   2010-12-2 19:33 楼主
根据手册,usb host模式下,非周期传输请求队列空间为8个,当正确初始化OTG CORE,并发现USB设备有插入后,配置OTG_FS_HCCHARx寄存器和OTG_FS_HCTSIZx寄存器,然后将OTG_FS_HCCHARx寄存器bit31置1,即可将一个传输请求放入非周期传输请求队列空间。如果是IN传输,不需要写FIFO,即有IN token发送出去。
而我现在碰到的问题是:已经按照上述方法放入一个IN传输请求进入请求队列空间,但是IN token并没有发出。
可能有人会怀疑我的OTG CORE初始化是否OK,怀疑我究竟有没有成功配置OTG_FS_HCCHARx寄存器和OTG_FS_HCTSIZx寄存器,所以我还是简单表述一下我已经成功实现了哪些。目前,我已经正确的初始化OTG CORE,正确的发现USB设备插入,正确的进行USB总线复位,正确的启动SOF,正确的枚举了USB device,并正确的执行了若干SCSI(U盘)命令。问题就是在正确的执行了若干SCSI(U盘)命令后,一个IN transaction却出不去了!
通过断点捕获到这个故障发生时的寄存器情况如下:OTG_FS_HCCHARx寄存器和OTG_FS_HCTSIZx寄存器全部正确,OTG_FS_HCINTx寄存器为0x00000000(没有任何中断),OTG_FS_HNPTXSTS寄存器的NPTQXSAV部分为7,表明还有7个空间空余,已有一个transaction请求存在。且,RxFifo已经通过OTG_FS_GRSTCTL寄存器的RXFFLSH位清空。我非常困惑,在这样的情况下,为什么host就是不发送IN token出来??????

STM32的专家们,请帮忙看看,如果是深圳的朋友帮我解决了这个问题,在下愿意赠送大餐,当面酬谢!专车接送!

回复评论 (57)

我再把问题精简一下:

什么情况下,已写入transaction request queue的in request会被阻挡住发送不出去?
点赞  2010-12-3 09:18
我再把问题精简一下:

什么情况下,已写入transaction request queue的in request会被阻挡住发送不出去?
simple_head 发表于 2010-12-3 09:18



呵呵,开个玩笑,你具体说说这个出不去的IN和其他出去的IN有什么区别?或者是这个出不去的IN之前的一次通信是什么?和其他的通信有区别吗?
点赞  2010-12-3 10:06
每个IN之前都需要

/* re-activate the channel when more packets are expected */
        hcchar.b.chen = 1;
        hcchar.b.chdis = 0;
        USB_OTG_WRITE_REG32(&pdev->regs.HC_REGS[grxsts.b.chnum]->HCCHAR, hcchar.d32);

做了吗?
点赞  2010-12-3 10:09
HCCHAR寄存器Bit31已经设为1.

我目前已经成功实现enumerate, 如果HCCHAR的BIT31没有射,之前的任何一次IN都不会成功.
点赞  2010-12-3 10:51
                                 我在enumerate U盘成功后,执行100次class specific request: Bulk ONly Mass Storage Reset.这是一个控制传输. 前18次执行都正确(程序运行正确,示波器观察正确),但是第19次执行,则再setup阶段的transaction正确完成后,host不再发出IN token.
点赞  2010-12-3 10:57
hcchar.b.chen = 1

不是设为1就可以了,是每个IN TOKEN之前都要再写一次1,比如你要收128字节,但最大包长度为64字节,所以会有2个包。

在第一个IN TOKEN出去以后,会产生RX FIFO中断,在中断中不需要再次设置长度地址等寄存器,但需要再次使能通道,在再一次使能后,第二个IN TOKEN就会出去了。
点赞  2010-12-3 10:59
                                 我的做法根你说的是一致的. 而且,当我的IN出不去的时候(以及之前),全部都是小于64字节的传输. Anyway,我会按照你的提示,再检查下.
点赞  2010-12-3 11:05
                                 除了IN出不来,其实我还有一个In Trnasaction的问题: 当IN transaction成功完成后, OTG_FS_HCINTx寄存器中只有Ack标志为1,而XFRC传输结束位不置1. 而我做的OUT传输,每次都有XFRC位正确被置1.
点赞  2010-12-3 11:10
是所有的IN transaction都这样吗?

这不正常的,应该有XFRC置位的

你看看你设置的包长度吧
点赞  2010-12-3 11:20
                                 IN 的结束标志条件是: OTG_FS_HCTSIZx中的PKTCNT从N变为0. 根OTG_FS_HCTSIZx中的XFRSIZXFR没有关系把?
点赞  2010-12-3 11:24
                                 OTG_FS_HCTSIZx中的XFRSIZXFR再IN的时候应该设为N*MaxPacketSize, 这个我已经照做了. 再我的调试中,OTG_FS_HCTSIZx中的PKTCNT已经从N变为0,我由此判断IN传输结束. 可能这个地方的确有问题.
点赞  2010-12-3 11:27
是所有的IN transaction都这样吗?

--- 是的
点赞  2010-12-3 11:28
                                 顶一下,以后看
点赞  2010-12-3 18:46
                                 楼上的,你的USB HOST进展如何?
点赞  2010-12-6 14:54
                                 你把你初始化发IN TOKEN的代码发出来看看
点赞  2010-12-6 15:14
                                 已发给你
点赞  2010-12-6 16:20
LZ能不能把你的代码发给我看下,mochou99@sina.cn
点赞  2010-12-8 09:04
                                 我的代码还在调试中,还有问题. 代码在我之前发的一个问题帖子里面有
点赞  2010-12-8 10:06
                                 你的OTG_FS非周期性TX FIFO/请求队列状态寄存器(OTG_FS_GNPTXSTS)的寄存器,在usb复位之后是什么样子的,我的是0x070800A0 这个,当我想传setup数据的时候,显示的是TXERR:传输错误这个错误,你有没碰到这个问题?可否解答下 谢谢 呵呵
点赞  2010-12-8 10:34
123下一页
电子工程世界版权所有 京B2-20211791 京ICP备10001474号-1 京公网安备 11010802033920号
    写回复