cancel
Showing results for 
Search instead for 
Did you mean: 

Function body has content of opposite function

FredS
Senior

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

 

1 ACCEPTED SOLUTION

Accepted Solutions
STM_Thirty2
ST Employee

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. 

If you feel a post has answered your question, please click "Accept as Solution"

View solution in original post

8 REPLIES 8
STM_Thirty2
ST Employee

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. 

If you feel a post has answered your question, please click "Accept as Solution"

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

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:DeviceManager_USBerror_.jpg

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
ST Employee

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

If you feel a post has answered your question, please click "Accept as Solution"

Hallo Eddie,

I have no idea on the implications, but when I let CUBEIDE execute 'Clean Project' followed by a new 'Build Project' to get all sources compiled again, I saw some warnings, see below:

../USB_DEVICE/App/usbd_desc.c: In function 'Get_SerialNum':
../USB_DEVICE/App/usbd_desc.c:394:17: warning: 'deviceserial0' is used uninitialized [-Wuninitialized]
  394 |   deviceserial0 += deviceserial2;
      |   ~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~
../USB_DEVICE/App/usbd_desc.c:390:12: note: 'deviceserial0' was declared here
  390 |   uint32_t deviceserial0;
      |            ^~~~~~~~~~~~~
../USB_DEVICE/App/usbd_desc.c:394:17: warning: 'deviceserial2' is used uninitialized [-Wuninitialized]
  394 |   deviceserial0 += deviceserial2;
      |   ~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~
../USB_DEVICE/App/usbd_desc.c:392:12: note: 'deviceserial2' was declared here
  392 |   uint32_t deviceserial2;
      |            ^~~~~~~~~~~~~
../USB_DEVICE/App/usbd_desc.c:399:5: warning: 'deviceserial1' may be used uninitialized [-Wmaybe-uninitialized]
  399 |     IntToUnicode(deviceserial1, &USBD_StringSerial[18], 4);
      |     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../USB_DEVICE/App/usbd_desc.c:391:12: note: 'deviceserial1' was declared here
  391 |   uint32_t deviceserial1;
      |            ^~~~~~~~~~~~~

When I try to understand what the function 'Get_SerialNum' will assign to 'deviceserial0' and 'deviceserial1',
I conclude it will be undefined, depending on the old values on the addresses of these variables.

As I mentioned before, I have no idea of the consequences for a successful USB connection, but I think it is useful to report such CUBEIDE compiler-warnings.

Enjoy your weekend,

Fred Schimmel

Hallo Eddie,

I tried my tiny test application on a STM32F401RCT6 and a STM32F401CCU board, with identical results.

Greetings,

Fred Schimmel

PR1G0RYAN
Associate II

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);
  }
}