Trouble with code created by CubeMx for usb device cdc on STM32H743

[EBrun]

..

[EBrun]

STM32H743ZIT6 rev Y on custom board

STM32CUBEMX v6.7.0

I imported a project from an old version (only code generated by

STM32CUBEMX) and migrated to the new version.

Created the project code.

The created project fails to run and always fails.

STM32CUBEIDE v1.11.2

Manually update Usb Device from v2.5.3 to v2.11.1 on my application

To get it to work I had to manually edit the code to enable

the usb transceiver.

File "stm32h7xx_hal_pcd.c"

Function "HAL_StatusTypeDef HAL_PCD_Start(PCD_HandleTypeDef *hpcd) {"

Replace the line

   "if(((USBx->CID & (0x1U << 8)) == 0U) && (hpcd->Init.battery_charging_enable == 1U)){"

with the line

   "if((hpcd->Init.phy_itface != USB_OTG_ULPI_PHY) && (hpcd->Init.battery_charging_enable == 1U)){"

as it was already for version 2.5.3

USBx->CID register value (in debug registers OTG_HS_CID 0x4008003c) (in datasheet OTG_CID):

- post reset = 0x0000000

- post "__HAL_RCC_USB_OTG_FS_CLK_ENABLE()" = 0x00002100

On the datasheet the reset value is 0x00002300

Why this difference?

What meaning/context does the value of this register have?

I can't find anything in the code that updates/modifies this registry.

Did I miss something copying the drivers?

Thanks in advance

Best Regards

Enzo Bruno

[Ghofrane GSOURI]

Hello again @EBrun​ 

Concerning your question about the OTG->CID register value meaning :

**The OTG_CID register is a 32-bit register in the USB On-The-Go (OTG) core of a microcontroller that contains the product ID of the USB controller as its reset value. 

The product ID is a unique identifier that is assigned by the manufacturer of the USB controller and is used to differentiate it from other similar products.

The reset value of the OTG_CID register is 0x00002300, which means that when the microcontroller is reset, the OTG_CID register is set to this value. 

This value corresponds to the product ID of the USB controller, which is a unique value that is assigned by the manufacturer. 

By having the product ID as the reset value of the OTG_CID register, it ensures that the USB controller can be uniquely identified by software during initialization.

During the operation of the USB controller, the OTG_CID register may be read by software to obtain the product ID of the USB controller. 

This can be useful in certain applications where it is necessary to differentiate between different USB controllers or to perform specific operations based on the product ID.

It is important to note that the value of the OTG_CID register should not be modified during normal operation of the USB controller, 

as it may cause unexpected behavior or communication errors. Any modifications to the OTG_CID register should only be performed during initialization 

or configuration of the USB controller, and should be done carefully to avoid any unintended consequences.

**The "__HAL_RCC_USB_OTG_FS_CLK_ENABLE()" function is a macro which is used to enable the clock for the USB OTG FS peripheral. When the macro is executed, 

it sets a bit in a register of the RCC peripheral that controls the clock enable/disable state of the USB OTG FS peripheral.

**Concerning the line of code that you replaced :

if(((USBx->CID & (0x1U << 8)) == 0U) && (hpcd->Init.battery_charging_enable == 1U))::

This line means :

The first condition checks whether a bit in the USBx->CID register is clear (equal to 0). The bit being checked is the one at position 8, which is shifted by 1 bit to the left (0x1U << 8).

If this condition is true, it means that the USB device is not connected to a charger.

The second condition checks whether the "battery_charging_enable" flag in the PCD_HandleTypeDef structure is set to 1.This flag is used to enable or disable the battery charging feature of the USB controller.

If both conditions are true, the code inside the if statement will be executed, otherwise, it will be skipped.

**if((hpcd->Init.phy_itface != USB_OTG_ULPI_PHY) && (hpcd->Init.battery_charging_enable == 1U))

The first condition checks whether the "phy_itface" member of the PCD_HandleTypeDef structure is not equal to "USB_OTG_ULPI_PHY". 

This member is used to select the USB physical interface used by the controller,

and "USB_OTG_ULPI_PHY" refers to the UTMI+ Low Pin Interface (ULPI) PHY.

The second condition checks whether the "battery_charging_enable" member of the PCD_HandleTypeDef structure is set to 1.

This member is used to enable or disable the battery charging feature of the USB controller.

The USB physical interface is the physical layer of the USB communication protocol, which is responsible for transmitting data over the USB cable. 

It includes the USB connector,the cable, and the electronics that transmit and receive data between the USB host and the USB device.

The USB controller is a device that manages the USB communication between the USB host and the USB device.

It includes a physical interface that is designed to be compatible with a specific USB physical interface specification, 

such as USB 1.x, USB 2.0, or USB 3.x. The physical interface is responsible for encoding and decoding the data transmitted 

over the USB cable, and for managing the electrical signals required for the USB communication.

The physical interface used by the USB controller is determined by the design of the USB controller and is specified in the datasheet 

or documentation of the controller. Different physical interfaces have different electrical and functional characteristics, 

and may be compatible with different USB devices or host controllers. For example, some USB controllers may use the UTMI+ Low Pin Interface (ULPI) PHY, 

while others may use the High-Speed Inter-Chip (HSIC) PHY, depending on the requirements of the specific USB application.

This is my first analysis I will keep investigating this issue and I will keep you posted with updates.

Thanks for sharing you *ioc file with me .

Ghofrane

[fed5552]

Hi, 

So if OTG_CID register is 0x00002300 and the condition is if((USBx->CID & (0x1U << 8)) == 0U), then the result is always FALSE, cause bit8 of OTG_CID is 1. The USB Transceiver is thus never enabled. Is it a bug or am I misunderstanding something?

Regards,

Andrej.

 

[Ghofrane GSOURI]

Hello @EBrun​ 

First let me thank you for posting.

Could you please provide your project in order to investigate the issue .

I'll be waiting for your feedback.

Thx

Ghofrane

[EBrun]

Hi Ghofrane

I have inserted the file *.ioc for cube mx

Best Regards

Enzo Bruno

[EBrun]

Hi Ghofrane

Thank you for your quick answer.

I read all your answer, in my specific case why the CID register has value 0x2100 instead of reset value 0x2300 as per datasheet ?

Looking in the sources I see that the CID register is used as a test on bit8 only for both usb host and usb device. In your answer I read that the entire register represents the PRODUCT_ID of the type of usb used by the manufacturer, so why test the bit8 only?

Where can I find more details and/or specifications on this specific register ?

Is the modification I made to make it work correct or does it hide another type of problem not currently detected?

In the ioc file I sent you I tried to create a composite usb device driver with cdc + hid but I was unsuccessful, the created code has only the cdc driver. I point out that the original code from previous version of cube mx was only for usb device cdc.

Best Regards

Enzo Bruno

[EBrun]

Hi Ghofrane

As regards the creation of the project for the composite ubd device cdc + hid, I have already solved it.

Best Regards

Enzo Bruno

[RolfStDK]

Hi EBrun,

    I wonder how did you fix the issue wit the CID= 0x2300, as the first condition in if(((USBx->CID & (0x1U << 8)) == 0U) && (hpcd->Init.battery_charging_enable == 1U)), is not fullfilled, and the USB Transceiver is not enabled.

Thaks,
Rolf