Hi,
Is there someone on the list who has a USB trace of a working CDC implementation ? What I want to know is what happens after all descriptors are received by the host. The last descriptor I receive is a string descriptor saying "Ethernet data".
I'm busy implementing the USB device controller for the SAM9G45 and got quite far I think. It is recognised by the host as a cdc device but it doesn't work yet. I also see no errors so far, so according to the host it should be a working device I guess. I know that doesn't mean all that much , but it should mean that after it switched the IN and OUT endpoints that ep0 and ep3 are working well. I just guess ep1 and ep2 are not working correctly somehow.
I do notice when I call lsusb that it responds very slow and I do see on my USB analyzer that my device responds with NYET after it receives some OUT data.
What happens is that the host sends 90 bytes OUT data. The next thing is that my device sends is NYET. This first packet from the host contains the eth_addr (0a:fa:63:8b:e8:0a) if that means anything. Than my device sends 8 byte IN data over the status end point (ep3) : A1 00 01 00 01 00 00 00 Than the device sends 16 bytes over the status end point : A1 2A 00 00 01 00 08 00 00 00 64 19 00 00 64 19 Than the host send another 78 bytes of OUT data which also get responded by NYET (it also contains the eth_addr).
After this, I see the u-boot prompt.
The device sees that OUT data arrived, but nothing seems to happen with it. This is basically what I'm currently trying to find out.
I wonder where things get stuck in my communication. Since I see no real error appear and I even wonder if the driver on my host PC may be the issue. I tried a machine with an older kernel and the response is a little bit different but also doesn't work (and stops at the same point) so I guess that's not the issue.
I think I can clearly state that endpoint 0 and 3 are working correctly.
I have taken the atmel_usba_udc driver from linux, but I changed it to disable DMA. I'm not sure if that's a smart thing to do but I figured if DMA is disabled, the driver gets a whole lot simpler to implement and thus smaller. Regarding speed I think there's hardly any real need for high speed as well in u-boot but I may be wrong here. As far as I analyzed the Linux driver (I ported back from kernel 2.6.33) it seems to have been programmed with both DMA and non-DMA transfers in mind but I think non-DMA actually doesn't work at all because it contains no code to switch of DMA I think.
I can post analyzer results and some outputs from u-boot itself if anyone thinks it is helpful. I do however think that I' already helped with a working trace so that I know what should happen.
Anyway, if someone has a tip how to figure out this issue, please let me know.
Best regards, Marcel