Mention USART using ST-LINK (without separate USB-UART module)

[jturner314]

On PCB version C and newer of the STM32F3DISCOVERY board, the embedded ST-LINK has virtual COM port support. This means that a separate USB-UART module (such as the CH340G module mentioned in the book) is not necessary with recent boards. This is really nice because you don't need to buy the extra hardware, and you can use one less USB port.

While it may be a good idea to continue using a separate USB-UART module in the book to ensure maximum compatibility across different STM32F3DISCOVERY PCB versions, it's probably worth mentioning that this isn't necessary on recent boards that have the newer ST-LINK.

Some observations about the virtual COM port:

• The "VCP configuration" section of the STM32F3DISCOVERY user manual says that the USART pins connected to the ST-LINK are PA9 and PA10, but that's incorrect. The correct pins are PC4 and PC5 (as shown in the electrical schematic, by inspecting the board itself, and with testing).

• On my Linux machine, the serial port is connected as /dev/ttyACM0.

• I see a lot less noise in ADC measurements when I use the USART support in the ST-LINK than when I use a separate USB-UART module. This could be a result of my cheap USB-UART module, but it may also be true for higher-quality modules.

• The solder bridges for connecting the USART pins to the ST-LINK are SB13 and SB15. They were already connected on my board, and the user manual says that they should be connected for PCB version C and newer, but it's probably worth suggesting that the user check that the bridges are connected. (In fact, this might be a good way to determine the PCB version you have, because these solder bridges were not connected on PCBs before version C.)

By the way, many thanks for writing the Discovery book! It's what got me started with embedded Rust development.

[JoshMcguigan]

Thanks for posting this. I did not purchase the CH340G module, but I do have version C of the STM32F3DISCOVERY board (at least I can confirm SB13 and SB15 are connected).

Is anything else required to enable the virtual COM port support on the board? I'm on OSX, and I don't think I am able to see the port. The output of ls /dev/cu.* is listed below. I've tried testing as described in chapter 11.1 (https://japaric.github.io/discovery/11-usart/send-a-single-byte.html) using both of the devices listed below, and in both cases I don't see any activity on my minicom screen starting the test program with cargo run and entering continue in GDB.

$ ls /dev/cu.*
/dev/cu.Bluetooth-Incoming-Port	/dev/cu.SOC
/dev/cu.MALS			/dev/cu.usbmodem14513

Do you know of any other setup or troubleshooting steps I can try?

[jturner314]

I forgot to mention that I've been able to get this to work only if I've started openocd while the device is connected. It seems to work if I start openocd and then access the serial port; or start openocd, kill openocd, and then try to access the serial port. So openocd doesn't have to be running in my experience, but it has to run at least once while the device is connected (maybe to initialize the ST-LINK or something). By the way, the openocd command I'm using is openocd -f interface/stlink-v2-1.cfg -f target/stm32f3x.cfg.

The devices that show up when I plug the STM32F3DISCOVERY board into my Linux laptop via USB are the following: /dev/serial, /dev/sdc, /dev/sg2, and /dev/ttyACM0. The one that's worked for serial communication is /dev/ttyACM0. Unfortunately, I don't have access to a Mac to test with.

I'd recommend the following. (You've probably already done most of these things, but just in case, I'll mention them.)

1. Make sure you're attaching the USB cable to the ST-LINK USB port on the STM32F3DISCOVERY, not the USER USB port.
2. Does OS X allow you to observe the kernel logs/messages? If so, make sure that it's recognizing the STM32F3DISCOVERY board. The kernel logs/messages may even tell you what device file the kernel has created for the serial port. You could also try OS X's equivalent of lsusb to make sure that the board is recognized.
3. Observe which devices appear when you plug the STM32F3DISCOVERY into your computer for the first time after it's been restarted. (Restart your computer, save the list of devices with ls /dev > ~/devices_before, plug in the STM32F3DISCOVERY, then save the new list of devices with ls /dev > ~/devices_after, then compare with diff ~/devices_before ~/devices_after.) I would assume that one of the new devices would be the serial device.
4. Make sure you've configured minicom according to the book.
5. Start openocd with openocd -f interface/stlink-v2-1.cfg -f target/stm32f3x.cfg and make sure the LED on the STM32F3DISCOVERY starts changing colors.
6. Try connecting to the board with minicom again (while openocd is running).
7. Restart your computer and try again.

You could also try stepping through the test program with gdb to possibly get a better idea of what's happening.

Edit: As a side note, unrelated to getting serial working for the first time, one issue I've noticed is that the Linux kernel does not reliably flush the serial device when tcflush is called. If your OS has this issue, it's important to keep in mind while writing software to communicate over serial, because even if you reset the STM32F3DISCOVERY and try to flush the serial device with tcflush, there may still be a few bytes remaining in the OS's buffer. The only reliable way I've found to flush the buffer of the serial device file is to unplug the STM32F3DISCOVERY from my computer and plug it in again. (This destroys and recreates the serial device file.)

[JoshMcguigan]

$ diff disconnected.txt connected.txt 
17a18
> cu.usbmodem14513
25a27
> disk2
180a183
> rdisk2
189a193
> tty.usbmodem14513

disk2 and rdisk2 both return permission denied when trying to connect with minicom. cu.usbmodem14513 and tty.usbmodem14513 don't show any data in minicom after running the test program with cargo run and then continue. I am connecting through a USB-C to USB-A converter, so I'm not sure if that could be complicating things.

[jturner314]

Based on a couple of articles talking about the ST-LINK "Virtual COM" feature [1] [2], the device name on a Mac would be /dev/tty.usbmodem*, so it's probably the /dev/tty.usbmodem14513 device for your hardware. It's worth trying the /dev/cu.usbmodem14513 device, though, if the other one doesn't work.

I just realized the most probable reason why the chapter 11 example isn't working for you, though. As I mentioned in my first comment on this issue, the pins on the STM32F3 microcontroller that are connected to the ST-LINK for USART are pins PC4 and PC5. However, the pins used in the chapter 11 example of the book are PA9 and PA10. So, you need to change the example to use the pins connected to the ST-LINK. I think this will work. The other examples in the book using USART need to be changed too in order to use the pins connected to the ST-LINK.

Don't forget to start openocd as I described in my previous comment, or the serial port won't work. (I've done that a few times.)

[JoshMcguigan]

Switching out the pins as shown in your fork worked!

Thanks for the help. I think this information would be a great addition to the Discovery book.

[jturner314]

Yay! Which device file ended up working? (Was it /dev/tty.usbmodem14513?)

[JoshMcguigan]

Yes, it was /dev/tty.usbmodem14513

[JoshMcguigan]

By the way, I just noticed that the latest version of the user manual has corrected the pinouts to PC4 & PC5 as you listed above. The revision history says it was fixed 5 days after your original post.

https://www.st.com/content/ccc/resource/technical/document/user_manual/8a/56/97/63/8d/56/41/73/DM00063382.pdf/files/DM00063382.pdf/jcr:content/translations/en.DM00063382.pdf

[japaric]

Oh, nice! I recall reading long time ago somewhere in the ST docs that the ST-Link built into the F3 can't operate in virtual COM mode and in debugger mode at the same time so I never bothered trying this out. But I just tested out the virtual COM within a GDB ession and it just worked!

It definitively makes sense to update the book to use PC4 / PC5 instead of PA9 / PA10 then the user can choose between the virtual COM and a USB-UART converter depending on the revision they have.

I believe that a quick test to check if virtual COM will work for you without checking the revision printed on the board or checking the solder bridges would be to short PC4 and PC5 using a jumper wire, open minimcom /dev/ttyACM0, type some characters and see if the chars get echoed back. (Haven't tested this myself).

The revision history says it was fixed 5 days after your original post.

Curious. Maybe some ST employees are subscribed to this repo. 👋

[japaric]

For those watching this issue. I have put up a PR (#148) to update the text and recommend using the Virtual COM.

[therealprof]

@japaric It was just noticed that the PR is not merged due to the removal of the image which we'd like to keep. Any chance of getting that addressed?

[7sDream]

Hello @jturner314 and @JoshMcguigan,

Sorry for creat new post in a closed issue. I just meet some trouble when read the serial communication section. And after some search I found this issue, which have some discussions on PCB version macOS enviroment, which close to my problem. So I took the liberty to ask some questions here.

I just bought a board of PCB version D-01:

But when I plug it in my MacBook Pro labtop, I can't find any device name start with tty.(also tried after running openocd):

I notice SB13 and SB15 bridge of my board is little strange. It looks like there is solder on it, but the break of > shape still remain on it

Does this mean I bought a fake? Or is this actually a frequent occurrence, I only need to re-soldering by myself?

Thank you!

[jturner314]

I don't have my board with me, but from memory, it looks very similar to your pictures, so I doubt yours is a fake. Maybe it's a manufacturing defect? According to the docs, SB13 and SB15 should be connected on PCB versions C and later. If you want to use the ST-LINK USART functionality, you'll need to make those connections somehow. I'd suggest just soldering the bridges yourself (maybe using a 0Ω SMD resistor or a short segment of stripped wire to help bridge the gap). Alternatively, you could solder header pins to the pads labeled TX and RX, and then use jumpers to connect TX to PC5 and RX to PC4.

[7sDream]

@jturner314

OK, I will try to solder those bridge on next weekend and see if I can find the virtual COM device.

Thank you for your information and suggestions.