Hallo everyone,
I tried to export the measured data of my project on a WeAct-3.0 STM32H723 board as an USB_OTG_HS stream to a Virtual COM Port on my Windows desktop. Unfortunately, I fail to get this operational, despite many trial and error attempts. Finally I reduced the challenge to just writing a test-string to USB, but even this minimal task doesn't even invokes a port in the Windows Device Manager.
Still being a beginner, I work with STM32CubeIDE, version 1.16. I created a new project, configured the HSE with a 25MHz crystal, configured the CPU clock @ 250MHz, and the USB clock @ 48MHz via HSI48. I configured an uint8_t array 'text' with a string constant assigned to it. Finally in the main 'while()' loop, I invoke the statements:
Return_CDC_Transmit = CDC_Transmit_HS(Txt, sizeof(Txt));
HAL_Delay(1000);
Count++;
When I run this project with the Debugger, I see the value of 'Return_CDC_Transmit' become 1 (Busy) and 'Count' increasing every second (as expected). However, as there is no VCP, I cannot receive the bytes.
I have tried to inform myself better by reading the USB_OTG chapter in RM0468, but soon found this a useless track for me: I became overwhelmed with a flood of descriptions for all different cases supported, obscuring what I need to know. Searching the internet for descriptions of similar cases gave no clues that helped me out. Also the various introductions and tutorials I found don't provide me info to zoom in on the cause of the failure.
As additional complication, I appear not capable to define acceptable names for USB_OTG Register variables in the column 'Live Expressions' of the Debugger. In this specific case the Register values probably won't help me much as I fail to understand the meaning of the many registers, but I consider this mismatch a big failure of STM. What is the use of documenting Registers when the user cannot apply the documented Register names to retrieve their values from a Debugger ???
In another attempt to find a clue, I changed the compiler preferences to show all possible errors and warnings, see picture below:
Building the project with this configuration resulted in a shocking list of warnings, many signaling casting issues. Checking on the files involved, I detected a function with useless content, see below:
Description Resource Path Location Type
unused parameter 'pbuf' [-Wunused-parameter] usbd_cdc_if.c /STM32H723VGT_Test_USB_OTG_HS_v1.0/USB_DEVICE/App line 183 C/C++ Problem
unused parameter 'length' [-Wunused-parameter] usbd_cdc_if.c /STM32H723VGT_Test_USB_OTG_HS_v1.0/USB_DEVICE/App line 183 C/C++ Problem
unused parameter 'Len' [-Wunused-parameter] usbd_cdc_if.c /STM32H723VGT_Test_USB_OTG_HS_v1.0/USB_DEVICE/App line 264 C/C++ Problem
enumeration value 'HAL_MDMA_XFER_ALL_CB_ID' not handled in switch [-Wswitch-enum] stm32h7xx_hal_mdma.c /STM32H723VGT_Test_USB_OTG_HS_v1.0/Drivers/STM32H7xx_HAL_Driver/Src line 424 C/C++ Problem
enumeration value 'HAL_DMA_XFER_ALL_CB_ID' not handled in switch [-Wswitch-enum] stm32h7xx_hal_dma.c /STM32H723VGT_Test_USB_OTG_HS_v1.0/Drivers/STM32H7xx_HAL_Driver/Src line 1594 C/C++ Problem
conversion to 'long unsigned int' from 'long int' may change the sign of the result [-Wsign-conversion] core_cm7.h /STM32H723VGT_Test_USB_OTG_HS_v1.0/Drivers/CMSIS/Include line 2132 C/C++ Problem
conversion to 'long unsigned int' from 'long int' may change the sign of the result [-Wsign-conversion] core_cm7.h /STM32H723VGT_Test_USB_OTG_HS_v1.0/Drivers/CMSIS/Include line 2148 C/C++ Problem
conversion to 'long unsigned int' from 'int32_t' {aka 'long int'} may change the sign of the result [-Wsign-conversion] core_cm7.h /STM32H723VGT_Test_USB_OTG_HS_v1.0/Drivers/CMSIS/Include line 2303 C/C++ Problem
conversion to 'long unsigned int' from 'int32_t' {aka 'long int'} may change the sign of the result [-Wsign-conversion] core_cm7.h /STM32H723VGT_Test_USB_OTG_HS_v1.0/Drivers/CMSIS/Include line 2311 C/C++ Problem
conversion to 'long unsigned int' from 'int32_t' {aka 'long int'} may change the sign of the result [-Wsign-conversion] core_cm7.h /STM32H723VGT_Test_USB_OTG_HS_v1.0/Drivers/CMSIS/Include line 2516 C/C++ Problem
conversion to 'long unsigned int' from 'int32_t' {aka 'long int'} may change the sign of the result [-Wsign-conversion] core_cm7.h /STM32H723VGT_Test_USB_OTG_HS_v1.0/Drivers/CMSIS/Include line 2524 C/C++ Problem
conversion to 'long unsigned int' from 'int32_t' {aka 'long int'} may change the sign of the result [-Wsign-conversion] core_cm7.h /STM32H723VGT_Test_USB_OTG_HS_v1.0/Drivers/CMSIS/Include line 2546 C/C++ Problem
conversion to 'long unsigned int' from 'int32_t' {aka 'long int'} may change the sign of the result [-Wsign-conversion] core_cm7.h /STM32H723VGT_Test_USB_OTG_HS_v1.0/Drivers/CMSIS/Include line 2554 C/C++ Problem
conversion to 'long unsigned int' from 'int32_t' {aka 'long int'} may change the sign of the result [-Wsign-conversion] core_cm7.h /STM32H723VGT_Test_USB_OTG_HS_v1.0/Drivers/CMSIS/Include line 2576 C/C++ Problem
conversion to 'long unsigned int' from 'int32_t' {aka 'long int'} may change the sign of the result [-Wsign-conversion] core_cm7.h /STM32H723VGT_Test_USB_OTG_HS_v1.0/Drivers/CMSIS/Include line 2584 C/C++ Problem
conversion to 'int8_t' {aka 'signed char'} from 'uint8_t' {aka 'unsigned char'} may change the sign of the result [-Wsign-conversion] usbd_cdc_if.c /STM32H723VGT_Test_USB_OTG_HS_v1.0/USB_DEVICE/App line 314 C/C++ Problem
conversion to 'int32_t' {aka 'long int'} from 'long unsigned int' may change the sign of the result [-Wsign-conversion] core_cm7.h /STM32H723VGT_Test_USB_OTG_HS_v1.0/Drivers/CMSIS/Include line 2234 C/C++ Problem
conversion to 'int32_t' {aka 'long int'} from 'long unsigned int' may change the sign of the result [-Wsign-conversion] core_cm7.h /STM32H723VGT_Test_USB_OTG_HS_v1.0/Drivers/CMSIS/Include line 2235 C/C++ Problem
conversion to 'int32_t' {aka 'long int'} from 'long unsigned int' may change the sign of the result [-Wsign-conversion] core_cm7.h /STM32H723VGT_Test_USB_OTG_HS_v1.0/Drivers/CMSIS/Include line 2303 C/C++ Problem
conversion to 'int32_t' {aka 'long int'} from 'long unsigned int' may change the sign of the result [-Wsign-conversion] core_cm7.h /STM32H723VGT_Test_USB_OTG_HS_v1.0/Drivers/CMSIS/Include line 2516 C/C++ Problem
conversion to 'int32_t' {aka 'long int'} from 'long unsigned int' may change the sign of the result [-Wsign-conversion] core_cm7.h /STM32H723VGT_Test_USB_OTG_HS_v1.0/Drivers/CMSIS/Include line 2546 C/C++ Problem
conversion to 'int32_t' {aka 'long int'} from 'long unsigned int' may change the sign of the result [-Wsign-conversion] core_cm7.h /STM32H723VGT_Test_USB_OTG_HS_v1.0/Drivers/CMSIS/Include line 2576 C/C++ Problem
conversion to 'int' from 'uint32_t' {aka 'long unsigned int'} may change the sign of the result [-Wsign-conversion] core_cm7.h /STM32H723VGT_Test_USB_OTG_HS_v1.0/Drivers/CMSIS/Include line 2132 C/C++ Problem
conversion from 'unsigned int' to 'uint8_t' {aka 'unsigned char'} may change value [-Wconversion] stm32h7xx_ll_usb.c /STM32H723VGT_Test_USB_OTG_HS_v1.0/Drivers/STM32H7xx_HAL_Driver/Src line 1899 C/C++ Problem
conversion from 'unsigned int' to 'uint16_t' {aka 'short unsigned int'} may change value [-Wconversion] usbd_def.h /STM32H723VGT_Test_USB_OTG_HS_v1.0/Middlewares/ST/STM32_USB_Device_Library/Core/Inc line 449 C/C++ Problem
conversion from 'long unsigned int' to 'uint8_t' {aka 'unsigned char'} may change value [-Wconversion] usbd_desc.c /STM32H723VGT_Test_USB_OTG_HS_v1.0/USB_DEVICE/App line 411 C/C++ Problem
conversion from 'long unsigned int' to 'uint8_t' {aka 'unsigned char'} may change value [-Wconversion] usbd_desc.c /STM32H723VGT_Test_USB_OTG_HS_v1.0/USB_DEVICE/App line 415 C/C++ Problem
conversion from 'int' to 'char' may change value [-Wconversion] syscalls.c /STM32H723VGT_Test_USB_OTG_HS_v1.0/Core/Src line 74 C/C++ Problem
in expansion of macro 'MIN' usbd_ctlreq.c /STM32H723VGT_Test_USB_OTG_HS_v1.0/Middlewares/ST/STM32_USB_Device_Library/Core/Src line 1007 C/C++ Problem
in expansion of macro '__SCB_ICACHE_LINE_SIZE' core_cm7.h /STM32H723VGT_Test_USB_OTG_HS_v1.0/Drivers/CMSIS/Include line 2311 C/C++ Problem
in expansion of macro '__SCB_DCACHE_LINE_SIZE' core_cm7.h /STM32H723VGT_Test_USB_OTG_HS_v1.0/Drivers/CMSIS/Include line 2524 C/C++ Problem
in expansion of macro '__SCB_DCACHE_LINE_SIZE' core_cm7.h /STM32H723VGT_Test_USB_OTG_HS_v1.0/Drivers/CMSIS/Include line 2554 C/C++ Problem
in expansion of macro '__SCB_DCACHE_LINE_SIZE' core_cm7.h /STM32H723VGT_Test_USB_OTG_HS_v1.0/Drivers/CMSIS/Include line 2584 C/C++ ProblemBuilding the project with this configuration resulted in a shocking list of warnings, many signaling casting issues. Checking on the files involved, I detected a function with useless content, see below:
File: //Project/USB_DEVICE/App/usbd_cdc_if.c, line 176 and following:
/**
* @brief Manage the CDC class requests
* @PAram cmd: Command code
* @PAram pbuf: Buffer containing command data (request parameters)
* @PAram length: Number of data to be sent (in bytes)
* @retval Result of the operation: USBD_OK if all operations are OK else USBD_FAIL
*/
static int8_t CDC_Control_HS(uint8_t cmd, uint8_t* pbuf, uint16_t length)
{
/* USER CODE BEGIN 10 */
switch(cmd)
{
case CDC_SEND_ENCAPSULATED_COMMAND:
break;
case CDC_GET_ENCAPSULATED_RESPONSE:
break;
case CDC_SET_COMM_FEATURE:
break;
case CDC_GET_COMM_FEATURE:
break;
case CDC_CLEAR_COMM_FEATURE:
break;
/*******************************************************************************/
/* Line Coding Structure */
/*-----------------------------------------------------------------------------*/
/* Offset | Field | Size | Value | Description */
/* 0 | dwDTERate | 4 | Number |Data terminal rate, in bits per second*/
/* 4 | bCharFormat | 1 | Number | Stop bits */
/* 0 - 1 Stop bit */
/* 1 - 1.5 Stop bits */
/* 2 - 2 Stop bits */
/* 5 | bParityType | 1 | Number | Parity */
/* 0 - None */
/* 1 - Odd */
/* 2 - Even */
/* 3 - Mark */
/* 4 - Space */
/* 6 | bDataBits | 1 | Number Data bits (5, 6, 7, 8 or 16). */
/*******************************************************************************/
case CDC_SET_LINE_CODING:
break;
case CDC_GET_LINE_CODING:
break;
case CDC_SET_CONTROL_LINE_STATE:
break;
case CDC_SEND_BREAK:
break;
default:
break;
}
return (USBD_OK);
/* USER CODE END 10 */
}When I tried to trace the file in the repository, I only could find a similar filename with 'Template' added to its name. I guess the "Generate Project" routine uses this template to generate a version of 'usbd_cdc_if.c' for the specific processor and the edit-script is corrupted.
All these things together are to much for a beginning engineer, so I have two questions:
- are there more experienced members of this forum who can advice me how to tackle my problem (and want to do so)
- is there an employee of STM who feels him- or herself obliged to take my complaints on documentation serious enough to initiate a large cleanup of the naming of Registers?
I find it ridiculous that a user must guess what Register name is needed to show its value in the 'Live Expressions' column of the Debugger. On top of that: in the Debugger column 'SFR' all peripherals are listed with the abilty to expand their name to their various registers. However, theses names are NOT usable in the 'Live Expressions' column!!!
Thanks for your attention,
many greetings, Fred Schimmel
1 ACCEPTED SOLUTION
Accepted Solutions
Hi,
(i was on holidays... :) )
+ did you enable the built in debug messages ? Maybe its helping...
in Cube : USB settings ->
Hi,
(i was on holidays... :) )
+ did you enable the built in debug messages ? Maybe its helping...
in Cube : USB settings ->
Hi Fred,
thanks for the flowers... :)
the extra serial is in the ST-Link V3 , on its pins: VCP tx/rx , here for mini E , i have :
and on H7 - any uart, i used uart3 , set to 3Mbit ;
nice on separate serial: you can see your "debug" or info messages without starting debug, even on connecting to a running machine, connect to the serial pins, just open terminal - and you see , what it tells.
In main needs only a simple call, to send both, always. So SWD with profiling etc in debug, and just the messages, you want to send all time, you connect to the serial rx/tx . (in user code area, so re-generate code changes nothing.)
/* USER CODE BEGIN 4 */
int __io_putchar(int ch)
{
ITM_SendChar(ch);
HAL_UART_Transmit(&huart3, (uint8_t *)&ch, 1, 0xFF);
return (ch);
}
/* USER CODE END 4 */
printf(...) gives you some info then, needs not much time , because both serials in Mbit range.
