Problem with the "net_lwip_webserver (RNDIS) example"

[Wini-Buh]

Hi

I'm tying to get the net_lwip_webserver (RNDIS) example working. Unfortunately there is problem with the notification end point (0x81). Everything I tried did not helped to solve the problem. It seems that the end point does not send the RNDIS "report data" (this is send here

tinyusb/lib/networking/rndis_reports.c

Line 81 in 4e2684f

netd_report(ndis_report, sizeof(ndis_report));

(at least I could not see any communication in the Wireshark on that end point).

At the moment I also work on the on porting the tinyUSB to the CCRX toolchain from Renesas (see #785 ... I will also do a draft PR this week with all my changes for a deeper discussion about an inclusion into the tinyUSB project)

I know it is difficult to ask for some support in this stage, but I don't have any idea how to solve the problem. In the attached debugging output of the tinyUSB, you see an assert is triggered.

Thank you very much for an answer.
tinyusb_rndis.log

[hathach]

@Wini-Buh thank you very much for your effort, the rndis is considered as advanced examples. Not all the existing ports actually run fine with it #289 . I have an list of running ports, though I am kept busy with other works to actually verify them all. Anyway, don't worry too much of about that particular example. The initial porting PR does not requires all example to run. Bugs are expected. I think you only need to get the msc_cdc and or hid_composite running, that would be just good enough. The rest can be addressed via follow up PRs.

[kkitayam]

Unfortunately, I only have a windows machine. I cannot confirm that the example will work correctly on a Linux machine.

[Wini-Buh]

I also did a quick test with an old Windows 7 and the assert is not triggered. The enumeration is done successfully and all communication over endpoint 81 is performed correctly.

The enumeration with a Linux host seems a bit different (at least what I see on the Wireshark captures). But I'm not the USB specialist (that maybe I should be ? ). Do you have any idea how to find the reason of the problem ? It must be something around endpoint 81, which is used for interrupt transfers.

[kkitayam]

Queue EP 81 with 8 bytes ... usbd_edpt_xfer 1249: assert failed

I think the assertion message indicates that the next transfer has requested by application layer, even though the previous transfer has not been completed. It may be a bug regarding exclusive control operations in dcd_usba.c. I had thought that disabling USB interrupts would be sufficient.

[kkitayam]

@Wini-Buh
Could you share the full log getting by Linux host? I would like to check transfers around the assertion message.

Interrupt IN transfers are invoked at L.307 and L.404. But, it seems that L.404 only runs, in my Windows 10 host's log. If Linux hosts execute both lines, I guess the point has something hints for the issue.

[hathach]

@Wini-Buh I also encouter the ASSERT with 0x81 endpoint, however, it seems to be "normal" since currently the net driver doesn't check the busy state of the notification endpoint and can send one while previous one doesn't received by host yet. This will be fixed later but in general it does affect the example as this also appear on other working MCUs as well.