Transfer Complete Interrupt is not generated

[selvaoscura]

Hello everybody,

I'm sending a simple 1 byte report (2 bytes with the Report ID) to my HID device that defines a Custom Usage.
My HID client on Windows uses a standard Win function 'WriteFile' to send reports to the HID device (my board). Windows says the report is sent OK (2 bytes written). I also can see (using debugger) the board receiving the packet. However the XFER complete interrupt is never generated, so my board shows no action (LED is off).
To add to my frustration, I had a success with the transaction at some point, but then without apparent reason the board stopped generating the XFER complete.
To summarize:
The board is enumerated OK
The report is sent and Success is returned by OS (Windows
The Device receives the transaction and copies a packet from system FIFO buffer into Endpoint buffer.
The XFER complete interrupt is Not generated i.e. MCU doesn't detect a Transfer complete pattern.

I'm using stm32f4Discovery board with modified firmware. My Windows HID client is a modified WDK sample 'hclient' (C code).

Any advice is greatly appreciated.

[Jan Axelson]

What is the "Transfer complete pattern" that triggers the interrupt?

[selvaoscura]

According to

RM0090 Reference manual for STM32F40x, STM32F41x, STM32F42x, STM32F43x advanced ARM-based 32-bit MCUs

==================
The OUT data transfer completed pattern for an OUT endpoint is written to the receive FIFO on one of the following conditions:
– The transfer size is 0 and the packet count is 0 (that's because the count gets decremented on each packet read - My Note)
– The last OUT data packet written to the receive FIFO is a short packet (0 ≤ packet size < maximum packet size)
==================

The problem is I cannot say exactly what's the content of the packets. I'm using OpenOCD debugger coupled with Zylin embedded GDB plugin on Eclipse. The Debug GUI in Eclipse doesn't give a very readable info (in my opinion). It's difficult to figure out the content of the registers for example, or what exactly is the system buffer content. I probably need to try the command line

[Barry Twycross]

Could you be having data toggle issues. The symptom of a data toggle issue is the data being successfully transferred on the bus, then being ignored. The behaviour is actually correct, the receiver and sender are differing on what data toggle to send. Which sounds like what you have.

[selvaoscura]

My task at this point is to just ensure the USB connection works. The firmware reacts only to USB transfer per se, i.e. doesn't matter the report data (it is completely ignored). As long as the transfer is completed the application toggles a LED. So, I cannot see how Host and the device could possibly disagree here. Besides, as I mentioned before, the transfer is indeed 'incomplete', which is unambiguously seen using the debugger. The system signals the received packet and allows the application to read it, but never signals the completed transfer (although just one data packet of 8 bits has been sent to OUT Endpoint).

Anyways, I appreciate every advice given. I realize it's difficult to help here without physical access the whole setup.

[Tsuneo]

selvaoscura:
I'm using stm32f4Discovery board with modified firmware.

Which firmware did you modify?
STM32_USB-Host-Device_Lib_V2.1.0 (STSW-STM32046)?
- \Project\USB_Device_Examples\HID?

And how did you modify it?
- Added an interrupt OUT EP, rewrote the report descriptor?

Because of Synopsis' "efficient" USB hardware design on STM32, and ST's rambling document, firmware programmers get hard time. To receive just single-packet transfer, we have to deal with twice RXFLVL interrupts (Data OUT packet pattern, Data transfer completed pattern), and XFER (XFRC) interrupt (endpoint transfer complete).

Tsuneo

[selvaoscura]

I modified the Demonstration firmware coming with stm32f4discovery board ( STM32F4-Discovery_FW_V1.1.0\Project\Demonstration ).
The main modification is to "STM32F4-Discovery_FW_V1.1.0\Project\Demonstration\usbd_desc.c" for the Configuration descriptor (OUT endpoint added), and the Report descriptor (I replaced the original Mouse function with Custom function/usage for both IN/OUT).

Please, see attached 2 files:
1. usbd_desc.c (main points: 'USBD_HID_CfgDesc', 'hid_report_desc', 'USBD_HID_cb')
2. usblyzer_props_view.txt ( usblyzer's view of the descriptors)

Seems I cannot upload the attachments. Getting error:
"The attachments upload directory is not writable. Your attachment or avatar cannot be saved. "

Is there an email I can use to send them directly until I figure out how to post my files online for easy viewing?

[selvaoscura]

In my case

Always happens:
OTG_FS_GINTSTS.RXFLVL      USB_OTG_GINTSTS_TypeDef.rxstsqlvl      RxFIFO non-empty i.e. indicates that there is at least one packet pending to be read from the RxFIFO.

Never happens (Transfer complete):
OTG_FS_GINTSTS.OEPINT      USB_OTG_GINTSTS_TypeDef.outepintr      Indicates an interrupt pending on one of the OUT endpoints of the core (in device mode).

[Tsuneo]

Umm,
The USB device stack in STM32F4-Discovery_FW_V1.1.0 is unstable.
I tested Demonstration example on my F4-Discovery board.
Just with a little change on the descriptor ( reset boot protocol, add an OUT endpoint ), the device engine drops into forced Suspend-Reset, around 10 seconds after the first bus reset. I have an impression that the stack expects SetFeature( REMOTE_WAKEUP ) to initialize its Suspend logic.

I recommend you to move to STM32_USB-Host-Device_Lib_V2.1.0 (STSW-STM32046)
http://www.st.com/web/en/catalog/tools/PF257882

In this version, many bugs in the USB stack (USB-Host-Device_Lib_V2.0.0) of STM32F4-Discovery_FW_V1.1.0 have been fixed, including above Suspend logic.
(though still minor bugs are there, like
https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=%2fpublic%2fSTe2ecommunities%2fmcu%2fLists%2fcortex%5fmx%5fstm32%2fFlooded%20empty%20FIFO%20interrupts%20still%20make%20USB%20devices%20crawl
)

Tsuneo

[selvaoscura]

Tsuneo, Thank you very much for the information. I'll try your recommendation and let know the results.

[Tsuneo]

To port STM32_USB-Host-Device_Lib_V2.1.0 examples into F4-Discovery board,

1) Start with STM324xG-EVAL option

2) Crystal frequency (25 MHz --> 8 MHz)

Code: [Select]

system_stm32f4xx.c

#ifdef USE_F4DISCOVERY
  #define PLL_M      8
#else
  #define PLL_M      25
#endif

3) LEDs and switch
Copy these files into your project folder

\STM32F4-Discovery_FW_V1.1.0\Utilities\STM32F4-Discovery\
- stm32f4_discovery.c
- stm32f4_discovery.h

LED1 - LED4 (STM324xG-EVAL) --> LED3 - LED6 (F4-Discovery)

etc.

Tsuneo

[selvaoscura]

So far I tried simply building my project using libraries from STM32_USB-Host-Device_Lib_V2.1.0. Now it seems the packet is not reaching the board (OTG_FS_GINTSTS.RXFLVL not happening). Probably I'm missing some configurations.

I'll try to port the whole example as Tsuneo suggested.

[selvaoscura]

Oh, that was long ago.
Just to round this one up. The reason was incorrect configuration used for the OUT transfer. The solution was eventually found in the 'RM0090 Reference manual' for 'stm32f4xx ARM-based 32 bit CPUs' on pages 1136 and 1139.

Prior receiving the data OTG_FS_DOEPTSIZ.XFRSIZ and PKTCNT have to be set by the application. This wasn't done in my case. Discovery examples only cover IN transactions, so the details of OUT setup are left to developer.

If XFRSIZ is not initialized, the transfer size on EP is set (by MCU Core) to a strange value '524224' (should be '64' normally). Because of the huge value of Transfer size, the 'Transfer complete' is never generated. On each subsequent packet sent from the HID Client the number '524224' gets decremented, but it would take 8191 of 64 bit packets to bring it to 0 and generate the 'Transfer complete'.

To solve the problem use function 'DCD_EP_PrepareRx', which sets XFRSIZ and PKTCNT. After that the 'XFRC interrupt' happens as expected... and developer moves to a next problem, which is a subject of another appeal for help:-)

[mangodan]

This sounds very similar to a problem I am having, but with some differences. This issue exists with essentially the same application but altered slightly to cope with 2 different targets:

STM32F105
STM32F407

First off, the application works as expected provided the host port is a USB2 controller. If I try to use an USB3 host on the same PC, the following problem occurs.

The Bulk out interrupt occurs exactly once. i.e. the first bulk write works and the application handles the data. All further write cause nothing to happen. The sending / driver end is happy that the data was sent, and wireshark shows that the writes are acknowledged by the device.

Control writes continue to work as expected.

All bulk IN transfers work as expected.

Any ideas what might lead to this behaviour, remembering that if the host end is USB2 it all works. But that the problem appears to be in the device end.

[Jan Axelson]

After receiving bulk OUT data, be sure the endpoint is armed to receive new data.

A protocol analyzer will show if the host is attempting to send data and if the endpoint is NAKing the attempts.