Issue with STM32F1 project

[perigoso]

I'm having an issue that's proving difficult to debug. (not a bug report because I'm not sure it is a bug)

The issue in its essence is that the device fails to send some hid reports, in this project we have implemented a protocol through hid reports, the host sends a hid packet through the interrupt pipe, and the device responds appropriately, similar to the hid generic in out example, but the host times out waiting for the response, because apparently the device fails to send it.

What i tried:
implemented an example with the same protocol implementation, and everything works fine, but with essentially the same configuration on our project it fails.

I know there's not enough information here to identify the issue, but I'm a bit at a loss here so i don't even know what to provide.

For reference here is the example i made to test (that works) (BOARD=stm32f103bluepill)

and this is the code that doesn't work (also running on a stm32f103 bluepill) (might be hard to follow)

Important details:
The device enumerates fine, Tinyusb doesn't report any error on the log
The device can send some hid reports like HID mouse, just fails with the protocol reports
I have checked the clock registers and the are the same in both projects after initialization

I will attach built binaries for my project if someone wants to run them on a bluepill (swo enabled 6MHz on PB3, TUSB LOG 2)
out.zip

Testing the protocol is possible by running ratbagd on linux

I'm not asking for someone to debug the project for me, just providing the means.
I'm happy to provide anything that might help you help me.

[hathach]

@perigoso can you post the log=2 here (portion around the issue occurred) for analysis. Also you may want to check the return of tud_hid_report() to see if it queues transfer correctly. There maybe race condition between the hid_ready() check and when sending out report.

Another question is, did the exact code work on other MCU e.g stm32f4 ?

[perigoso]

I tested the example i made both on a stm32f103 and a efm32gg12, bith with success

I will capture the output and post it later today

[hathach]

Please test with other mature port such as stm32f4. Efm is still too early for reference

[perigoso]

Tusb Log, this is in response to a 8 byte request by the host, the data is the expected, the host di not receive a response.

   USBD Xfer Complete on EP 01 with 8 bytes
     HID xfer callback
	got report
   		queuing response
   			data:
   			0x2100016F70656E696E7075742D67697400000000000000000E000000D84E0020
     Queue EP 81 with 32 bytes ... OK
     Queue EP 01 with 32 bytes ... OK
   USBD Xfer Complete on EP 81 with 32 bytes
     HID xfer callback

This is a different request by the host, but the reply comes in a 8 byte report, the data is also the expected, this time the host received the response

   USBD Xfer Complete on EP 01 with 8 bytes
     HID xfer callback
	got report
   		queuing response
   			data:
   			0x2000000000010000
     Queue EP 81 with 8 bytes ... OK
     Queue EP 01 with 32 bytes ... OK
   USBD Xfer Complete on EP 81 with 8 bytes
     HID xfer callback

[hathach]

I don’t see any difference in the device log. Host already received the data, and decide it is not valid or else ( can be at OS level ). Try to switch to other OS to test, find some syslogs like dmesg, or better to find an (hard/soft) usb analyzer to observe the actual traffic on the bus.

[perigoso]

Right, that's what i thought, I remember dmesg outputting something unusual

Reran things and got this
usb 3-4.3: input irq status -75 received but its no much to go off of

The only thing i came across was -75 is EOVERFLOW ("Value too large for defined data type").
could it be related to the hid descriptor?

[perigoso]

I dumped the descriptor and it looks like what its supposed to

[perigoso]

@hathach do you have any suggestion as to what may cause this? The configuration is the same in both projects, the
only thing that comes to mind being different is the compilation/linking, but i tried to use the same flags as well. we also dont use the ST hal, but i dont see why that would cause anything like this

[hathach]

There is not enough information for me to know what happened. Here is my suggestion

1. Make sure the data you sent from device is received as it is on host by running on other mature port such stm32f4, and/or checked it with software/hardware analyzer
2. If the data is correct, check to see why host OS decide it is invalid packet. May have something related to report descriptor, try to change your OS to macos/windows/linux to see how those behave.

[perigoso]

After banging my head for a good while, i finally found the issue, I had the endpoint configured to 32 bytes, setting it to 64 fixed it, (im not using the macros from tusb, making them by hand).

That said, shouldn't it work? I was sending 32 byte reports (including ID) so it should've been fine no? @hathach

[hathach]

what is your report size in report descriptor, and have you tried with other OSes ? Whatever config you do, try to apply it with the hid_composite example to see if that works. There is not enough information to analyze the root cause.