Author Topic: Transfer Complete Interrupt is not generated  (Read 33852 times)

selvaoscura

  • Member
  • ***
  • Posts: 12
Re: Transfer Complete Interrupt is not generated
« Reply #15 on: April 02, 2014, 10:00:51 am »
My transfer works fine by now but only ONCE.
I'm stuck with the 'bit toggle' problem that was mentioned by Barry Twycross a bit prematurely. Now it's upon me.

My OUT reports have 64 bytes and are sent in Single packet each. Windows WriteFile generates DATA0 on the first write. The device ACKs the packet and generates the Transfer Complete. The following packet is sent from Windows with DATA1. The device sends NAK on DATA1 and packet is endlessly resent. I cannot find how to tell Windows API that this is a New transfer and the packet has to be with DATA0. I have to reset the HID device.
BTW is my understanding correct that a New Transfer has to always start with Data0?

Jan Axelson

  • Administrator
  • Frequent Contributor
  • *****
  • Posts: 3033
    • Lakeview Research
Re: Transfer Complete Interrupt is not generated
« Reply #16 on: April 02, 2014, 11:11:33 am »
No. Except for control transfers, the data toggle resets only on Set Configuration, Set Interface, and Clear Feature(Endpoint Halt).

Also, a receiver that gets data with the wrong data toggle doesn't NAK. The receiver ACKS, but ignores, the new data.

After receiving bulk OUT data, be sure the endpoint is armed to receive (ACK) new data. See your controller's data sheet for information on how to do this.

Barry Twycross

  • Frequent Contributor
  • ****
  • Posts: 263
Re: Transfer Complete Interrupt is not generated
« Reply #17 on: April 02, 2014, 01:12:07 pm »
Definitely not a data toggle problem. A packet with a bad toggle is successfully transferred, that is its ACKed, then the host never tells the driver about it (it never generates a transfer complete interrupt) because the packet is discarded (correctly).

The data toggle toggles between DATA0 and DATA1, Jan mentioned the circumstances that cause the toggle to be reset, and a new transfer is not one of them. The new transfer should start with the next toggle, which is what you say its doing, so the host is being correct, its the device which is the problem.

The packets are being NAKed, which means they are not being received. The device is refusing them. The transfer complete interrupt never happens because the transfer has not completed. The data was not discarded, it was never received in the first place. A device will usually NAK because the endpoint has not been told to receive the data. It sounds like you successfully arm the endpoint for the first packet, then do not rearm it when you do get the transfer complete interrupt. The endpoint has to have been told that it can receive more data. It must have a buffer to put it in and there is usually an enable bit. So you arming goes something like:

1. Set buffer address
2. Set buffer length
3. Set control flags to enable endpoint.

You have do that for each transfer, which sound like each packet in your case.

selvaoscura

  • Member
  • ***
  • Posts: 12
Re: Transfer Complete Interrupt is not generated
« Reply #18 on: April 03, 2014, 09:30:44 pm »
The bug is fixed and the whole process is finally working!

My code had already everything in place. However there was one redundant function call that screwed up the setup right after EP was prepared for next transfer.
For interested I experiment on stm32f4 Discovery. The function that arms the EP for new transfer is 'usb_dcd.c:DCD_EP_PrepareRx'. Right after this function I had a call to 'usb_dcd.c:DCD_EP_Flush', which effectively destroyed just prepared setup. Simply commented it out.

If not the advice kindly provided on this forum I would probably chase a wrong path for uncertain time.

Thanks very much Ian and Barry!