This is week five of my internship at Aeste Works. To move forward to what I have to do to implement USB CDC ECM class for ethernet over usb, I’d have to first migrate the USB CDC ACM demo from the PIC32MX which I had been working on last week to the PIC32MZ in which the company’s own board utilises. I was provided a schematic showing the pinouts of the custom board and was tasked to implement a simple LED blink with it. As for the migration part, I was fortunate enough to find a harmony configuration that worked with the custom board which was great as all the necessary configuration code and USB stack would be initialised from there. The only changes needed to make the USB CDC ACM demo to work were to replace the Board Support Package functions being used.
Once the USB CDC ACM demo worked on the PIC32MZ, it was time to code the necessary descriptors for the ECM class. I copied what I had written last week on the PIC32MX to the PIC32MZ under the USB stack initialisation data and after that was done, monitored the USB packets using Wireshark in ensuring that enumeration between the board and the host is successful. Wireshark is a packet analyzer. A packet analyzer will try to capture network packets and tries to display that packet data as detailed as possible. As expected, there were some errors found that caused the board to not enumerate with the host. There was a malformed packet under the Get DESCRIPTOR Response Configuration which meant that some descriptor fields were incorrectly set. Looking closely at the usb packets, it was clear that the ECM Functional Descriptor was causing the packet to malform. According to the USB specification, fields of the ECM Functional Descriptor such as the Ethernet statistics, Maximum segment size and Number of MC Filters require more than 1 byte of data to be inputted. I had incorrectly set the fields under the ECM functional descriptor structure to all just 1 bytes which caused the packet to malform.
After correcting that issue, the board still unsuccessfully enumerates with the host. There was now another issue with the endpoint descriptor having an incorrect length of 7 bytes but according to the USB specification, this was supposedly correct as all the fields within this descriptor amounted to 7 bytes. I was stuck at this issue for quite some time, and after Dr Shawn reviewed this issue with me, we decided to analyze a third party that had implemented an ethernet over USB solution to see the descriptors that they used and the fields that they had set. The third party had a demo that worked with the PIC32MX and after analyzing the USB packets with wireshark, we found that our Endpoint Descriptor field values were the same but we couldn’t get more information as there were no details on the Functional Descriptor. I double checked that every single Descriptor and their respective fields were correct and cross-referenced it with the USB specification to make sure that everything was set properly.
Thankfully, just before the weekend, I managed to solve this issue under the Configuration Descriptor which contains information about the configuration and its interfaces, alternate settings, and their endpoints. In it was one field, that I overlooked which was supposed to hold the value for the total size of all the descriptors. It was set to default size of 67 bytes from the previous demo and since I had changed the Functional Descriptor to fit the Ethernet Control Model from the Abstract Control Model, the total size of the descriptors have now changed. After fixing this, and monitoring the packets through Wireshark, the device and host enumerates successfully and this was shown after all the necessary standard USB device requests have been made. The host still sees the device as a COM port and not as a network adapter but Dr Shawn explained to me that this is due to the Vendor ID and Product ID by Microchip that the code was currently using. I would have to modify this next week to fit it for Ethernet Networking Devices. Overall, a challenging week in troubleshooting the problems that I’ve faced but rewarding seeing them solved.
0 Comments