Extra byte received from host that causes stall

[berke-bakar]

Hi @hathach thank you for this awesome stack. I work for a semiconductor company and I am trying to add tinyusb support to one of our evkit. We came across a weird thing and we could not understand why this happened. I attached both STM32F407DISCOVERY board and our board's logs to compare. Notice that our board stalls the request C8 A1 21 00 00 00 00 07 as it is meaningless. But the thing is that should be a GET_LINE_CODING request. There is an extra C8 byte in front of it and since we only get 8 bytes for setup packets the last 00 byte is not seen there. We could not find a reason why there is an extra C8 byte. This problem also occured in SET_LINE_CODING request before the last GET_LINE_CODING request. But in that case it was a mistake by my side and I mistakenly set our state to idle so the data part of the SET_LINE_CODING recognized as a setup packet. So when we read 8 bytes it looked like this 00 C2 01 00 00 00 08 C8. So it appears that after the data part of set line coding and before the last get line coding request there is an extra C8 byte that is received. Have you ever encountered something like this? Do you have any suggestions or checks I should do to see where is that C8 byte comes from. Currently I do not have any USB analyzer but ordered one.

PS. In the logs you might have noticed the tinyUSB stack sends a request that is larger than 64 bytes even though our endpoints max size is 64. This is because we had to tweak data_stage_xact to send us all of the buffer. Otherwise the DATAEND bit was set early on and hardware considered the transfer is over.

board_log.txt
stm32f407disco_log.txt

[hathach]

Thanks for your kind words, would you mind providing more information for reproducing purpose

1. What is your mcu, board
2. Which example you are testing, if it is modified, please provide link to your fork
3. What are the steps you doing to cause the issue

[berke-bakar]

1. This is a board that includes MAX32666 and currently it is not available to customers.
2. I am trying the webusb_serial example, I did not modified the example but as I mentioned in the post, I had to modify the data_stage_xact in order to receive the whole data in just one request. Otherwise we set the DATAEND bit early.
3. I just flash the board with the example and I can see in the logs that an extra byte (C8) is received.

[hathach]

Unfortunately, I am not familiar with your mcu and/or not able to have any test with it. So I couldn’t tell what is the issue. However, all data is from the host, if there is extra byte, that is probably the issue with off-by-one in the buffer management.

TinyUSB can queue an transfer larger than 64 yes, but it is aysnc API and its buffer is guaranteed to last until transfer is complete. DCD should take note of the buffer pointer and auto-increase update transaction until all bytes are transferred and then notice stack with xfer complete event. There is lots of other mcu doing this e.g nrf5x