Author Topic: Stupid USART question on STM32F030R8 Nucleo board (Read 6883 times)

thormj · « **on:** August 02, 2016, 07:03:04 pm »

So I've tried using the mbed web compiler and their demo and I get nothing.
I've tried my own C code on USART2 (which the STM32Cube complains that it shares the lines with SWD, but it doesn't, afaict). And I still get nothing (Com23, 9600 8-n-1 using teraterm).

Do I need to enable the vcp somehow?
I can step through the code and it all seems to work (not sure how to tell Keil to use the serial port, but I'll deal with that later), but I get no output (the LED is blinking at a slower pace, so I know the mbed code downloaded)...

The SB13&14 are connected (as from Digikey).

MosherIV · « **Reply #1 on:** August 02, 2016, 07:07:04 pm »

From the sound of it, you have connected 3.3V gpio to 12V RS232.

Do not worry, I have done that before and the micro survived.
You need a RS232 level convertor like a MAX232.
(Assuming your code is not at fault)

void_error · « **Reply #2 on:** August 02, 2016, 07:17:12 pm »

Quote from: MosherIV on August 02, 2016, 07:07:04 pm

You need a RS232 level convertor like a MAX232.
(Assuming your code is not at fault)

In case of a 3.3V supply there's the MAX3232 which works with both 3.3V & 5V.

richardman · « **Reply #3 on:** August 02, 2016, 11:16:00 pm »

VCP on USART2 should "just work" without any extra hardware or software once the ST driver is installed. I don't use mBed or Keil so do not know the specific, but surely the mbed forum have some help or answers?

ebclr · « **Reply #4 on:** August 02, 2016, 11:58:03 pm »

1st )Check if the board appear on windows

ebclr · « **Reply #5 on:** August 03, 2016, 01:32:36 am »

If you are using Windows 10, try on another machine with a older windows, maybe is a windows 10 driver issue.

ebclr · « **Reply #6 on:** August 03, 2016, 01:47:29 am »

Go to the ST web page

https://my.st.com/content/my_st_com/en/products/embedded-software/development-tool-software/stsw-link004.license%3d1470188094990.html

And get the lateste Stlink STSW-LINK004

Do a firmware upgrade on your board

after that, things must be ok and serila will work

MosherIV · « **Reply #7 on:** August 03, 2016, 11:05:47 am »

Sorry missed the references to the VCP by the OP.

The OP indicated that they tried to initialise USART2 (a physical device that should output to GPIO pins).
The GPIO pin MUX must be configured to select USART2 to particular pins for USART2
The USART GPIO pins must now be connected to a RS232 interface device, the MAX3232.

To connect to a PC, the PC MUST has a RS232 port. A USB to RS232 adapter can be used, this must have it's own driver.

The ST VCP has nothing to do with a physical RS232 port. The ST VCP is a USB driver that emulates RS232 over USB.

Hope this clears things up a bit more.

Kilrah · « **Reply #8 on:** August 03, 2016, 12:46:14 pm »

Quote from: MosherIV on August 03, 2016, 11:05:47 am

To connect to a PC, the PC MUST has a RS232 port. A USB to RS232 adapter can be used, this must have it's own driver.

The ST VCP has nothing to do with a physical RS232 port. The ST VCP is a USB driver that emulates RS232 over USB.

No. On this board with the default bridge config USART2 of the micro is precisely connected to the ST-Link so that it feeds through the VCP.

MosherIV · « **Reply #9 on:** August 03, 2016, 01:25:02 pm »

Quote

No. On this board with the default bridge config USART2 of the micro is precisely connected to the ST-Link so that it feeds through the VCP.

In which case, ignore what I said about the RS232 interface device.

The schematic from ST is very unclear about this

The ST-Link says "STLK_TX" and "STLK_RX" but the processor page says "USART_TX" and "USART_RX" $:-\$

Personally, I have never got the ST-Link debug VCP to work.

Good luck

Jeroen3 · « **Reply #10 on:** August 03, 2016, 01:35:03 pm »

Quote from: MosherIV on August 03, 2016, 01:25:02 pm

Quote
No. On this board with the default bridge config USART2 of the micro is precisely connected to the ST-Link so that it feeds through the VCP.
Personally, I have never got the ST-Link debug VCP to work.

Me neither. After the example didn't work. I just found two other pins and connected one of those cheap ftdi boards with some jumper wire.
Instant success.

thormj · « **Reply #11 on:** August 03, 2016, 02:12:54 pm »

So I tried some more:
1. I got a different example from someone else for USART2 (using the StdPeriph drivers)...
2. I don't see a signal using an oscope of PA2 (I have it transmitting "SO" continuously...)

My next step is to write a program that just bounces all of the GPIO lines and see what that looks like on the oscope (and it should give me garbage on the VCP since I won't have the right baud rate)...

After figuring out the HAL reentrancy lock the project seemed to be clicking into place, but this is having me vexed (I'm asking at ST micro [who gave me the StdPeriph version], mbed [silent] and here)...

If anyone has a "hello world"(or SOS beacon or anything) that works with the Nucleo board) or could tell me if I'm doing something stupid with this [keil uvision 5 project; I just built this in the StdPeriph_Examples\USART\USART_Printf directory], I'd appreciate it

janoc · « **Reply #12 on:** August 03, 2016, 02:57:41 pm »

Quote from: Jeroen3 on August 03, 2016, 01:35:03 pm

Quote from: MosherIV on August 03, 2016, 01:25:02 pm
Quote
No. On this board with the default bridge config USART2 of the micro is precisely connected to the ST-Link so that it feeds through the VCP.
Personally, I have never got the ST-Link debug VCP to work.
Me neither. After the example didn't work. I just found two other pins and connected one of those cheap ftdi boards with some jumper wire.
Instant success.

I did, but the ST Link firmware needs to be updated. What they ship out of the factory has tons of bugs and problems

thormj · « **Reply #13 on:** August 03, 2016, 05:52:01 pm »

Ok, so with my Bouncy program, I see action on all PA lines *except* PA_2/PA_3 (the usart). I even desoldered the jumpers at SB13/SB14, and still no bouncing on those... I have to use the Mass Storage to reprogram afterwards. I suppose that's what I get for bouncing PA13/14...

So what's with PA2/PA3?

---
Aha! PA2/PA3 have to be brought out to the connectors using SB62 and SB63 (not made by default).
Doing that made the bouncing appear and made the serial traffic appear on the pin headers so I can watch on the oscope!

I guess VCP is a lost cause for this board -- I see the traffic on the oscope, but I do *not* see it on COM23 (STMicroelectronics STLink Virtual Com Port), even after upgrading the STLink to V2.J27.M15. On my PC (windows 7), it says the driver is version 1.1.0.0).

Has anyone gotten the VCP to work on a Nucleo board? What driver versions do you have?

ebclr · « **Reply #14 on:** August 03, 2016, 06:39:36 pm »

The example on mbed, work for sure, I guess you have a old firmware on your stlink, update that

richardman · « **Reply #15 on:** August 03, 2016, 08:42:19 pm »

I have half a dozen ST-Nucleo on my desk right now and sold 50+ as part of our kits. The VCP/USART2 works. No problem. The debug pod function is great.

I do not update the firmware on the kits that we sell. They just work, for download and debug.

richardman · « **Reply #16 on:** August 03, 2016, 08:44:26 pm »

And I have F030, F070, F103, L152, F401, F411 and even the new F746 ST-Nucleos. Never had a problem with the ST-LINK/VCP portion.

One thing I do notice is that sometimes my Win7 takes a loooooooong time before it finishes installing the driver, so watch that spinning wheel. Some boards take no time, some boards take longer. Even the same MCU ones. No idea why.

janoc · « **Reply #17 on:** August 03, 2016, 09:55:02 pm »

Quote from: richardman on August 03, 2016, 08:42:19 pm

I have half a dozen ST-Nucleo on my desk right now and sold 50+ as part of our kits. The VCP/USART2 works. No problem. The debug pod function is great.

I do not update the firmware on the kits that we sell. They just work, for download and debug.

Maybe they have fixed the firmware on the more recent boards. I have likely got one of the early STM32F042 and 32F030 Nucleos and there the firmware was iffy. Good to know it is fixed - those are certainly sweet devboards for prototyping. I like the small form factor Nucleos better than the big Discoveries - just stick it into a breadboard and code away.

ebclr · « **Reply #18 on:** August 03, 2016, 10:17:02 pm »

I just upgrade firmware for 12 different ST board, they have a problem with win10 and this upgrade is really necessary

ebclr · « **Reply #19 on:** August 03, 2016, 10:24:06 pm »

No more than 30 seconds

thormj · « **Reply #20 on:** August 04, 2016, 04:49:05 pm »

What version did you upgrade to?

ebclr · « **Reply #21 on:** August 04, 2016, 10:07:25 pm »

V2.J27.M15


EEVblog Main Site	EEVblog on Youtube	EEVblog on Twitter	EEVblog on Facebook	EEVblog on Odysee

Author Topic: Stupid USART question on STM32F030R8 Nucleo board (Read 6883 times)

Share me