2024-03-28 02:45 PM
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
Solved! Go to Solution.
2024-03-28 09:43 PM
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.
2024-03-28 09:43 PM
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.
2024-03-29 02:59 AM
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
2024-03-29 03:57 AM
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
2024-03-29 08:05 AM
I will try to replicate with a Nucleo-F446RE. Get back to you then. In the meantime can you tell me what board specifically.
2024-03-29 08:40 AM
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
2024-03-29 08:43 AM
Hallo Eddie,
I tried my tiny test application on a STM32F401RCT6 and a STM32F401CCU board, with identical results.
Greetings,
Fred Schimmel
2024-04-18 11:35 AM
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);
}
}
2024-04-26 05:50 AM
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