Skip to main content
eltar
eltar
Associate II
June 18, 2012
Question

ST-Link also serves as USB<->USART when not debugging

  • June 18, 2012
  • 5 replies
  • 1573 views
Posted on June 18, 2012 at 20:59

Hi to all STM guys here. Thank for all the great eval boards you do.

We just had a sparks-generating discussion on a forum from where camse an idea that we miss an interaction with PC capability on the discovery boards. I just had a look at F4 board and confirmed that there's USART2 unoccupied on STM32F103C8T6 chip. That means that it is feasible to hack the board a bit to connect an USART on the main chip with USART2 on the debugger chip. The debugger chip would serve than as both ST-Link (for debugging) and as VCP for interaction with a terminal on PC. That would greatly help to have this possibility outside of IDE.

To do so what we need is either sources of firmware of the debugger (so the community could modify it to implement the needed functionality) or the firmware with amplemented functionality from ST so we could flash that ourselves.

Please let us know if that is possible (no hardware/legal restrictions from STM side) and we can expect STM to release a solution for this problem any soon.

Many thanks in advance.

P.S. This would really kick ass to Arduino :)

#st-link #debugger #stm32-discovery
This topic has been closed for replies.

5 replies

frankmeyer9
frankmeyer9
Associate III
June 18, 2012
Posted on June 18, 2012 at 21:30

This forum is quite rarely monitored by ST guys, I hope they find the flowers ... ;)

Please let us know if that is possible (no hardware/legal restrictions from STM side) and we can expect STM to release a solution for this problem any soon.

I know there is an

http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=101700&start=0&postdays=0&postorder=asc&highlight=

around (or better a hack), which turns the STLink into an OCD. It is based on STLink-V1 (STM32VLDiscovery).

Maybe you can use this as starting point ...

For the original firmware/source code, you might ask ST directly.

eltar
eltarAuthor
Associate II
June 18, 2012
Posted on June 18, 2012 at 22:00

I actually got a reply from Thierry on another thread about TCL library the other day. SO let's wait.

Meanwhile I soldered a few wires to my STMF0 Discovery and connected by STMF4 Discovery and ST-Link utility. Here's what I got:

23:53:28 : Old ST-LINK firmware detected!

                  Please upgrade it from ST-LINK->'Firmware update' menu.

23:53:28 : Connected via SWD.

23:53:28 : Device ID:0x410 

23:53:28 : Device family :STM32F10xxx Medium-density device

23:53:28 : Cannot read memory!

                  Disable Read Out Protection and retry.

So my guess is I can connect and flash the stm 32 onboard. I'm however somewhat bad at programming, which does not stop me from trying, right? So I'll have a look at you link. However I already feel pessimistic as I tried to study about OCD a bit a few months back and I din't manage to go through all the info. Maybe this attempt will help.

Thanks!

eltar
eltarAuthor
Associate II
June 18, 2012
Posted on June 19, 2012 at 00:54

I would strengthen my request after I saw that on F4Discovery there's UART1 of target MCU is hardware-connected with SD14-15 to debugger MCU. So if there's an ST-Link firware driver that creates a virtual comport it will be easy to interact with PC with zero hw modification. ST, pleaaaaaaaaseeeeeeeeee. Just update ST-Link v2 firmware

dannym
dannym
Associate III
June 27, 2012
Posted on June 27, 2012 at 21:34

Well I'm not sure if that's a good idea.  AFAIK, the bootloader and debugger on the STM32F4 Discovery uses that UART, and that's why it's there.

If we start sending another data stream through that UART, at the very least, debug couldn't function.  Debug would have to be disabled to even get to that point.

Even if you can keep the bootloader, there's a problem getting it to coincide with the programming.  That is, you'll need to disable whatever PC software using it as a COM port before programming to avoid a conflict of the usage of the port.  More likely I'd expect a conflict where the host PC can't decide if it's a STMLink/V2 or a Virtual COM Port when plugged in, because the devID has two conflicting drivers for it.  Unless you rewrite the DevID and make it really hard to reprogram or debug the board again.

Torsten Jaekel
Torsten Jaekel
Associate III
March 5, 2014
Posted on March 05, 2014 at 09:21

FYI,

I have the STMF4 Discovery working with UART VCD as well as as an USB Audio Sound Card on PC.

The firmware (project) can be found here: www.tjaekel.com

Best regards

Torsten

Terms & ConditionsAccessibility statement