2024-08-21 12:06 PM
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++ Problem
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:
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
Solved! Go to Solution.
2024-09-23 11:15 AM
Hi,
(i was on holidays...
+ did you enable the built in debug messages ? Maybe its helping...
in Cube : USB settings ->
2024-08-21 01:24 PM
Hi Fred,
First: you cannot debug a running USB connection, because it has a fixed timing and the moment you stop it, to see what it's doing - it's over, some timeout hits and nothing working anymore.
So you can: enable debug messages, to get some info what's going on, or use a tool, to record the running USB transfer and see what happens.
But never stop it by debug and expect it to run on then.
And if you setup the USB correctly, it will work, no need to look at some registers.
2024-08-22 03:27 AM
Hallo AScha.3,
Thank you for your quick and useful response. I never thought about your reasoning, which makes sense. And I assume the debug cases I ended in the endless 'HardFault_Error' loop are caused by this.
A related question: is it possible to verify the procedure to establish a VCP connection by the Debugger? Or is this based on interrupts with timeout as well? I thought about starting the project without a connection with my desktop, plug the USB cable in and follow the executed statements.
What do you think about my observation of the function 'CDC_Control_HS(...)' I reported? In my opinion this function is required to create a VCP connection. Will this be the cause (or a part of it) of my failure to get a VCP? And next: where does this error come from and how do I get gid of it? Will it require a fresh install of my STM32CubeIDE as a whole or is it possible to replace a subset of the package?
Anyway, it is nice to find out someone else is willing to give support,
thank you for that,
Fred Schimmel
2024-09-23 10:28 AM
Hi @FredS
USB communication is time sensitive. Instead of halting the processor, use debug messages or a USB analyzer to monitor traffic.
Did you try to follow example provided https://github.com/STMicroelectronics/STM32CubeH7/blob/44df45f4dbbba971e9258fb961d77fc6a6f80154/Projects/STM32H743I-EVAL/Applications/USB_Device/CDC_Standalone/Src/usbd_cdc_interface.c#L155
To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.
2024-09-23 11:15 AM
Hi,
(i was on holidays...
+ did you enable the built in debug messages ? Maybe its helping...
in Cube : USB settings ->
2024-09-23 12:00 PM
Any attempt to send data to host is in vain, unless the enumeration works successfully and a program on the host reads from the VCP device.
Debugging USB by prints/traces is tricky exactly because time sensitiveness. Debug output must be very fast. This is a challenge by itself for a beginner.
Warnings: newer GCC compiler versions produce more warnings and they are enabled by default. Since this is not your code and you have no clue why the warnings, just disable them for now (but note for later).
> WeAct-3.0 STM32H723 board
This is not a ST board, so try to reach them. May be a board specific issue. If you don't see at least an "unrecognized device" in Windows - there's a basic electrical problem.
2024-09-24 04:06 AM
Hallo Ascha.3 and Pavel A.,
Many thanks for your attention and assistance, I really appreciate there are people who are willing to help less experienced users to overcome their problems.
I was not aware of the possibility to modify the Debug level for USB in the configuration window of an USB -Device. I certainly will keep it in mind. And I learned it is not possible to debug an USB connection problem because of strict timing requirements, very helpful to know. Triggered by the two recent reponses on my help request, I tried once more to get USB_OTG running on my WeAct H723VG board.
I created a new project, configured the available crystal oscillators, than the 'Clock Configuration window' and ran the Device Tool Generator to let CUBEIDE generate the needed source-files. I added a USB_OTG 'Device only' to my project, and specified an 'USB_Device'. Now I generated the project code and uploaded it on my WeAct board. This time I saw an "unrecognized device" in my Windows Device Manager, a big difference with the past.
The error appeared to be caused by a wrong Clock Frequency for USB in the MCU. After I changed it to 50MHz all worked as intended. I'm happy about this conclusion, because the form-factor of the WeAct board is a lot smaller than the Nucleo--H723, so easier to incorporate in my project.
Once more, thank you both for your help,
good luck with your onw projects,
Fred
2024-09-24 04:53 AM - edited 2024-09-24 06:47 AM
Hi Fred,
btw. >After I changed it to 50MHz <
USB needs exactly 48.000 MHz ! + coming from a good clock, usually crystal (+ PLL , if needed) !
Otherwise ...no fun with USB .
+
To see the messages, you need serial connection: can use a separate RX/TX to an ST-Link V3 , that has extra serial (and see in terminal or in IDE console -> serial term.), or SWO , to view SWD data and debug messages.
On WeAct board i made the connection to cpu swo pin , board didnt have it on debug connector.
Just ask, if you have problems with this.
+ I have also a board (WeAct) but with H743VG ; working fine, no problems (so far
2024-09-24 11:41 AM
Hallo Ascha.3,
Thank you for the correction. I didn't check the result after my change of the USB Clock setting (to 50MHz), I assumed the automatic solver had found a way to create the requested value. After your reply I checked it; the solver has changed my 50 to 48MHz automatically! This explains why I got a working project.
>To see the messages, you need serial connection: can use a separate RX/TX to an ST-Link V3 , that has extra serial (and see in terminal or in IDE console -> serial term.), or SWO , to view SWD data and debug messages.<
I don't understand how you create an additional serial connection via the ST-Link V3. I made myself a cable to connect my ST-Link to the WeAct board, with an extra wire from ST-Link pin 13 to H723 pin B3 (Trace SWO), just like you did.
You can be sure I note your name in my administration as guru with experience with WeAct H7xx boards.
Thank you once more for sharing your knowledge,
greetings from Holland,
Fred
2024-09-24 02:02 PM - edited 2024-09-24 02:03 PM
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.