 Hello and welcome to this presentation of the STM32H7 USB full-speed and high-speed interfaces. It covers all the features of these interfaces, which are widely used to connect either a PC or a USB device to the microcontroller. This figure shows the connections between an STM32H7 microcontroller and a USB connector. The STM32H7 features a USB full-speed communication interface, allowing the microcontroller to communicate typically with a PC or a USB storage device. The simplest implementation is a USB peripheral device, but the STM32H7 also supports the USB on-the-go functionality. Let's look at some of the key features of this USB full-speed interface, which is a USB specification 2.0 compliant interface that operates at a 12 megabit per second rate. In the simplest form, a USB FS device can be implemented. Built-in support for link power management adds enhanced power modes on top of the USB 2.0 specification. In addition, the on-the-go or OTG functionality enables implementation of an OTG product or an embedded host, both of which have the capacity to behave as a targeted host. The battery charger detection function allows for increased current to be drawn from BC 1.2 compliant chargers up to 1.5 amps. USB 2.0 high speed is also available via the ULPI interface. The same modes of operation are possible when coupling with an external ULPI transceiver. Let's explain more deeply the USB on-the-go or OTG functionality. The default role is determined by the connection of the cable, additional ID pin inside of the connector. If the USB peripheral has only one role, the ID pin is ignored. The role of the peripheral can be switched on the fly, while the two OTG devices are directly connected using a point-to-point connection. This functionality is only possible on devices with micro-A or micro-B controllers. For example, some smartphones have this capability. The peripheral is fully capable to work as OTG, but currently there is no firmware support in STM32 cube HAL libraries. The STM32 H7 microcontroller embeds two instances of a USB HS peripheral, OTG HS1 and OTG HS2. Both support full-speed communication and OTG mode, but only the OTG HS1 peripheral supports high-speed communication through an external HS5 thanks to its ULPI interface. This is an overview of the peripheral's characteristics. Up to nine channels, including endpoint zero, can be used for device implementation, which can be useful for creating more complex composite devices. On the host side, up to 16 channels can be used in parallel. As already highlighted, both instances have a dedicated 4-kilobyte RAM for FIFO, support link power management, OTG mode and battery charging management. But only OTG HS1 can connect using an external USB-fi using the ULPI hardware interface to work in high-speed mode. In this block diagram, the USB OTG high-speed controller core, HS1 instance, is shown in the center with its data FIFOs below. The FS physical layer or FI on its right side handles the analog signal levels including many specific level detections relating to on-the-go and battery charger detection functions. For high-speed operation, an external ULPI-fi transceiver can be connected to the HS2 core. The USB interrupt goes to the Cortex processor to signal various USB events. The AHB slave interface enables read-write access of the controller registers and the power and clock control block. Transfers to and from memory are handled by a DMA engine inside the controller via the AHB master interface. In this block diagram, the USB OTG high-speed controller core, HS2 instance, is shown in the center with its data FIFOs below. The FS-fi on its right side handles the analog signal levels including many specific level detections relating to on-the-go and battery charger detection functions. Note that the connectivity of the HS2 core only allows full-speed operation. The USB interrupt goes to the Cortex processor to signal various USB events. The AHB peripheral bus enables read-write access of the controller registers and the power and clock control block. Depending on the use case, that is either device only or OTG device, a low or high-speed crystal oscillator is necessary to provide an accurate timing reference for the USB block. The voltage regulator dedicated for OTG peripherals is a new feature of the STM32H7 family. Using this regulator, only an OTG peripheral can be sourced. Other internal or external functions cannot be connected to pin VDD33 USB. This allows the peripheral to be powered directly from VBUS without any additional components and using a different voltage level for MCU VDD. Setbit USB-REGEN to zero when a USB peripheral needs to be supplied with an external 3V3 voltage source, as on older devices. To achieve a high-speed communication, a high-frequency clock is required. So the USB clock is sourced from the HSE clock. For full-speed communication, a crystal-less design can be implemented based on the clock recovery system or CRS. Note that this clock recovery system is only relevant for the case of a full-speed device. At any given time, one of the two operating modes, host or device modes, is functional. Peripheral mode is used for a regular device or an OTG device when operating in device mode. A 1.5 kiloohm pole resistor on the D-plus line can be used to show the presence of the device on the bus. One bi-directional control endpoint zero is available for application implementation. Another 8-in and 8-out endpoints can then be set on the fly. A dedicated 4-kilobyte RAM can be divided into one shared RX-FIFO and up to nine TX-FIFOs, one for each out endpoint. Targeted host mode is used for an embedded host or an OTG device when operating in host mode. In host mode, it is necessary to use an external charge pump to drive the V-bus voltage. An application can use up to 16 host channels or pipes, which can change transfer type on the fly. An embedded hardware scheduler can manage up to 16 periodic and 16 non-periodic requests. Periodic requests are requests from interrupts and isochronous channels. Non-periodic requests are requests from bulk and control channels. FIFO RAM is divided into three shared parts. RX-FIFO, TX-FIFO for periodic transfers, and TX-FIFO for non-periodic transfers. This slide shows the support of the standard USB classes by the STM32 library. Now let's take a brief look at the various low power modes of the USB physical layer, or FI, and the controller. For the FI, power down mode can be used, for example, when there is no V-bus present and the session is identified to be not OTG. It is also possible to disable the V-bus sensing related to OTG, A and B sessions, if the OTG function is not used. During suspend mode, there is no dynamic signaling occurring over the USB interface, so three different controls are offered to lower the power consumption as desired by the application. Low power modes for the high speed core are similar to the full speed one, but the modes concerning the FI are not listed, as in this case, the FI or transceiver is an external component. The USB peripheral is active in run and sleep modes. In stop mode, the USB is not available, but the contents of its registers are kept. In standby mode, the USB peripheral is powered down and must be reinitialized when returning to a higher power state. Within the USB module, certain dedicated bits are implemented to allow debug functionality in a USB application. They relate to FIFO status and contents and the scheduling of periodic queues in host mode. Additional details of these debug bits are listed in this table. Here is an application example of a low power device. Power is drawn directly from the USB V-bus signal. To get a precise enough clock signal for high speed communication, the USB clock is sourced from the clock recovery system without the need for an external resonator component enabling a crystal-less design for such applications. For complete USB specification documents, please refer to usb.org. The USB 2.0 document homepage has a zip file containing the USB 2.0 and OTG 2.0 specifications and an ECN for LPM. The USB device class documents page has the battery charger specification.