stm32f105USBDEVICESOS!!

wzp9999

stm32f105USBDEVICESOS!! [复制链接]

description for my question:

- host OUT a data
- STM32 receive it
- then use USB_SIL_Write(...) to write data to TxFIFO
- finally,host execute IN command,the data can be read right.
- then STM32 USB will catch a IN interrupt.in this interrupt ISR,use
USB_SIL_Write(...) to write data to TxFIFO again
- in this condition,host can read data from device at any time correctly.

I am sure that host OUT command is OK.

if host uses OUT to send data several times, then host can not useIN command to read data from device(stm32 have no interruptresponse),but data from host received correctly.


any reply will be appreciated.

wujieflash

- host OUT a data?
data is the plural of datum...
所以还是说中文吧。

suaimei

                                 What is host? What is the driver in host? Who wrote it? Are you sure it is good?

梦想之家

- 主机OUT指令（自定义的一些数据）
- stm32接收到主机的‘特定’数据后，使用USB_SIL_Write(...)函数往TxFifo写数据
- 这时主机IN指令，可以正确的收到stm32的数据，然后stm32产生一个‘传输完成中断’，并使用USB_SIL_Write(...)函数再次往TxFifo写数据。
- 这样主机就可以在任意时刻IN指令(经测试没有问题，每次读取的数据都正确，速度在上位机每次读8k的时候可以达到700k)。

问题：当满足以上条件的时候，上位机连续OUT几次（中间不执行IN指令，stm32可以正确接收）后，再执行IN指令，stm32无中断产生。
为什么会出现这种情况？？

ryl_522

问题可能有多种，
1、可能是TxFifo溢出，很多FIFO在设计的时候对overflow和underflow的处理是要求软件参与的，因为IC对这两种错误的处理略微有点麻烦。
2、USB的ip可能出了问题，USB传输的时候依靠dTD来做控制，在你收到多个指令之后会向USB ip发出多个传输指令，这些指令中包含对USB传输启动的触发，而一旦产生了前一次传输未完成而第二次触发已经产生，USB ip的处理可能是丢弃，也可能是直接Reset掉前面的内容。为了避免这个问题，建议在每次传输之前查询USB core的busy状态，不busy了再传。
3、通用并且安全的做法就是，主机侧随时挂多个in的urb等待，什么时候device有数据了，这些urb马上返回给应用程序。这种主机侧发多个命令而不挂in urb的方法不符合软件操作流程和硬件原理。

stonenb

谢谢5L兄弟。
1.下位机一次只往TxFifo放64字节的数据，当IN指令完成后再放64字节，所以应该不会溢出的。
2.感觉像这种，下位机把数据放入到TxFifo中，但主机可以选择读取或者OUT指令，一旦主机选择OUT指令了，是不是就发生了你说的这种情况了？？
3.不太明白，意思是有3个线程来IN？？

mgp765321

不用三个啊，只需要你把多个urb挂到USBD上，保证永远是HOST在等待device传输，而不是device已经准备好数据来等待HOST取，意思就是device随时可以发数据并被取走。
如果HOST也是嵌入式的，没有USB协议栈，只需要保证在每次接收中断处理了之后立即把另外一块buffer挂上去并启动接收。

lizhonglei201

                                 按照LZ在6楼的描述，应该FIFO和USB ip都没问题，而是device这一侧在长时间数据发送不出去之后，软件混乱了。

whl0808

9L的建议我已经试了，还是出现我先前的问题。

xinzha
我如何解决这个软件混乱？“只需要你把多个urb挂到USBD上”，urb和usbd我不明白，什么意思？

xia_23

我不知道你HOST侧是用的什么系统，我只做过Nucleus和Linux的USB驱动，但是我想USB协议栈这儿都不差不多吧。
urb就是你传输数据的请求的数据结构，usbd或者是usb kernel是对主机侧USB controller的驱动和协议栈的封装，然后提供给上一层驱动一些接口供调用。
以linux举例来说，你只需要把urb结构填好，里面有回调函数，传输方向等等的属性，然后每次回调产生说明已经接收到了相应的包，这时候把另外一个usb用再submit就可以了。

jhxia0156

我现在是在xp系统下，usb驱动用的是CyAPI的。
现在是一个线程不停的IN指令，数据可以正确接收，但是当我点击按钮发送OUT指令的时候，下位机就没有中断响应了，我这种方法应该和你说的差不多吧。

fall1979

这个就不好说了，因为我从来没写过windows的程序。
你检查一下当你发送out指令之后，主机这一侧是否有in的请求挂上去。
如果有bus doctor或者usb explorer之类的usb总线监视器就抓一下，实在不行可以用一个软件抓包软件，好像叫bus hound看一下。

mayi_huan

                                 我觉得主机这边没有什么问题，问题应该还是下位机软件出现混乱了，但是不知道具体是哪。。。

wenf

问题：当满足以上条件的时候，上位机连续OUT几次（中间不执行IN指令，stm32可以正确接收）后，再执行IN指令，stm32无中断产生。
按照你的描述，上下可能都有问题。

apple2

这种情况我也试了。
问题：当满足以上条件的时候，上位机连续IN指令时（stm32可以正确接收），再执行OUT指令（执行1次），stm32也会无中断产生。

xboy3721

晕了，先查这个时候stm32是个什么状态吧，是活着还是挂死了。
如果是挂死可能是中断处理或者什么地方处理错了。
如果还活着的话就要看总线上是否真正把数据发送给了stm32，因为调试这种问题的时候首先一点是相信操作系统提供功能的强壮性以及可靠性，看是不是自己的应用被阻塞在什么地方而导致最终发送失败。
如果stm32活着，并且数据在总线上已经发送过去，并且格式正确，但是没有激起stm32的接收完成中断，那就先查查中断是不是被关了，如果打开的话，我就不知道了...

yejing2008

STM32活的好好的，就是不产生“传输完成中断”了，我在仔细看看吧。
主机这边的程序应该是没问题，不过我用bus hound只能看出正确传输的数据，比如DI，DO等。

yinwei2005

看DI/DO对，如果DI和DO数目一致，那么就是主机程序的问题。
如果是DO多于DI，检查stm32侧吧。

奋青

如果DI/DO成对出现，也就是主机一个OUT后（stm32接收到OUT指令后，往TxFifo写入数据）再一个IN指令，这样的程序是一点问题也没有的。
我现在要求的是主机OUT和IN不一定是成对出现的，随时都可以IN，随时也都可以OUT的。

liso

DI和DO是你看到在总线上的数据，如果数目相等，就是说明所有的DO，stm32都已经给回答。如果DO数目大于DI，说明stm32在接收到某些包之后没有回答。而在正常情况下，在总线上看到的一定是DI和DO一样，这里要注意一点，你发出的请求如果没有实际数据响应，总线上是什么都看不到的。
这种测试是要找到问题的产生在整个链路的哪个部分。