IN Transfer not completing

[TLegrain]

Hello,
I am using STM32F4xxx with USE_ULPI_PHY and DMA as a USB device.
I am trying to send a large packet (900+ bytes) with DC_EP_TX(). Using a TotalPhase analyzer shows that only the first 64 bytes are sent.
Furthermore when implementing an interrupt driven 'chuncking' function so that I only pass 64 bytes to DC_EP_TX() at a time; I transmits the first chunck, and call DC_EP_TX() but the second packet is not transmitted and my function is not called again. Sounds like an interrupt or flag is not getting reset but I don't know which or where.

This sounds similar to a previous post 'Transfer Complete Interrupt is not generated' (http://www.janaxelson.com/forum/index.php?topic=1194.0). But this is with an IN_EP.

Any hints are greatly appreciated. Thank you

[Barry Twycross]

All the same things apply to an IN endpoint as apply to an out endpoint. Usually they're structured pretty similar.

The first question though, is the host asking for the data. Are their Ins? Are they NAKed?

If the host is asking for data, then its probably you have not configured the endpoint to send the data. I don't know your chip, but I'd look for where you set length, address and which enable bits do you need to set. Then check the enable bits are set.

If your host is not asking for data, then you have a host issue. What speed is this device? What's the max packet size? If the packet sent was not a max packet sized packet, then the host may think its finished.

[Tsuneo]

TLegrain,
Are you working on ST’s STM32_USB-Host-Device_Lib_V2.1.0 ?

In this Device library, a couple of bugs and fixes have been pointed out on IN endpoint handling.
Sound like you are hit by one of them.

- Flooded "empty FIFO" interrupts still make USB devices crawl
https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flooded%20empty%20FIFO%20interrupts%20still%20make%20USB%20devices%20crawl

- Known bugs in the OTG / USB library v2.1.0
https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=https%3a%2f%2fmy%2est%2ecom%2fpublic%2fSTe2ecommunities%2fmcu%2fLists%2fcortex%5fmx%5fstm32%2fKnown%20bugs%20in%20the%20OTG%20%20USB%20library%20v2%2e1%2e0

Tsuneo

[TLegrain]

Barry and Tsuneo, Thank you for your responses.

Barry: Yes, the host is asking for data. The device stages the 900+ bytes but I'm only seeing 64 with the Beagle analyzer (the ep max packet size is 64 bytes). If my device was sending all the bytes I should be seeing it with the analyzer even if they are not accepted by the host, no? Or should the host be sending ACK with every 64 bytes it receives?

Tsuneo: Yes, I'm using 'ST’s STM32_USB-Host-Device_Lib_V2.1.0'. I've made the bug fixes but I am still having the same issue.
I'm using STM32F4xx, USB HS external PHY with DMA. When I set the EP max packet size to 1024, and use DCP_EP_TX() the Beagle shows 181 bytes transmitted, strange!.

Using the same host but with a different device (STM32F2xxx, USB FS) and different firmware, the whole 900+ byte packet is requested and transmitted and seen by the Beagle analyzer.

[Barry Twycross]

If the host is sending INs, then the problem is in the device. If the device is NAKing them, then the endpoint doesn't know its supposed to be sending them. Checking every status bit you can find is a good step forward. Have your firmware read them out of the register if possible to make sure some other bit of code is not doing something you're not expecting.

If you're seeing something else apart from IN-NAK, repeated then its a different problem.

[TLegrain]

"If you're seeing something else apart from IN-NAK, repeated then its a different problem."

Yes, I am seeing 64 bytes that are the beginning of the 900+ actual bytes that the device should be sending. The device should send 15+ packets of 64 bytes each. But I only see the first one with the Beagle analyzer.

[Barry Twycross]

The question is does the host continue to ask for data. That is does the host send more Ins?

You are being very unclear on this point and it makes a big difference. If the host sends one IN, which is successfully completed, then never sends another, that would be a host problem. That would be the host not asking for data.

If the host is sending more than one IN, what happens to the second one?

[TLegrain]

Perhaps I'm not understanding your question.

Using the same host,

in the working version:
there is one (1) OUT record with a data packet which contains a command to request 900+ bytes of data from the device
then
there is fifteen (17) IN records containing the data

In the non-working version:
there is one (1) OUT record with a data packet which contains a command to request 900+ bytes of data from the device
then
there is one (1) IN record containing the first 64 bytes of the requested  data.

[Barry Twycross]

And no more Ins?

Do you have NAKs turned on in your analyzer. In other words would you know if your device were NAKing.

[Barry Twycross]

You do seem to be misunderstanding the question because its basically what happens on the bus after that one 64 byte packet you've mentioned. What happens next, or what doesn't happen next, is the big clue. You have never unambiguously stated what happens next.

[TLegrain]

I don't have the analyzer output in front of me right now but yes I can see NAKs.
I recall that after the problem, the host repeatedly sends  one (1) OUT record with a data packet which contains a command to request 900+ bytes of data from the device.
My device doesn't respond.
Thanks for your help, Barry.

[TLegrain]

To answer Barry's question more clearly:

After the first 64 bytes of the 900+byte IN message (EP 5),
I get an ACK packet (EP 5) and then a bit more than 6000 SOF (essentially nothing for 770ms).

Then there is activity on other endpoints,
Strangely, there is also activity on another device number. All of which the Beagle analyzer marks as I (Invalid PID sequence)

And then the host, about 2 seconds after that ACK (EP5), resends the OUT message (EP 5) containing the command that requests the data.

The device's IN endpoint (EP 5) never comes back.

[Barry Twycross]

It sounds like you have a host issue.

Your host is asking for 64 bytes and getting them, then its not asking for any more, but you're expecting it to ask for more. So the question is why is the host not asking for data. You also say that the host successfully completes this transfer with a different device, which makes the situation more puzzling.

Do you know what the host driver is doing? That is, is it your driver, or someone else's?

Are you sure the host is expecting 900 bytes? If it were, I'd expect that to be made as one 900 byte transfer, in which case when it received a max packet sized packet, the host would then send more INs without event pausing.

So, is that 64 byte packet max packet sized? is this a full speed device? I asked that earlier but got no response, if it is not a full speed device, 64 bytes is not a valid max packet size (at least for bulk, I've been assuming bulk). Is the endpoint descriptor correct?

On the other hand, the host driver may request 64 bytes and then consider the matter. If it didn't like the 64 bytes you sent it, it may then not ask for more. You may be able to tell the difference between these with the working device. If there is a pause between the 64 byte being ACKed and the next IN which is more than micro-seconds, then this is probably what's happening. If the pause is some frames, its definitely what's happening.