This is week six of my internship at Aeste Works. After configuring the company’s board to enumerate successfully on a Windows environment, it was time to configure it on Linux. On Windows, the usb drivers loads according to the Vendor ID and Product ID which was for Microchip’s USB CDC Abstract Control Model demo. USB CDC Ethernet Control Model is widely used for interoperability with non-Microsoft operating systems, but does not work with Windows and this meant that even with the configurations made for USB CDC Ethernet Control Model, the host would still see the board as a COM port as per the original Abstract Control Model demo. A Microsoft proprietary protocol called Remote Network Driver Interface Specification (RNDIS) would have to be implemented to provide a virtual Ethernet link on top of USB for Windows but that is not my focus for now.
In the source code, I set one of the LED’s on the board as a debug LED to check whether the board has been successfully enumerated with the host and this was shown & observed on Windows. However the LED kept on toggling after connecting the board to the Linux machine meaning something was not right during the enumeration process. Observing the USB packets over Wireshark, it was seen that the standard USB descriptors were repeatedly requested and set by the host but never actually configuring the board as a USB CDC ECM device. Looking carefully at the source code, there were two issues causing this stalling behaviour.
The first issue was that the Linux machine was not supporting the USB high speed that was originally configured and had set the board for USB full speed. In the source code, any other speed configuration would lead to a stall response and so I had to change it accordingly along with the correct endpoint buffer size to be 64 bytes for full speed from the 512 bytes for high speed as per the USB documentation . The second issue was that there was a USB CDC Ethernet Control Model sub class specific request from the host that was not handled in the source code. Note that the Ethernet Control Model sub class is not supported by Windows and this is why this specific sub class request was observed on Linux only. The original USB CDC Abstract Control Model demo would direct any other sub class specific requests other than its own to a stall response. This specific required request is called Set Ethernet Packet Filter and is used to configure device Ethernet packet filter settings. The first step I did to handle this request was to look through how the source code handles specific sub class requests for Abstract Control Model. Fortunately, there was one that I could examine called the Set Control Line State request that generates RS-232/V.24 style control signals. After, coding all the necessary event and application handler functions as well as the Ethernet Packet Filter Bitmap structure as per the USB CDC documentation, it was time to see whether the board would be recognized as a USB CDC Ethernet Control Model device. I could immediately see it appear as a network interface and had successfully configured to be an ethernet device! Awesome! Using Wireshark, Dr Shawn and I also tested and monitored the packets being transferred over USB. Overall, it was a great week after getting to finish one of my main projects and am excited for the next couple of weeks that involves using a third party TCP/IP stack called lwIP to be interfaced with the USB CDC ECM device. I hope I can manage it.
0 Comments