Why can't I get USB TX to work on my Nucleo board?

[JMatu.1]

I am new to the ST world and have a Nucleo-H7A3ZI that I am testing with. I have STM32CubeIDE setup and have an LED toggling, so I am comfortable that I have the toolset configured properly.

My next step was to send some characters over USB to the host. Once that is working, I am going to send from the host and echo them back to see both directions working. But I cannot get the Nucleo to transmit anything....

I setup the connectivity for the Internal FS Phy to be "Device_Only". I tried Activate-VBUS both enabled and disabled. In middleware I setup the HS class as CDC and generated the code.

Then in my main.c I:

1 -

#include "usbd_cdc_if.h"

2 -

 /* USER CODE BEGIN 2 */
 HAL_Delay(1000);
 /* USER CODE END 2 */
 
 /* Infinite loop */
 /* USER CODE BEGIN WHILE */
 while (1)
 {
 /* USER CODE END WHILE */
 
 /* USER CODE BEGIN 3 */
	 CDC_Transmit_HS(buffer, sizeof(buffer));
	 HAL_Delay(1000);
 }

No dice. I've done a few other things where people recommended adjusting a case statement in usbd_cdc_if.c, etc. But nothing seems to matter. No matter what I do, I get USBD_BUSY in the CDC_Transmit_HS function.

What am I missing? I am sure it is something silly.

[TDK]

CDC_Transmit_HS returns busy if the previous call is not yet complete. Does your computer correctly detect the device? Are you able to open the serial port in a terminal program of some sort?

The HAL USB support is not awesome, in general.

There are some USB examples in the cube repository, but nothing for the H7A board yet, presumably since it's so new.

https://github.com/STMicroelectronics/STM32CubeH7/tree/master/Projects/STM32H7B3I-EVAL/Applications/USB_Device

There are some examples for the H7A board in the cube repository. No CDC applications, though.

https://github.com/STMicroelectronics/STM32CubeH7/tree/master/Projects/NUCLEO-H7A3ZI-Q/Applications/USB_Device

[JMatu.1]

OK, that makes sense, thank you. I added in some delays (as some people were pointing out that the command could occur too quick after initialization, but no dice. Thanks, I went through those apps as well, but since I couldn't find something CDC that was anywhere close to what I would want to do, I had to give up on them.

Late on FRI I realized that the USB port I //should// be using is different from the one supplying power and is used for debugging. It makes sense, but I stupidly hadn't thought about it. That port does not seem to be recognized by my Win10 laptop. Even though the ST site says the default drivers should be fine, they definitely aren't for me. I've found a lot of other people with the same issue, but none of their fixes worked for me. I am going to try to connect to my personal Linux laptop today to see if that makes a difference.

What worries me though is if that works. If it works, it means that I have no solution for connecting to a W10 machine, and that is what the customer is ultimately going to want to do. In the end the board will be a custom PCB, so I assume that if I use a known good FTDI chip (or something of that ilk), I won't have the same issues, but it doesn't give me a warm and fuzzy (especially for demoing to the customer).

[JMatu.1]

Yikes! I plugged it into my Ubuntu 20.04 laptop and it caused all sort of issues. This is a very off USB front end.....

[TDK]

> Late on FRI I realized that the USB port I //should// be using is different from the one supplying power and is used for debugging.

There are two USB ports. One is used by the ST-Link to debug/program the chip. The other one is connected to the target chip. That's the one you need to use.

> Even though the ST site says the default drivers should be fine, they definitely aren't for me.

Could be that the drivers are fine but the code is not. Unfortunately it's a common issue with USB code here. Would be nice if ST provided more/better examples.

[JMatu.1]

Yeah, it is a little frustrating just trying to get a simple echo working and it is failing so badly. If I could, Does this seem like the proper steps?

1 - Plug in the ST-Link USB cable

2 - Debug-as STM32 blah blah blah

3 - Hit run

4 - plug in the VCOM cable

I really hoped that that CDC_GET_LINE_CODING/CDC_SET_LINE_CODING would do the trick, but nada. This is my 3rd day working on it, if it doesn't work by COB, I am not sure where to take it from here.....

I appreciate the clarifications.