stlink clone support #62

Closed
rene-dev opened this Issue Jan 9, 2015 · 16 comments

Projects

None yet

9 participants

@rene-dev
rene-dev commented Jan 9, 2015

I am wondering if it works on these cheap stlink clones:
http://www.ebay.com/itm/ST-Link-V2-mini-Emulator-Downloader-Programming-Unit-Random-Color-STM8-STM32/251609973875
they have an stm32f101 inside.

Rene

@gsmcmullin
Contributor

Hi Rene

Without knowing exactly what is in the clone it's hard to say. The
authentic st-link is an stm32f103 which has USB, the f101 does not have. I
don't know how they would make an st-link clone without USB. The best I
can suggest it to get one and try it out. No guarantee it works though.

Cheers,
Gareth

On Fri, Jan 9, 2015 at 11:59 PM, Rene Hopf notifications@github.com wrote:

I am wondering if it works on these cheap stlink clones:

http://www.ebay.com/itm/ST-Link-V2-mini-Emulator-Downloader-Programming-Unit-Random-Color-STM8-STM32/251609973875
they have an stm32f101 inside.

Rene

Reply to this email directly or view it on GitHub
#62.

Black Sphere Technologies Ltd.

Web: www.blacksphere.co.nz
Mobile: +64 27 777 2182
Tel: +64 9 478 8885
Skype: gareth.mcmullin
LinkedIn: http://nz.linkedin.com/in/gsmcmullin

@themadinventor
Contributor

I actually ordered two of those and they arrived today. They contain a STM32F101CBT6 (128 kB flash, not too bad), and as gsmcmullin said, have officially no USB support.
I initially thought that the chinese had implemented bitbanged USB, but some google-fu turned up this http://bbs.21ic.com/icview-107887-1-1.html (chinese), that indicates that the 101 chip is (more or less) identical to the 103 and actually has USB support, though it is not tested and might be out of spec.

TL;DR It might actually be fully compatible.
I'll do some more research and return when I find out anything more.

@rene-dev

I started drawing a schematic.
screen shot 2015-01-26 at 21 03 20

@themadinventor
Contributor

I can now confirm that the stlink version of blackmagic works out of the box on this device (tested against 1b2cd54, i.e latest). I flashed it using openocd and another stlink through the test pads.

@rene-dev

wow.
Is it just responding on the usb, or do the swd header pins even match up and debugging works?

@themadinventor
Contributor

It seems to work all the way, I connected to another stm32f101 and it behaved as expected. I did a quick compare of your schematic against this one http://www.micromouseonline.com/wp/wp-content/uploads/2014/01/mini-st-link-v2.png and things line up :).
I have no idea where the BMP's debug UART gets pinmapped, but perhaps the SWIM pin should be repurposed as UART Rx instead of serial trace input; a debug UART is easier to use than tracing imho.

@gsmcmullin gsmcmullin closed this Mar 6, 2015
@dm13dv1b

Hi! Would you please help me? I have this chinese stlinkv2 but it does not work w/ openocd. It fails when I try to flash.

@denis-fr

I have the same st-link clone (same date on pcb) and was able to flash it with modified code.
I do it because last revision (f4eda28) generate to big binary and also this clone does not have exactly the same hardware than original st-link V2.
Pin PC 13 is unconnected (pulled low in original). This make the software not correctly identify the version. With incorrect identification, the led is off.

@milkpirate
milkpirate commented Dec 16, 2016 edited

Hey,

first of all I am damn new to STM32 and BMP so please be forgiving if I ask obvious questions. So I managed it to flash a CH ST-Link v2 clone, like above, with the latest (gd6e2977) BMP firmware. Works like a charm:

lenny@ubuntu14:[~/mcu/stm32/blackmagic/scripts]$ arm-none-eabi-gdb
GNU gdb (GNU Tools for ARM Embedded Processors) 7.8.0.20150604-cvs
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=x86_64-unknown-linux-gnu --target=arm-none-eabi".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word".
(gdb) target extended-remote /dev/ttyACM1
Remote debugging using /dev/ttyACM1
(gdb) monitor swdp_scan
Target voltage: unknown
Available Targets:
No. Att Driver
 1      STM32F3
(gdb) attach 1
Attaching to Remote target
0xfffffffe in ?? ()
(gdb) quit
A debugging session is active.

        Inferior 1 [Remote target] will be detached.

Quit anyway? (y or n) y
Detaching from program: , Remote target
lenny@ubuntu14:[~/mcu/stm32/blackmagic/scripts]$

As you see, the prob's UARTs were mapped to /dev/ttyACM1 and /dev/ttyACM2. Now to my problem:

lenny@ubuntu14:[~/mcu/stm32/blackmagic/scripts]$ arm-none-eabi-gdb
GNU gdb (GNU Tools for ARM Embedded Processors) 7.8.0.20150604-cvs
....
Type "apropos word" to search for commands related to "word".
(gdb) source hexprog.py -d /dev/ttyACM1 ../../maple_mini_boot20.bin
hexprog.py -d /dev/ttyACM1 ../../maple_mini_boot20.bin: No such file or directory.
(gdb)

File to flash exists and is reachable. To me it seems to relate to denis-fr's comment but I might be wrong and I'm missed something...

@esden
Contributor
esden commented Dec 16, 2016

hexprog.py is not a gdb command. It is supposed to be used on the command line.

@gsmcmullin
Contributor

Hi @milkpirate. It looks like everything is working fine.

The hexprog.py script is not intended to be run from inside GDB. It also requires an intel hex file.

To load a hex file from gdb, do:

load file.hex

To load a binary file from gdb, do:

restore ../../maple_mini_boot20.bin binary <address>
@milkpirate
milkpirate commented Dec 16, 2016 edited

Hey,

@esden: Yes I know, but source is.
@gsmcmullin: Ahh right. I converted the binary file to Intel HEX. Dont know why I havent tried that earlier. Then hexprog.py runs smoothly:

Black Magic Probe -- Target Production Programming Tool -- version 1.0
Copyright (C) 2011  Black Sphere Technologies
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

Black Magic Probe (Firmware v1.6-rc0-257-gd6e2977) (Hardware Version 0)
Copyright (C) 2015  Black Sphere Technologies Ltd.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

Target device scan:
Target voltage: unknown
Available Targets:
No. Att Driver
 1      STM32F3

Attaching to target 1.
FLASH memory -- Offset: 0x8000000  BlockSize:0x800

Programming target
Flash write failed! Is device protected?

So the next step was to add an -r which lead to:

...
Attaching to target 1.
Removing device protection.
Traceback (most recent call last):
  File "blackmagic/scripts/hexprog.py", line 155, in <module>
    target.run_stub(stub_opterase, 0x20000000)
  File "/home/lenny/mcu/stm32/blackmagic/scripts/gdb.py", line 203, in run_stub
    regs = list(self.read_regs())
  File "/home/lenny/mcu/stm32/blackmagic/scripts/gdb.py", line 166, in read_regs
    return struct.unpack("=20L", data)
struct.error: unpack requires a string argument of length 80
lenny@ubuntu14:[~/mcu/stm32]$

The suggested gdb commands dont seem to work either:

(gdb) load maple_mini_boot20.hex
Loading section .sec1, size 0x1bd4 lma 0x0
Load failed
(gdb) restore maple_mini_boot20.bin binary 0x08000000
Restoring binary file maple_mini_boot20.bin into memory (0x8000000 to 0x8001bd4)
Writing to flash memory forbidden in this context
(gdb)
@uzi18
uzi18 commented Feb 13, 2017

@themadinventor did You find where uart debug is workin? Or not working at all?

@uzi18
uzi18 commented Feb 13, 2017 edited

look's like pin 12/13 (PA2/PA3) are UART pins and need to be connected to additional header.
Anyone could test it?

@rogerclarkmelbourne
Contributor
rogerclarkmelbourne commented Feb 14, 2017 edited

Are you sure you can use PA2 / PA3

The Stlink dongle I have, is basically like this schematic

http://www.avrki.ru/picture/articles/samodelniy_st_link_v2/shemf_st_link_v2.jpg

So PA2 and PA3 are not connected

I think to be able to use a UART on these dongles you'll need to remap UART1 onto its alternate pins of PB6 and PB7 and use the pins that are labelled as SWIM and SWIM_RST.
These connections are via resistors, but I recall trying this some time ago, and normally these low value resistors didnt seem to cause a problem.
As its only 22 ohms in series with PB6
PB7 is the worst as it has 680R and 22R in series.

You also need to make sure that PB5, and PB9 and PB10 are all floating, as PB7,9 and 10 are linked and PB5 and 6 are linked.

But other pins default to floating input so should be OK as long as they are not explicitly configured as either a UART or GPIO output.

PS. When I get time, I was going to revisit this, as I had some old code BMP code that runs on these, but I'd need to dig it out and see what I need to do in order to make it work with the revised code architecture.

PS.

I found basically the same circuit elsewhere as well. So I suspect most dongles are the same.

http://we.easyelectronics.ru/uploads/images/00/31/28/2013/05/11/3012f7.jpg

The only difference being the pin order on connector on the end of the dongle

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment