Help deciphering the STM32F072 USB CDC example

[Oliver Sedlacek]

I've got the USB CDC VCOM standalone example compiled and running from https://github.com/STMicroelectronics/STM32CubeF0/tree/master/Projects/STM32072B_EVAL/Applications/USB_Device/CDC_Standalone

The documentation has some noteable gaps, some of which would be obvious if the CubeMX project file were available.

The example is a "USB to UART bridge" application, which is not really how most use would use the STM32F072 as a USB CDC end point. Certainly I want to parse the incoming characters to make my system do something. The example just plumbs bytes to a UART, and the way the code is structured there's no visibility of execution flow. What I've discovered is:

1. The 'UART' plumbed to the USB VCP is USART2, based on the fact that it's the only one enabled.

2. USART2 RXD and TXD aren't routed to any pins, PD6 and PD5 don't count as they don't exist on 64 pin package.

[TDK]

Most examples aren't generated from CubeMX, hence the lack of an IOC file.

Characters are received in CDC_Itf_Receive one packet at a time. In your implementation, replace the contents of that function with what you want to do with the data, such as put it into a buffer which is then read in the main loop, or parse it there, or whatever.

[Oliver Sedlacek]

This code seems insane to me. The call stack shows the USART being configured from inside an ISR, which is no way to create a responsive and reliable system.

Anyway, I figured I need to move to USART1 on GPIO PA9-10 and tried it like that. No joy, no activity when I type on the terminal.

What event can I breakpoint on when the micro receives a USB packet? Maybe then I can step through and figure out how it's supposed to work.

[tjaekel]

Just some comments how USB CDC (often also called USB VCP) works:

• there is not a real UART device/peripheral involved: no need to initialize a UART2 (there is no UART on MCU side)
• after USB stack is initialized and the "USB enumeration works" properly - you should see now a new UART device on Windows Device Manager (something with VCP, STM, or also a UART COM which is not there if MCU is disconnect/hold in reset)
• This is you UART COM port: all the UART traffic is now received by the MCU in the USB stack: you have to find where the USB UART characters come in and how to send via USB UART.
  All inside the USB functions, nothing related to a "real" UART (and no need to do anything for a "real" UART).
• And bear in mind: a USB VCP (CDC) packet coming in, or sending out (to host) can have up to 64 characters. When you "copy and paste" a string in UART terminal (e.g. TeraTerm) - you could get up to 64 characters as "one shot"
• The baudrate, when you open Terminal (TeraTerm), usually does not matter: any baudrate is fine and it anyway set by the USB speed (e.g. FS or HS).
  But there might be code to act on UART configuration, e.g. to set the bits per bytes (actually also getting a baudrate request), parity etc. Myself: I do not use and let it run with the defaults.

My suggestion:

Check, if you get the USB enumeration working (a "USB ding" sound on Windows), if you see a new COM port in Device Manager. If so: pretty great: now the USB UART is actually established.

Now you can check on which function you will be notified (in MCU FW) that something was received, actually in which buffer the received characters are stored (it should be done "automatically" to store the received bytes, by the USB stack).

Just find the hooks (functions and buffers) where the USB UART traffic is going.

[Oliver Sedlacek]

Thanks. USB enumeration seems to be working because Windows shows a COM port in the device manager.

The example configures the STM32F072 as a 'USB to UART' bridge, so the readme.txt says that traffic is routed to and from a USART peripheral, so yes, a real UART is involved. Although the VCP doesn't care about bit rate etc, these settings are processed and applied to the USART peripheral.

My question comes back to your last point, finding the hooks and the callback functions that get fired by traffic. The buffers are easy, they are documented in the readme.txt. A reference search by name for the buffer shows where the buffers are passed into initialisation code, so after that the code uses some private pointer.

Breakpointing on the ISR, all I see is SOF activity. The search for the hooks goes on.

Oliver

[Pavel A.]

> What event can I breakpoint on when the micro receives a USB packet? Maybe then I can step through

@Oliver Sedlacek I'm not familiar with this specific example, just a note: breakpoints and stepping through USB device code won't work because the USB link is time sensitive. The host expect real time response, a delay may cause device reset and re-enumeration. You can set a breakpoint to find whether execution runs to certain point but it will be hit only once. 

For a supported, production quality USB device library look somewhere else.

 

[Oliver Sedlacek]

Yes, I know that USB may crash if you breakpoint. I've got to start somewhere though. :(

[Oliver Sedlacek]

After looking at properties in devcie manager I'm wondering what this means.

 

I've run the installer downloaded from ST, so that's not it. Windows can't find a better driver.

[tjaekel]

This does not mean so much: as long as the VCP COM port driver is happy - it should work.

BTW:
which Middleware stack do you run? (the "old" STM stuff or the new one with AZURE RTOS and ACM drivers)?

I can look into my project: I have USB VCP UART working on many projects, since years.

Also asking:
Are we talking about a USB VCP UART implemented in MCU FW, used via the USR USB connector?
Or are you talking about the USB VCP UART which is provided via the ST-LINK debgger?

The first one does not need any "real" UART device, all as USB only.
The second on is a VCP UART but on the ST-LINK chip: it is forwarded as a regular UART: here you need a real UART (e.g. UART1, see the schematics).

When it comes to USR USB VCP UART - I can check in my projects where to check if characters come in.
BTW: you can use breakpoints: but during the Enumeration process (when all the descriptors are sent) - it can time out. Later, when you want to see if a character entered on Host Terminal (e.g. TeraTerm) - a breakpoint should work in your MCU FW.

 

[Oliver Sedlacek]

The example is 'bare metal' as that's all I want.

Once I have the USB TX and RX working, the intent is to parse command messages from RX, process them and return a response through the TX. The example doesn't do that, it feeds USB RX to a USART TX and the USART RX to the USB TX, turning the STM32F072 into a USB to UART bridge. None of this is to do with the ST-LINK.

I've now checked that the USART is configured correctly by getting the code to explicitly send a test message and I can see that on the 'scope on the appropriate GPIO pin.

[Pavel A.]

>After looking at properties in devcie manager I'm wondering what this means.

Windows correctly detected the USB device and the usbser driver claimed it. All this looks good. Is the 206531584246 the "serial number" of your device?