 In this part we will cover tips, tricks and best practice about debugging USB on STM32 we were able to collect during years of support. Some of the devices are not tied only to STM32 as they are protocol related, but most of the time is the focus on STM32 USB middleware layer which need to be fine-tuned for customizing the application. What device can be used for USB debugging? Most developers have the possibility to use Oscilloscope in their lab. Oscilloscope is the best choice if electrical parameters of the USB bus need to be checked to verify correctness of hardware design. Signal measured by Oscilloscope can be analyzed by PC2 provided by usb.org or some vendors directly add this application into their Oscilloscope. Also you can find guidance for various types of Oscilloscope on usb.org But for debugging of application itself, Oscilloscope is not a convenient device. Length of recording is not sufficient for analysis and most Oscilloscopes don't have option for decoding USB communication. Dedicated USB analyzer which are also cheaper than Oscilloscopes in general are much better choice here. There are more different kinds of USB hardware analyzer from more vendors. Difference is in maximum speed analyzer can record, so high speed or super speed, advanced record option like for example power delivery, filtering and display option. Some analyzers are able not only to record but also generate USB traffic like a host. And that can make at the end very significant difference in the price. Some basic hardware USB analyzers starts on 1000 euro. USB analyzer can show all the details about the traffic on the bus, decode messages, show timing. So also here you can get possible errors in descriptors and for example if you are not able to establish the communication between microcontroller and PC using analyzer you will discover where the problems come from using the USB analyzer. For debug purposes can be used also debug messages implemented in USB library, mainly in the host part. These debug messages are showing mainly the states of internal USB state machine executed inside MCU and the information observed using it is very limited compared to USB analyzer. Debugging using breakpoints and stepping through the code is possible more or less only with USB host which is driving the communication and the device needs to follow its timing. But for USB device it's not convenient as the device may be disconnected by the host when handshake on free consecutive transfer is missed. There exists also software option for USB debugging like Microsoft Message Analyzer or Wireshark. But as software tools goes through PCs, USB hardware and drivers, timing is either not available or it's not reliable. On top of that some messages are not propagated. For example incomplete or corrupted message may be missing and this may be crucial to catch during development. And if you are developing USB host functionality software analyzer on PC cannot be used and hardware one is only option. Also level of displayed message analyzing and decoding is not on such level like dedicated tools for hardware analyzers. Tricky point with developing USB devices with Windows PC we need to mention is product ID and vendor ID combination. As vendor ID and product ID shall be unique for each kind of functionality after successful enumeration windows save setting of the device into the register and next time device with same vendor ID and product ID combination is detected information obtained during enumeration are ignored. So for example if connected USB mouse with any combination of vendor ID and product ID is successful enumerated and bit later you connect for example CDC device with exactly the same combination of vendor ID and product ID like the HID before. Windows automatically enumerate as HID device because this is the device which was once already successfully enumerated with this vendor ID and product ID combination. How to get dedicated vendor ID and product ID combination for the final device is covered in USB driver chapter. Sometimes windows is not able to assign correct driver to connected device then it's needed to handle the driver assignment manually using the control panel as the example is show on the slide. Quite interested option device manager is offering is view device by connection. This will show USB interconnection inside your PC. How hubs are connected, which USB ports are connected to which hub and which devices are the end connected using which path to the root hub. Some of these functionality can be achieved also using dedicated application like for example USB view which can up top of that show directly descriptors of the connected devices very easily. Why is this actually important for us? As there was already explained in the theory USB hub need to share the bandwidth between all connected devices and bulk transfers don't have allocated bandwidth and get only the rest of not used by control, isochronous or interrupt transfers. So difference of USB master which device connected directly to the root hub without any other device connected there or to the hub with three already connected devices can be quite significant. Also some laptops are able to offer a USB port directly connected to the root hub but it's not mandatory option. And even if all USB port on the PCs are disconnected we are able to see a lot of devices is connected already. These are the internal devices of the laptop connected to the USB like for example touchpad, Bluetooth, some sensor or similar devices. There is also small mention about debugging in the next environment with the specific messages. Also Warshark can be used on the Linux but more exhausting information can be found directly on the web or on various web pages and forum. Also it's expected that Linux users are already more or less familiar with the options the system is offering to them. Here is a highlight of commonly observed problem from our support. First one is the list on the list is small heap size. As you could see during hands-on, USB middleware in STM32 libraries use the dynamic allocation of the memory. So USB structures and buffers are stored in heap. And for some classes default KubeMx value which is 200 hexadecimal is not enough which cause the failure at the end during connection. So some users also change the library in order to use static allocation instead of dynamic one for their end application. Very end is the problem with the driver in Windows end or lower. As CDC class demands usage of the signed driver there. For development is enough to use unsigned driver and go through warning window during manual assignment of the driver but for release signed driver is mandatory. This problematic is also covered in USB driver chapter. With Windows 10 new driver and policy was introduced so no need for dedicated signed driver anymore in this system but in product it will be still needed to keep compatibility with still very popular Windows 7 or 8. Another common problem is VBUS Sensing which is one of the OTG peripheral features. If not considering OTG dual row functionality VBUS has two purposes. First not so important is to get 100% inline with USB specification which allows to have voltage on data lines of USB device this mean pull up resistor on D plus only after detection of host VBUS connection. More important reason to use VBUS Sensing is the capability to differentiate USB suspend and disconnection state. Mandatory it's mainly for self-powered device. In USB library you need to properly connect dedicated pin before enabling it in configuration. For the hardware connection and constraints connected to it to VBUS please follow the USB hardware chapter. As already mentioned in previous slides also developing and changing functionality of the device with some vendor ID and product ID combination without train stalling driver can be tricky and cause not exactly present pleasant searching for the root case.