New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

stlink clone support #62

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

Comments

Projects
None yet
@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

This comment has been minimized.

Show comment
Hide comment
@gsmcmullin

gsmcmullin Jan 16, 2015

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

Contributor

gsmcmullin commented Jan 16, 2015

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

This comment has been minimized.

Show comment
Hide comment
@themadinventor

themadinventor Jan 26, 2015

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.

Contributor

themadinventor commented Jan 26, 2015

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

This comment has been minimized.

Show comment
Hide comment
@rene-dev

rene-dev Jan 26, 2015

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

rene-dev commented Jan 26, 2015

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

@rene-dev

This comment has been minimized.

Show comment
Hide comment
@rene-dev

rene-dev commented Jan 26, 2015

st2

@themadinventor

This comment has been minimized.

Show comment
Hide comment
@themadinventor

themadinventor Jan 26, 2015

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.

Contributor

themadinventor commented Jan 26, 2015

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

This comment has been minimized.

Show comment
Hide comment
@rene-dev

rene-dev Jan 26, 2015

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

rene-dev commented Jan 26, 2015

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

@themadinventor

This comment has been minimized.

Show comment
Hide comment
@themadinventor

themadinventor Jan 26, 2015

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.

Contributor

themadinventor commented Jan 26, 2015

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

This comment has been minimized.

Show comment
Hide comment
@dm13dv1b

dm13dv1b Jun 20, 2015

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.

dm13dv1b commented Jun 20, 2015

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

This comment has been minimized.

Show comment
Hide comment
@denis-fr

denis-fr Jun 12, 2016

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.

denis-fr commented Jun 12, 2016

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

This comment has been minimized.

Show comment
Hide comment
@milkpirate

milkpirate Dec 16, 2016

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...

milkpirate commented Dec 16, 2016

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

This comment has been minimized.

Show comment
Hide comment
@esden

esden Dec 16, 2016

Member

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

Member

esden commented Dec 16, 2016

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

@gsmcmullin

This comment has been minimized.

Show comment
Hide comment
@gsmcmullin

gsmcmullin Dec 16, 2016

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>
Contributor

gsmcmullin commented Dec 16, 2016

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

This comment has been minimized.

Show comment
Hide comment
@milkpirate

milkpirate Dec 16, 2016

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)

milkpirate commented Dec 16, 2016

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

This comment has been minimized.

Show comment
Hide comment
@uzi18

uzi18 Feb 13, 2017

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

uzi18 commented Feb 13, 2017

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

@uzi18

This comment has been minimized.

Show comment
Hide comment
@uzi18

uzi18 Feb 13, 2017

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

uzi18 commented Feb 13, 2017

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

@rogerclarkmelbourne

This comment has been minimized.

Show comment
Hide comment
@rogerclarkmelbourne

rogerclarkmelbourne Feb 14, 2017

Contributor

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

Contributor

rogerclarkmelbourne commented Feb 14, 2017

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

@enly1

This comment has been minimized.

Show comment
Hide comment
@enly1

enly1 Apr 11, 2017

Just a heads up as I wanted to look at black magic probe as an alternative to the stlink clone I have for various reasons. I built a firmware using the patches available in the forums, but the usart RX wasn't working for some types of serial adapters.

The reason for this was that on my clone, there isn't a 680R in series with 22R, its actually a 680 pullup to 3v rail. There is however an additional ~220K resistor in series after the pullup.

The reason RX wasn't working for me was that the USB USART adapter I had included a 1K inline resistor on the TX pin, which formed a nice voltage divider with the 680R pullup, resulting in a low of around 2V.

I swapped out the 680R for a 20K on the board and logic low is now working fine.

Hope this helps someone who can't work out why RX isn't working on a clone device, but TX works fine once patched.

PS - Didn't check if I could remove it or not as wasn't sure if the PB7 pin has input pullup enabled or not.

enly1 commented Apr 11, 2017

Just a heads up as I wanted to look at black magic probe as an alternative to the stlink clone I have for various reasons. I built a firmware using the patches available in the forums, but the usart RX wasn't working for some types of serial adapters.

The reason for this was that on my clone, there isn't a 680R in series with 22R, its actually a 680 pullup to 3v rail. There is however an additional ~220K resistor in series after the pullup.

The reason RX wasn't working for me was that the USB USART adapter I had included a 1K inline resistor on the TX pin, which formed a nice voltage divider with the 680R pullup, resulting in a low of around 2V.

I swapped out the 680R for a 20K on the board and logic low is now working fine.

Hope this helps someone who can't work out why RX isn't working on a clone device, but TX works fine once patched.

PS - Didn't check if I could remove it or not as wasn't sure if the PB7 pin has input pullup enabled or not.

@rogerclarkmelbourne

This comment has been minimized.

Show comment
Hide comment
@rogerclarkmelbourne

rogerclarkmelbourne Jun 7, 2017

Contributor

@enly1

Which STLink dongle are you using?

I have it partially working, including UART on a "Baite" branded STLink from AliExpress, but I was also interested in getting it to work on the same one as @rene-dev posted the internal photos of.

However, If the schematic posted by @rene-dev is correct (which I think it probably is), then to make the UART work would require the use of 2 UARTS

i.e
Neither PB13 or PB14 is usable as a UART

However PB6 is the USART1_TX via ALT pin mapping
and PB11 is USART3_RX on its primary mapping
So the code would need to be modified quite a lot to configure 2 UARTS (1 and 3) and put 1 on its ALT pins

I'm not sure if the F101C8 has USART3

BTW. As previously discussed, although the STM32F101 is not supposed to have USB, in reality it does have, probably because ST are selling F103's as F101's
Its also likely that it has 128k flash, because most F103C8's are only supposed to have 64k no one has ever found a F103C8 that does not have 128k.

Contributor

rogerclarkmelbourne commented Jun 7, 2017

@enly1

Which STLink dongle are you using?

I have it partially working, including UART on a "Baite" branded STLink from AliExpress, but I was also interested in getting it to work on the same one as @rene-dev posted the internal photos of.

However, If the schematic posted by @rene-dev is correct (which I think it probably is), then to make the UART work would require the use of 2 UARTS

i.e
Neither PB13 or PB14 is usable as a UART

However PB6 is the USART1_TX via ALT pin mapping
and PB11 is USART3_RX on its primary mapping
So the code would need to be modified quite a lot to configure 2 UARTS (1 and 3) and put 1 on its ALT pins

I'm not sure if the F101C8 has USART3

BTW. As previously discussed, although the STM32F101 is not supposed to have USB, in reality it does have, probably because ST are selling F103's as F101's
Its also likely that it has 128k flash, because most F103C8's are only supposed to have 64k no one has ever found a F103C8 that does not have 128k.

@enly1

This comment has been minimized.

Show comment
Hide comment
@enly1

enly1 Jun 8, 2017

@rogerclarkmelbourne will check tonight - but I think it was one of the v1 clones with an stm32f101 on it.
Pin remapped the uart and removed one of the resistors to get it to work.

enly1 commented Jun 8, 2017

@rogerclarkmelbourne will check tonight - but I think it was one of the v1 clones with an stm32f101 on it.
Pin remapped the uart and removed one of the resistors to get it to work.

@rogerclarkmelbourne

This comment has been minimized.

Show comment
Hide comment
@rogerclarkmelbourne

rogerclarkmelbourne Jun 8, 2017

Contributor

@enly1

Thanks.

I noticed that the resistors seem to stop serial loopback working, but I could send and receive to a separate USB Serial.

So I suspect the problem is the resistor values e.g. the 680 ohms in series, though I think there is also a pullup which may not be helping either

Contributor

rogerclarkmelbourne commented Jun 8, 2017

@enly1

Thanks.

I noticed that the resistors seem to stop serial loopback working, but I could send and receive to a separate USB Serial.

So I suspect the problem is the resistor values e.g. the 680 ohms in series, though I think there is also a pullup which may not be helping either

@enly1

This comment has been minimized.

Show comment
Hide comment
@enly1

enly1 Jun 8, 2017

enly1 commented Jun 8, 2017

@rogerclarkmelbourne

This comment has been minimized.

Show comment
Hide comment
@rogerclarkmelbourne

rogerclarkmelbourne Jun 8, 2017

Contributor

I think your STLink dongle may be different from mine.

AFIK the schematic in mine is something like this http://www.avrki.ru/picture/articles/samodelniy_st_link_v2/shemf_st_link_v2.jpg
but the pinout to the plug is different

It seems to have 680 ohms in series with PB7 and another 680 ohms to 3.3V (via the PB7 to PB11 connection)

So it looks like the SWIM pin would be pulled to 3.3V/2 = 1.65 and PB7 will have to drive against that all the time.

Contributor

rogerclarkmelbourne commented Jun 8, 2017

I think your STLink dongle may be different from mine.

AFIK the schematic in mine is something like this http://www.avrki.ru/picture/articles/samodelniy_st_link_v2/shemf_st_link_v2.jpg
but the pinout to the plug is different

It seems to have 680 ohms in series with PB7 and another 680 ohms to 3.3V (via the PB7 to PB11 connection)

So it looks like the SWIM pin would be pulled to 3.3V/2 = 1.65 and PB7 will have to drive against that all the time.

@enly1

This comment has been minimized.

Show comment
Hide comment
@enly1

enly1 Jun 8, 2017

stm32front
stm32back

These were the board I have - I swapped R10 for a 20K resistor to help out with the voltage divider situation. Worked with all my usb uarts and loopback tests.

enly1 commented Jun 8, 2017

stm32front
stm32back

These were the board I have - I swapped R10 for a 20K resistor to help out with the voltage divider situation. Worked with all my usb uarts and loopback tests.

@enly1

This comment has been minimized.

Show comment
Hide comment
@enly1

enly1 Jun 8, 2017

PS - label on the aluminum cover shows st-link v2.

enly1 commented Jun 8, 2017

PS - label on the aluminum cover shows st-link v2.

@rogerclarkmelbourne

This comment has been minimized.

Show comment
Hide comment
@rogerclarkmelbourne

rogerclarkmelbourne Jun 8, 2017

Contributor

Which build target ("platform") are you using with this dongle ?

stlink or swlink (or something else)

BTW. Mine also has STLink V2 written on it, so I'm sure its the same one.

I presume you must have connected Serial TX and RX to Pins 1 and 3 (RST and SWIM) (possibly the other way around)

In which case, isn't RST connected to either PB0 or PB6, depending on whether RST means NRST or SWIM_RST
and SWIM connected to PB7 ?

I presume RST must mean SWIM_RST otherwise its not going to work.

I'm now also guessing that you must be using code based on the "swlink" version, as that version uses the UART on PB6 and PB7

Re: Changing R10 for 20k.
Can you post a link to the schematic, as I don't think I have one which accurately reflects the resistor numbers

Also. Why didn't you simply remove the pullup ?

Contributor

rogerclarkmelbourne commented Jun 8, 2017

Which build target ("platform") are you using with this dongle ?

stlink or swlink (or something else)

BTW. Mine also has STLink V2 written on it, so I'm sure its the same one.

I presume you must have connected Serial TX and RX to Pins 1 and 3 (RST and SWIM) (possibly the other way around)

In which case, isn't RST connected to either PB0 or PB6, depending on whether RST means NRST or SWIM_RST
and SWIM connected to PB7 ?

I presume RST must mean SWIM_RST otherwise its not going to work.

I'm now also guessing that you must be using code based on the "swlink" version, as that version uses the UART on PB6 and PB7

Re: Changing R10 for 20k.
Can you post a link to the schematic, as I don't think I have one which accurately reflects the resistor numbers

Also. Why didn't you simply remove the pullup ?

@enly1

This comment has been minimized.

Show comment
Hide comment
@enly1

enly1 Jun 9, 2017

enly1 commented Jun 9, 2017

@rogerclarkmelbourne

This comment has been minimized.

Show comment
Hide comment
@rogerclarkmelbourne

rogerclarkmelbourne Jun 9, 2017

Contributor

No worries

Contributor

rogerclarkmelbourne commented Jun 9, 2017

No worries

@rixnco

This comment has been minimized.

Show comment
Hide comment
@rixnco

rixnco Jun 27, 2017

Hi guys,

I'm jumping in the discussion as I'm interrested in remaping my stlink v2 mini RST and SWIM pins to usart.
I have the exact same board as @enly1 posted.

@enly1 could you please give me a bit more details on your solution?

Regards

rixnco commented Jun 27, 2017

Hi guys,

I'm jumping in the discussion as I'm interrested in remaping my stlink v2 mini RST and SWIM pins to usart.
I have the exact same board as @enly1 posted.

@enly1 could you please give me a bit more details on your solution?

Regards

@gojimmypi

This comment has been minimized.

Show comment
Hide comment
@gojimmypi

gojimmypi Jun 28, 2017

Its also likely that it has 128k flash, because most F103C8's are only supposed to have 64k no one has ever found a F103C8 that does not have 128k

@enly1 @rogerclarkmelbourne lucky me, I think I have one! :| Last evening, I was trying to flash BlackMagic onto a "Blue Pill" with the STM32F103C8, and pretty much comprehensively confirmed there's only 64KB

For one, dfu-util -l has a the text /0x08000000/8*001Ka,056*001Kg, which I assume means "8KB bootloader at 0x08000000 and 56 KB free after bootloader" (true?):

dfu-util 0.8

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2014 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to dfu-util@lists.gnumonks.org

Found DFU: [1d50:6017] ver=0100, devnum=40, cfg=1, intf=0, alt=0, name="@Internal Flash   /0x08000000/8*001Ka,056*001Kg", serial="76543210"

Further, when I try to flash BlackMagic, (now 58,364 bytes), I get this error:

0 $  sudo dfu-util -d 1d50:6017 -s 0x08002000 -D blackmagic.bin --verbose
dfu-util 0.8

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2014 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to dfu-util@lists.gnumonks.org

dfu-util: Invalid DFU suffix signature
dfu-util: A valid DFU suffix will be required in a future dfu-util release!!!
Opening DFU capable USB device...
ID 1d50:6017
Run-time device DFU version 011a
Claiming USB DFU Interface...
Setting Alternate Setting #0 ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 011a
Device returned transfer size 1024
DfuSe interface name: "Internal Flash   "
Memory segment at 0x08000000   8 x 1024 =  8192 (r)
Memory segment at 0x08002000  56 x 1024 = 57344 (rew)
Downloading to address = 0x08002000, size = 58364
dfu-util: Last page at 0x080103fb is not writeable

I am otherwise able to flash the smaller dfu_upgrade.bin with no problems:

0 $ sudo dfu-util -d 1d50:6017 -s 0x08002000 -D dfu_upgrade.bin --verbose
dfu-util 0.8

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2014 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to dfu-util@lists.gnumonks.org

dfu-util: Invalid DFU suffix signature
dfu-util: A valid DFU suffix will be required in a future dfu-util release!!!
Opening DFU capable USB device...
ID 1d50:6017
Run-time device DFU version 011a
Claiming USB DFU Interface...
Setting Alternate Setting #0 ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 011a
Device returned transfer size 1024
DfuSe interface name: "Internal Flash   "
Memory segment at 0x08000000   8 x 1024 =  8192 (r)
Memory segment at 0x08002000  56 x 1024 = 57344 (rew)
Downloading to address = 0x08002000, size = 6764
Download        [                         ]   0%            0 bytes   Poll timeout 100 ms
   Poll timeout 0 ms
 Download from image offset 00000000 to memory 08002000-080023ff, size 1024
   Poll timeout 100 ms
   Poll timeout 0 ms
   Poll timeout 100 ms
   Poll timeout 0 ms
 Download from image offset 00000400 to memory 08002400-080027ff, size 1024
   Poll timeout 100 ms
   Poll timeout 0 ms
   Poll timeout 100 ms
   Poll timeout 0 ms
 Download from image offset 00000800 to memory 08002800-08002bff, size 1024
   Poll timeout 100 ms
   Poll timeout 0 ms
   Poll timeout 100 ms
   Poll timeout 0 ms
 Download from image offset 00000c00 to memory 08002c00-08002fff, size 1024
   Poll timeout 100 ms
   Poll timeout 0 ms
   Poll timeout 100 ms
   Poll timeout 0 ms
 Download from image offset 00001000 to memory 08003000-080033ff, size 1024
   Poll timeout 100 ms
   Poll timeout 0 ms
   Poll timeout 100 ms
   Poll timeout 0 ms
 Download from image offset 00001400 to memory 08003400-080037ff, size 1024
   Poll timeout 100 ms
   Poll timeout 0 ms
   Poll timeout 100 ms
   Poll timeout 0 ms
 Download from image offset 00001800 to memory 08003800-08003a6b, size 620
   Poll timeout 100 ms
   Poll timeout 0 ms
File downloaded successfully

launching the STM32 Flash loader demonstrator (UM0462) indicates at startup time that it found a 64K device:
st 64k

There's a comment here that:

The STM32duino core have two uploading board settings, one for 64 KB and one for 128 KB.

So perhaps there's still hope? However I've been unable to find these "settings" for memory (?)

And so ya - I also have a ST-Link that I will be trying, but the chip is so hard to read, I cannot tell if that's a "B" or an "8".

*edit: spelling

gojimmypi commented Jun 28, 2017

Its also likely that it has 128k flash, because most F103C8's are only supposed to have 64k no one has ever found a F103C8 that does not have 128k

@enly1 @rogerclarkmelbourne lucky me, I think I have one! :| Last evening, I was trying to flash BlackMagic onto a "Blue Pill" with the STM32F103C8, and pretty much comprehensively confirmed there's only 64KB

For one, dfu-util -l has a the text /0x08000000/8*001Ka,056*001Kg, which I assume means "8KB bootloader at 0x08000000 and 56 KB free after bootloader" (true?):

dfu-util 0.8

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2014 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to dfu-util@lists.gnumonks.org

Found DFU: [1d50:6017] ver=0100, devnum=40, cfg=1, intf=0, alt=0, name="@Internal Flash   /0x08000000/8*001Ka,056*001Kg", serial="76543210"

Further, when I try to flash BlackMagic, (now 58,364 bytes), I get this error:

0 $  sudo dfu-util -d 1d50:6017 -s 0x08002000 -D blackmagic.bin --verbose
dfu-util 0.8

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2014 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to dfu-util@lists.gnumonks.org

dfu-util: Invalid DFU suffix signature
dfu-util: A valid DFU suffix will be required in a future dfu-util release!!!
Opening DFU capable USB device...
ID 1d50:6017
Run-time device DFU version 011a
Claiming USB DFU Interface...
Setting Alternate Setting #0 ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 011a
Device returned transfer size 1024
DfuSe interface name: "Internal Flash   "
Memory segment at 0x08000000   8 x 1024 =  8192 (r)
Memory segment at 0x08002000  56 x 1024 = 57344 (rew)
Downloading to address = 0x08002000, size = 58364
dfu-util: Last page at 0x080103fb is not writeable

I am otherwise able to flash the smaller dfu_upgrade.bin with no problems:

0 $ sudo dfu-util -d 1d50:6017 -s 0x08002000 -D dfu_upgrade.bin --verbose
dfu-util 0.8

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2014 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to dfu-util@lists.gnumonks.org

dfu-util: Invalid DFU suffix signature
dfu-util: A valid DFU suffix will be required in a future dfu-util release!!!
Opening DFU capable USB device...
ID 1d50:6017
Run-time device DFU version 011a
Claiming USB DFU Interface...
Setting Alternate Setting #0 ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 011a
Device returned transfer size 1024
DfuSe interface name: "Internal Flash   "
Memory segment at 0x08000000   8 x 1024 =  8192 (r)
Memory segment at 0x08002000  56 x 1024 = 57344 (rew)
Downloading to address = 0x08002000, size = 6764
Download        [                         ]   0%            0 bytes   Poll timeout 100 ms
   Poll timeout 0 ms
 Download from image offset 00000000 to memory 08002000-080023ff, size 1024
   Poll timeout 100 ms
   Poll timeout 0 ms
   Poll timeout 100 ms
   Poll timeout 0 ms
 Download from image offset 00000400 to memory 08002400-080027ff, size 1024
   Poll timeout 100 ms
   Poll timeout 0 ms
   Poll timeout 100 ms
   Poll timeout 0 ms
 Download from image offset 00000800 to memory 08002800-08002bff, size 1024
   Poll timeout 100 ms
   Poll timeout 0 ms
   Poll timeout 100 ms
   Poll timeout 0 ms
 Download from image offset 00000c00 to memory 08002c00-08002fff, size 1024
   Poll timeout 100 ms
   Poll timeout 0 ms
   Poll timeout 100 ms
   Poll timeout 0 ms
 Download from image offset 00001000 to memory 08003000-080033ff, size 1024
   Poll timeout 100 ms
   Poll timeout 0 ms
   Poll timeout 100 ms
   Poll timeout 0 ms
 Download from image offset 00001400 to memory 08003400-080037ff, size 1024
   Poll timeout 100 ms
   Poll timeout 0 ms
   Poll timeout 100 ms
   Poll timeout 0 ms
 Download from image offset 00001800 to memory 08003800-08003a6b, size 620
   Poll timeout 100 ms
   Poll timeout 0 ms
File downloaded successfully

launching the STM32 Flash loader demonstrator (UM0462) indicates at startup time that it found a 64K device:
st 64k

There's a comment here that:

The STM32duino core have two uploading board settings, one for 64 KB and one for 128 KB.

So perhaps there's still hope? However I've been unable to find these "settings" for memory (?)

And so ya - I also have a ST-Link that I will be trying, but the chip is so hard to read, I cannot tell if that's a "B" or an "8".

*edit: spelling

@rma-x

This comment has been minimized.

Show comment
Hide comment
@rma-x

rma-x Nov 20, 2017

@gojimmypi

I guess you were using a version of blackmagic_dfu prior to commit b09a522:

Before this change the bootloader always reported a total of 64k flash for the stlink target regardless of the actual chip, and dfu-util refuses to flash a firmware image that is larger than the reported flash size. The newer bootloader reads the chip's flash size register at runtime and if that reports 64k it passes on 128k instead, because even the STM32F103C8 chips that really have 128k claim to only have 64k in their flash size register.

So your test was only for the reported flash size, not for the actual flash size and if your C8 really has 128k you should be able to use it if after upgrading to the latest bootloader.

rma-x commented Nov 20, 2017

@gojimmypi

I guess you were using a version of blackmagic_dfu prior to commit b09a522:

Before this change the bootloader always reported a total of 64k flash for the stlink target regardless of the actual chip, and dfu-util refuses to flash a firmware image that is larger than the reported flash size. The newer bootloader reads the chip's flash size register at runtime and if that reports 64k it passes on 128k instead, because even the STM32F103C8 chips that really have 128k claim to only have 64k in their flash size register.

So your test was only for the reported flash size, not for the actual flash size and if your C8 really has 128k you should be able to use it if after upgrading to the latest bootloader.

@rene-dev

This comment has been minimized.

Show comment
Hide comment
@rene-dev

rene-dev Nov 20, 2017

description of the string, from st:

USBD_DFU_MEDIA Interface USBD_DFU_MEDIA Parameter Description:
The description of the flash (used by PC tool DFuSe) Each Alternate setting string descriptor must follow this memory mapping so that the PC Host Software can decode the right mapping for the selected device:
@: To detect that this is a special mapping descriptor (to avoid decoding standard descriptor)
/: for separator between zones
Maximum 8 digits per address starting by “0x”
/: for separator between zones
Maximum of 2 digits for the number of sectors
: For separator between number of sectors and sector size
Maximum 3 digits for sector size between 0 and 999
1 digit for the sector size multiplier. Valid entries are: B (byte), K (Kilo), M (Mega)
1 digit for the sector type as follows: – a (0x41): Readable – b (0x42): Erasable – c (0x43): Readable and Erasabled (0x44): Writeable – e (0x45): Readable and Writeable – f (0x46): Erasable and Writeable – g (0x47): Readable, Erasable and Writeable Note: If the target memory is not contiguous, the user can add the new sectors to be decoded just after a slash"/" as shown in the following example: "@flash /0xF000/1
4Ka/0xE000/14Kg/0x8000/224Kg"

rene-dev commented Nov 20, 2017

description of the string, from st:

USBD_DFU_MEDIA Interface USBD_DFU_MEDIA Parameter Description:
The description of the flash (used by PC tool DFuSe) Each Alternate setting string descriptor must follow this memory mapping so that the PC Host Software can decode the right mapping for the selected device:
@: To detect that this is a special mapping descriptor (to avoid decoding standard descriptor)
/: for separator between zones
Maximum 8 digits per address starting by “0x”
/: for separator between zones
Maximum of 2 digits for the number of sectors
: For separator between number of sectors and sector size
Maximum 3 digits for sector size between 0 and 999
1 digit for the sector size multiplier. Valid entries are: B (byte), K (Kilo), M (Mega)
1 digit for the sector type as follows: – a (0x41): Readable – b (0x42): Erasable – c (0x43): Readable and Erasabled (0x44): Writeable – e (0x45): Readable and Writeable – f (0x46): Erasable and Writeable – g (0x47): Readable, Erasable and Writeable Note: If the target memory is not contiguous, the user can add the new sectors to be decoded just after a slash"/" as shown in the following example: "@flash /0xF000/1
4Ka/0xE000/14Kg/0x8000/224Kg"

@gojimmypi

This comment has been minimized.

Show comment
Hide comment
@gojimmypi

gojimmypi commented Nov 23, 2017

thank you @rma-x

@UweBonnes

This comment has been minimized.

Show comment
Hide comment
@UweBonnes

UweBonnes Feb 1, 2018

Contributor

Could people with a "baite"board try https://github.com/UweBonnes/blackmagic/tree/baite

If PC13/14 float and PB11 is pulled high, recognize as baite.
Handle as rev.1 board. Deciphered from:
http://www.avrki.ru/picture/articles/samodelniy_st_link_v2/shemf_st_link_v2.jpg

Contributor

UweBonnes commented Feb 1, 2018

Could people with a "baite"board try https://github.com/UweBonnes/blackmagic/tree/baite

If PC13/14 float and PB11 is pulled high, recognize as baite.
Handle as rev.1 board. Deciphered from:
http://www.avrki.ru/picture/articles/samodelniy_st_link_v2/shemf_st_link_v2.jpg

@rogerclarkmelbourne

This comment has been minimized.

Show comment
Hide comment
@rogerclarkmelbourne

rogerclarkmelbourne Feb 1, 2018

Contributor

I have some Baite STLink dongles, but don't have time to test until the weekend

Contributor

rogerclarkmelbourne commented Feb 1, 2018

I have some Baite STLink dongles, but don't have time to test until the weekend

@JojoS62

This comment has been minimized.

Show comment
Hide comment
@JojoS62

JojoS62 Feb 2, 2018

@UweBonnes: I've tried your baite branch and it works. First I flashed the stlink version, then merged your baite branch and flashed the new bin using the stm32.mem.py. In µC.net I reported you an error when using the python flash scripts, with the stlink version it works. The version output is:
(gdb) monitor ver Black Magic Probe (Firmware v1.6.1-114-gb9c5bb9) (Hardware Version 1)

but there is another PR for the baite platform: #274
There the UART pins are PB_6/PB_7, which is more convenient because these pins are on the 10 pin SWD connector, https://wiki.cuvoodoo.info/doku.php?id=jtag
The 680R pull-up at PB11 is very strong and also connected to PB_7 (RxD), I would rather remove this R for proper operation of the UART. I've tested this on another adapter, it works better without this pullup. But then your baite-detection doesn't work, also when PB_7 is used for the UART.

My conclusion: use the PR #274 for this hardware version.

JojoS62 commented Feb 2, 2018

@UweBonnes: I've tried your baite branch and it works. First I flashed the stlink version, then merged your baite branch and flashed the new bin using the stm32.mem.py. In µC.net I reported you an error when using the python flash scripts, with the stlink version it works. The version output is:
(gdb) monitor ver Black Magic Probe (Firmware v1.6.1-114-gb9c5bb9) (Hardware Version 1)

but there is another PR for the baite platform: #274
There the UART pins are PB_6/PB_7, which is more convenient because these pins are on the 10 pin SWD connector, https://wiki.cuvoodoo.info/doku.php?id=jtag
The 680R pull-up at PB11 is very strong and also connected to PB_7 (RxD), I would rather remove this R for proper operation of the UART. I've tested this on another adapter, it works better without this pullup. But then your baite-detection doesn't work, also when PB_7 is used for the UART.

My conclusion: use the PR #274 for this hardware version.

@orangefour

This comment has been minimized.

Show comment
Hide comment
@orangefour

orangefour Mar 2, 2018

@rixnco have you been able to flash your boards? Very interested in converting my clone to BMP to use SWD/SWC + RX

orangefour commented Mar 2, 2018

@rixnco have you been able to flash your boards? Very interested in converting my clone to BMP to use SWD/SWC + RX

@rixnco

This comment has been minimized.

Show comment
Hide comment
@rixnco

rixnco Apr 11, 2018

@orangefour. No I ended up using a bluepill board.

rixnco commented Apr 11, 2018

@orangefour. No I ended up using a bluepill board.

@flatsiedatsie

This comment has been minimized.

Show comment
Hide comment
@flatsiedatsie

flatsiedatsie Apr 18, 2018

This guide helped me (mac user) to install Black Magic Probe on an ST-Link V2. You will need two of those devices, one to program the other.

https://embdev.net/articles/STM_Discovery_as_Black_Magic_Probe

I found the correct pins to use for my device here:
https://madnessinthedarkness.transsys.com/blog:2017:0122_black_magic_probe_bmp_on_st-link_v2_clones

flatsiedatsie commented Apr 18, 2018

This guide helped me (mac user) to install Black Magic Probe on an ST-Link V2. You will need two of those devices, one to program the other.

https://embdev.net/articles/STM_Discovery_as_Black_Magic_Probe

I found the correct pins to use for my device here:
https://madnessinthedarkness.transsys.com/blog:2017:0122_black_magic_probe_bmp_on_st-link_v2_clones

@joric

This comment has been minimized.

Show comment
Hide comment
@joric

joric Jul 21, 2018

@gojimmypi same here. Last page is not writeable and stuff. Looks like those "unique" 64k RAM ones (56 KB free after bootloader). What I can do about it?

dfu-util.exe -l
Found DFU: [1d50:6017] ver=0100, devnum=45, cfg=1, intf=0, path="1-3", alt=0, name="@Internal Flash   /0x08000000/8*001Ka,056*001Kg", serial="C4DFCC06"

Looks like a regular $2 blue pill board, got it from ebay.

Upd: used ST-Link Demonstrator GUI via UART (force select 128K, select 8002000) and it worked. Instructions found here https://gojimmypi.blogspot.com/2017/07/BluePill-STM32F103-to-BlackMagic-Probe.html

joric commented Jul 21, 2018

@gojimmypi same here. Last page is not writeable and stuff. Looks like those "unique" 64k RAM ones (56 KB free after bootloader). What I can do about it?

dfu-util.exe -l
Found DFU: [1d50:6017] ver=0100, devnum=45, cfg=1, intf=0, path="1-3", alt=0, name="@Internal Flash   /0x08000000/8*001Ka,056*001Kg", serial="C4DFCC06"

Looks like a regular $2 blue pill board, got it from ebay.

Upd: used ST-Link Demonstrator GUI via UART (force select 128K, select 8002000) and it worked. Instructions found here https://gojimmypi.blogspot.com/2017/07/BluePill-STM32F103-to-BlackMagic-Probe.html

@UweBonnes

This comment has been minimized.

Show comment
Hide comment
@UweBonnes

UweBonnes Jul 21, 2018

Contributor

Have a look at (blackmagic)/scripts/stm32mem. It does not care about the DFU header but tries to write above 64 kByte even on a F103C8. But it compares the result and will show if there is no success.

Contributor

UweBonnes commented Jul 21, 2018

Have a look at (blackmagic)/scripts/stm32mem. It does not care about the DFU header but tries to write above 64 kByte even on a F103C8. But it compares the result and will show if there is no success.

@gvegidy

This comment has been minimized.

Show comment
Hide comment
@gvegidy

gvegidy commented Sep 4, 2018

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