Function body has content of opposite function

[FredS]

Hallo,

I struggled already two days with the implementation of USB_OTG_FS on a STM32F401 board. The most prominent error concerns the Virtual Com Port on the Windows PC: whatever I try, there is always a message saying "USB device not recognized", with as addition "Device Descriptor request failed".

In a final attempt I stepped my debugger through the initialization process and encountered the function 'USB_DevConnect(...)', located in the file: "ProjectName>>Drivers>>STM32F4xx_HAL_Driver>>Src>>stm32f4xx_ll_usb.c", line 76. I considered the statements in that function a bit strange, until my eye fell on the function 'USB_DevDisconnect(...)' right below the former one. The body of both functions are exact copies of each other!

At first I thought I messed up this file myself, so I checked the "master" file in the Repository for STM32F4xx targets, with the same result. Still I couldn't believe this came from ST, so I downloaded the most recent version, the "STM32Cube_FW_F4_V1.28.0" repositry, unzipped the file and checked the content of "stm32f4xx_ll_usb.c". Also here the problem appeared present in 'USB_DevConnect(...)', so I have no way to correct......

I sincerely hope ST will read about this flaw and file it on their "to-do-list". I assume it will not cause an emergency update release, but it will be very helpfull when a "repaired version of the file 'stm32f4xx_ll_usb.c' will be available soon.

Thanks for your attention,

Fred Schimmel

 

[STM_Thirty2]

I am not sure what you are seeing because according to the latest code found on the public github repo 

The functions are not identical, one is setting the soft disconnect (SDIS) while the other is clearing it. 

[FredS]

Hallo Eddie,

My sincere apologies for spoiling the bandwith and taking some of your time. You are completely right, the last statements in each function are NOT identical and do as you pointed out.

I will redo my debugger stepping to detect which action produces the "USB device not recognized" message and report my experience.

Have a nice weekend,

Fred Schimmel

[FredS]

Hallo Eddie,

I just have tried to get a project running on a STM32F401RCT6 board that just should output the values of an uint16_t array by USB_OTG_FS , configured as VCP device. I started the built-in 'serial wire' debugger and stepped through all relevant statements of the main function 'MX_USB_DEVICE_Init()'. When I arrived inside the function 'USB_DevConnect(...)', the execution of the second statement (USBx_DEVICE->DCTL &= ~USB_OTG_DCTL_SDIS;) caused the windows popup "USB device not recognized".

In the Windows Device Manager I identified the related USB device, see:

As this project only contains the USB_OTG_FS and a small piece of code that produces the data-array to be exported I am stuck. The application seems to run in the main 'while(1)' as designed, except the fact the function 'CDC_Transmit_FS(....)' doesn't do anything because the OTG status is 'HAL_BUSY'.

For completeness I add relevant segments of the project:

........
/* Private define ------------------------------------------------------------*/
/* USER CODE BEGIN PD */
#define CCD_BUFF_LEN			300
#define STEP_SIZE				100
#define DELAY_TIME				1000

/* USER CODE END PD */

/* Private macro -------------------------------------------------------------*/
/* USER CODE BEGIN PM */

/* USER CODE END PM */

/* Private variables ---------------------------------------------------------*/

/* USER CODE BEGIN PV */
uint16_t		g_CCD_Buff[CCD_BUFF_LEN];
uint8_t			g_OTG_Tx_Result = 0xAB;

/* USER CODE END PV */

/* Private function prototypes -----------------------------------------------*/
void SystemClock_Config(void);
static void MX_GPIO_Init(void);
/* USER CODE BEGIN PFP */

uint8_t CDC_Transmit_FS(uint8_t* Buf, uint16_t Len);
/* USER CODE END PFP */
.......

and :

 ....
 /* Infinite loop */
 /* USER CODE BEGIN WHILE */
 while (1)
 {
	 uint16_t	i;
	 uint16_t	offset;

	 for (i=0; i < CCD_BUFF_LEN; i++) {
		 g_CCD_Buff[i] = i + offset;
	 }
	 g_OTG_Tx_Result = CDC_Transmit_FS((uint8_t *)g_CCD_Buff, (uint16_t)CCD_BUFF_LEN*2);
	 offset += 100;
	 HAL_Delay(DELAY_TIME);

 /* USER CODE END WHILE */

 /* USER CODE BEGIN 3 */
 }
 /* USER CODE END 3 */
.....

I have no clue how to proceed. Can you help?

Thanks again,

Fred Schimmel

[STM_Thirty2]

I will try to replicate with a Nucleo-F446RE. Get back to you then. In the meantime can you tell me what board specifically.

[PR1G0RYAN]

I banged into same issue with with my F103 after update to Cube IDE 1.15. Seems like autogeneration sucks.
This is what I got:

static void Get_SerialNum(void)
{
 uint32_t deviceserial0;
 uint32_t deviceserial1;
 uint32_t deviceserial2;

 deviceserial0 += deviceserial2;

 if (deviceserial0 != 0)
 {
 IntToUnicode(deviceserial0, &USBD_StringSerial[2], 8);
 IntToUnicode(deviceserial1, &USBD_StringSerial[18], 4);
 }
}

And here's how IT SHOULD BE:

static void Get_SerialNum(void)
{
 uint32_t deviceserial0;
 uint32_t deviceserial1;
 uint32_t deviceserial2;

 deviceserial0 = *(uint32_t *) DEVICE_ID1; // Missing
 deviceserial1 = *(uint32_t *) DEVICE_ID2; // Missing
 deviceserial2 = *(uint32_t *) DEVICE_ID3; // Missing

 deviceserial0 += deviceserial2;

 if (deviceserial0 != 0)
 {
 IntToUnicode(deviceserial0, &USBD_StringSerial[2], 8);
 IntToUnicode(deviceserial1, &USBD_StringSerial[18], 4);
 }
}

[PR1G0RYAN]

P.S. Found the related issue: https://community.st.com/t5/stm32cubeide-mcus/stm32-cube-ide-1-15-usb-middleware-codegen-bug/m-p/655503