Week Four

This is my fourth week as an Intern at Aeste Works. My main target this week was to configure the PIC32MX microcontroller as a Universal Serial Bus Communications Class Device that utilizes the Ethernet Networking Control Model (ECM) in allowing the exchange of Ethernet-framed data between device and host. The first two days of the week were going through Microchip’s USB library documentation and USB Specification for Communication Devices to understand how the USB stack is structured specifically for the PIC32MX. 

The first thing to do to get the PIC32MX to register as a CDC ECM class was to configure two main parts for the Device Layer Initialization. The Device Layer Initialization must first be successful before the application can open the Device layer and register a Device layer event handler which receives device level events such as device configured, device deconfigured, device reset and device suspended. The first main part was to configure the Master Descriptor Table which is a container for all descriptor related information that is needed by the Device Layer for its operation. The table should contain a Pointer to the Full-Speed or High-Speed Device Descriptor in which a number of sub descriptor fields should be set (I.e. Interface descriptors, CDC Class-Specific Descriptors etc), the Number of Full-Speed or High-Speed Configurations, a Pointer to a Table of String Descriptors that can contain Manufacturer and Product String Descriptors and lastly, the Number of String Descriptors.

There were a lot of descriptor fields that needed to be set and the best way to get started with this task was to utilize a USB CDC demo provided by Microchip that has all the USB Stack configured nicely.  However, Microchip does not provide a demo specifically for the Ethernet Control Model and thus, some changes were needed to change the current Abstract Control Model that they used for the demo. The current demo exposes the USB device as a virtual COM Port to the operating system. Since, both Ethernet Control Model and Abstract Control Model are both subclasses of the Communications Interface Class, there were some similarities in the set fields of the descriptors.  There were a lot of minor changes that had to be implemented but I’ll just talk about the major change since it really is a lot to write. The major change was to completely replace the functional descriptor (Note that this is for the Master Descriptor Table) to fit the Ethernet Control Model. A functional descriptor simply describes the class specific contents and contains the class specific functionalities and in this case, for the Ethernet Control Model. I had to code a structure that contains the descriptor fields specific to the USB CDC ECM Functional Descriptor and the necessary “defines” for these fields according to USB 2.0 Specifications. 

The second part for the Device Layer Initialization contains information about the function drivers that are present in the application. The Device Layer needs this information to establish the intended functionality of the USB Device and then manage the operation of the device. Since the function drivers have already been coded in for the Communication Device Class, there was no change to be done here. The next step was to build and program the PIC32MX with the modified code to hopefully get it recognized as a USB CDC ECM device. Once it successfully built, I used wireshark to monitor the USB packets and check for any errors during the configuration process of the USB CDC device (the PIC32MX). Not surprisingly, a malformed packet was observed that is related to the functional descriptor during the GET descriptor request from the host.

Unfortunately, due to my carelessness, I pushed the USB micro cable too hard on the USB micro port on the PIC32MX ethernet starter kit when I was showing Dr Shawn what I’d done so far and that caused the usb port to break out from the board. As expected, I received scolding for that and I learnt some important lessons on being an engineer that day. We spent a few hours to figure whether we could use the USB type A port on the PIC32 as an alternative but in the end Dr Shawn instructed me to get started on the company’s own boards that utilise PIC32MZ instead of the PIC32MX on the ethernet starter kit. Essentially, it’s back to square one in writing software for the USB CDC ECM but now there will be no board specific harmony configuration files for me to use on the company’s custom board and I’ll have to write it myself and refer to the board’s schematic to understand how all the pins are set.  I really wish I hadn’t screwed up but there’s no choice but to move forward and learn from my mistakes.