Black Magic Probe on an stm32f103c8

11/07/2017 – I attached a binary that can be loaded onto your blue pill in this post: viewtopic.php?f=37&t=2801

12/3/2016 – You can now contribute to developers of the Black Magic Probe project (which isn’t me) using paypal. Find and click the paypal contribute button here: https://github.com/blacksphere/blackmagic

12/8/2016 – Instead of using this port of Black Magic Probe, it is a lot easier to just compile the PROBE_HOST=stlink and load that onto your bluepill. The bluepill hardware is the same as the stlink v1/v2 hardware. Just follow the steps from the Black Magic Probe software for building and installing the BMP stlink platform. The advantage being, you will get the latest BMP version and you will be able to update future versions just using the USB cable on the bluepill with a program called usb-util. The posts in this thread can be thought of as an interesting read on my journey from bluepill newbie to a somewhat proficient users of it.

The Black Magic Probe is a modern, in-application programmer and debugging software for embedded microprocessors. It allows you to see what is going on ‘inside’ an application running on an embedded microprocessor while it executes. It is able to control and examine the state of the target microprocessor using a JTAG or SWD (Serial Wire debugging) port and on-chip debug logic provided by the microprocessor. The probe connects to a host computer using a standard USB interface. The user is able to control exactly what happens using the GNU source level debugging software, GDB. Read more about it here: https://github.com/blacksphere/blackmagic/wiki

However, the stm32duino crowd here will find the open source Black Magic firmware more appealing than the hardware. The Black Magic Probe firmware can be loaded onto the low cost stm32c8t6 boards you find on eBay. You can then use that clone board with BMP firmware to take the place of an ST-Link programmer. Once the BMP firmware is loaded on a clone board, it provides the ability to upload to the flash of another target board. It does this using a gdb server built into the BMP firmware. This allows for hardware debugging using just arm-none-eabi-gdb without any host server code.

I started with the latest github version of the Black Magic Probe software and added platform support for the stm32f103c8t6 boards you find on ebay. I call it the ‘jc66_coreboard’ platform, as that is the label printed on the silk screen. Any board with the same pin outs should work (See Red Pill Blue Pill post for more info about the hardware). The new platform is based mostly on the already existing stlink platform source with changes to support the different hardware pin outs and features.

The ebay “Red Pill” board loaded with the Black Magic Probe firmware acting like a programmer:

by Rick Kimball, on Flickr

Target board (another “Red Pill” board) connections from the “Red Pill” BMP programmer:

I’ve attached a zip file containing the blackmagic.bin file, the blackmagic elf file, and patch file for the source. ( NOTE: I will fork BMP github code and create a branch with the source changes). For now, just download and unpack the zip and then upload the bin or elf file to your jc66_coreboard.

If you want to build the source yourself, do something like the following:
$ git clone https://github.com/blacksphere/blackmagic
Cloning into 'blackmagic'...
remote: Counting objects: 3463, done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 3463 (delta 0), reused 0 (delta 0), pack-reused 3461
Receiving objects: 100% (3463/3463), 1.70 MiB | 0 bytes/s, done.
Resolving deltas: 100% (2331/2331), done.
Checking connectivity... done.
$ cd blackmagic
$ unzip ../bmp_jc66_coreboard.zip
Archive: ../bmp_jc66_coreboard.zip
inflating: blackmagic
inflating: blackmagic.bin
inflating: bmp_jc66_coreboard.patch
$ patch -p1 <bmp_jc66_coreboard.patch
patching file src/Makefile
patching file src/command.c
patching file src/platforms/common/cdcacm.c
patching file src/platforms/jc66_coreboard/Makefile.inc
patching file src/platforms/jc66_coreboard/Readme
patching file src/platforms/jc66_coreboard/jc66_coreboard.png
patching file src/platforms/jc66_coreboard/platform.c
patching file src/platforms/jc66_coreboard/platform.h
$ make
$ cd src
$ make install # assuming it go OK, you will have to change the path for the st-write utility to match your system


Rick,

I’ve tried to install the BMP binary on 2 different C8 boards

This one didnt work, I just get unknown device on USB

However I have a feeling the board either has a defective USB connection or it doesn’t have a pull up resistor etc and will only work on USB with special firmware

The other C8 board, was fine (its the same board you have)

On Windows I had to download and install the drivers from here http://www.blacksphere.co.nz/downloads/ … 130819.zip

What does seem a bit odd, is that the drivers 2 years old http://www.blacksphere.co.nz/downloads/

I guess they have no need to update them, but I suspect that they may not work on Windows 10 without us re-packaging them (but its hard to know quite what Windows 10 will end up doing until its released)

I guess it doesnt really matter, but has BlackSphere given up selling the BMP ? There isnt a link to where you an buy it from, on their website. Well there is some text but no hyperlink

Is there any documentation about what GPIO pins on the flashed board need to be connected to the CLOCK and SDIO pins on the SWD connector ?

Do you know how the UART works, is this just a method to print debug messages

e.g. I found this code,

http://electronics.stackexchange.com/qu … d-using-gd

Is this the sort of UART functionality it provides ?

Thanks

Roger

I wonder if it would be possible to flash the BMP firmware on one of http://www.ebay.co.uk/itm/181736138353? … 26_rdc%3D1these.

Since I now have two of these ST-Link V2 clones it should be possible to use one to probe the other. They are also scarily cheap. If I get a chance I’ll try and reverse engineer the board and see if I can A) copy off the existing firmware, and B) figure out if we have enough pins etc to re-purpose it as a Black Magic Probe.

RogerClark wrote:
This one didnt work, I just get unknown device on USB

I really haven’t documented all the features. There are some other modifications in there if you look at the code.

I included support for reading the target boards VCC voltage. I found a patch on blackmagic mailing list
http://sourceforge.net/p/blackmagicdebu … /33693983/. I slightly modified it to fit the hardware on this board. To use this feature you need to do some things:

o Add a voltage divider and diode on pin PA0.
Use 4k7 resistors and connect to your TARGET VCC (On the c8 board it is broken out with the SWD pins)

pa0_diode_circuit.png (5.17 KiB) Viewed 28618 times

ahull wrote:I wonder if it would be possible to flash the BMP firmware on one of http://www.ebay.co.uk/itm/181736138353? … 26_rdc%3D1these.

Since I now have two of these ST-Link V2 clones it should be possible to use one to probe the other. They are also scarily cheap. If I get a chance I’ll try and reverse engineer the board and see if I can A) copy off the existing firmware, and B) figure out if we have enough pins etc to re-purpose it as a Black Magic Probe.

Rick, is there a way to use BMP and GDB on windows with the Arduino IDE? I have never used either, so I am getting a bit lost at what is needed.
If you could point me to some directions I can read and try to figure it out.

thanks.

[EDIT] .. see the next post for a possible answer[/EDIT]

victor_pv wrote:Rick, is there a way to use BMP and GDB on windows with the Arduino IDE? I have never used either, so I am getting a bit lost at what is needed. If you could point me to some directions I can read and try to figure it out. thanks.

I went ahead and modified the platform.txt to do the upload via arm-none-eabi-gdb.

Here is what it looks like when you have verbose upload turned on with the Arduino IDE on linux:

makerlabme_gdb.png (82.85 KiB) Viewed 28603 times

Rick

I think that code should work on Windows, but for greater compatibility for anyone on IDE 1.6.1 or earlier I think the path to GDB needs to be changed to the same path that is defined at the top of platform.txt, and then allow the rewrite-keys to handle changing it if necessary

With my other C8 board.
It could just be the board is defective.

Re: connections

After I posted, I managed to find a schematic of a derivative of the BMP called the Cricket Probe, and I can see that the BMP uses serial port 1 to connect to the target, as well as the SWD connection.

I will have a go at using the same model of F103C8 board that you use, and connect to my ZET board.

@ahull

Re: flashing an STLink.

I noticed in the GitHub code that there is a target of STlink, rather than the target of STM32 which I think rick may be using.

I was debating whether to reflash my STLink as a BMP, as I read the article you linked to and then tracked down the Stlink binary it referenced, on a Russian website.

However my stlink board only has the SWD pins broken out to a connector, so connecting a USB to serial to it, and pulling boot 0 high, in order to flash it, would be difficult.

In the longer term I may however reflash by F4 Discover stlink as its a pain needing a separate USB to serial for comms, I.e the Discovery stlink firmware doesn’t come with the virtual serial like the Nucleo firmware does

RogerClark wrote:Rick
After I posted, I managed to find a schematic of a derivative of the BMP called the Cricket Probe, and I can see that the BMP uses serial port 1 to connect to the target, as well as the SWD connection.

So after playing with this for a while. I realized that I needed to make a few modifications to the gdb commands I’m running with the -ex arguments. This seems to make it somewhat more reliable. I ended up putting shell sleep x in a couple of places, and yes I realize this is going to be problem with windows. I also read memory after erasing and after loading to force gdb to wait until it is done with any pending memory operations. After the file is loaded, I actually set a breakpoint on main and force it to reset and rerun the firmware. This is so the user doesn’t have to press the reset button when it is done loading. Here is what I have right now:

tools.sloadhost.upload.pattern="{path}{cmd}" -b 38400 -ex "set debug remote 0" -ex "set confirm off" -ex "set height 0" -ex "target extended-remote {serial.port}" -ex "mon swd" -ex "shell sleep 2" -ex "echo \nattach...\n" -ex "attach 1" -ex "shell sleep 2" -ex "x/wx 0x8000004" -ex "monitor erase_mass" -ex "x/wx 0x8000004" -ex "load" -ex "x/i *0x8000004" -ex "break main" -ex "run" -ex "echo \n\n\n{build.project_name}.elf uploaded!\n" -ex "quit" "{build.path}/{build.project_name}.elf"

OK, I think I figured out some of the issues. GDB will work in async mode and return immediately unless you turn that feature off. This seems to work and I was able to get rid of all the shell sleep instructions:

tools.sloadhost.upload.pattern="{path}{cmd}" -b 38400 -ex "set debug remote 0" -ex "set remotetimeout 10" -ex "set confirm off" -ex "set target-async off" -ex "set height 0" -ex "target extended-remote {serial.port}" -ex "mon swd" -ex "attach 1" -ex "x/wx 0x8000004" -ex "monitor erase_mass" -ex "echo address value should be 0xffffffff after erase\n" -ex "x/wx 0x8000004" -ex "file {build.path}/{build.project_name}.elf" -ex "load" -ex "x/i *0x8000004" -ex "break main" -ex "run" -ex "echo \n\n\n{build.project_name}.elf uploaded!\n" -ex "quit"

Rick,

Thanks.

Work is a bit busy for me at the moment, but I’ll give it a try this evening (my time)

Cheers

Roger

[Edit] I deleted the attachment here .. first post contains full versions of modified board.txt and platform.txt files[/EDIT]

This patch will add a BMP uploader feature to the generic stm32f103c boards. Apply it to the latest stm32duino source code. Someone with windows and OS/X might want to try this and see if it works.

$ # kill any running arduino sessions
$ cd Arduino_STM32
$ unzip bmp_upload.patch.zip
$ patch -p1 <bmp_upload.patch
$ # restart arduino

-rick

@Rick. On my Linux box..

Patch seems to be safe, and appears to do what you describe.

IDE still compiles code, but since I have no BMP to play with (yet…. give me time)… it fails with the following message..
COM1: No such file or directory.
"monitor" command not supported by this target.
Don't know how to attach. Try "help target".
Cannot access memory at address 0x8000004
"monitor" command not supported by this target.
Cannot access memory at address 0x8000004
You can't do that when your target is `exec'
The program is not being run.
Don't know how to run. Try "help target".
The program is not being run.


@ahull

Do you have a spare F103C8 board, if so you just flash Ricks binary into it.

I flashed by spare board and it enumerates fine on windows, but I’ve been a bit preoccupied trying to unify the bootloader that victor made for generic boards with the existing bootloader, and I’ve also been trying to get DDD working on windows ( see my post in the general discussion thread)

I’m happy to add upload to BMP as an option on all generic boards, as I see this as a low risk change, as its just adding new features and should not disturb the old ones.

I must admit I’m surprised about how few people are interested in In Circuit debugging, but it could be just a catch 22 situation at the moment, with both the lack of easily available hardware and software, and no windows GUI.

@Roger – if I get some spare time I was planning on trying to build/flash to a generic “ST-Link V2” clone, since I now have a couple of these to play with (and probably break ). Spare time is the missing ingredient at the moment.

Rick and @ahull

FYI. Just as a matter of interest, I flashed Ricks previous bin to my F103ZET board, and it enumerates fine as a BMP !

I don’t intend to use it as a BMP, but I accidentally flashed a HTML page to it, (I must remember right clicking and saving links to files in github does not save the bin file !!!)
So rather than leaving complete junk code in the board, I immediately flashed what I had to hand which was BMP !

I’ve been flat out with work recently and have had very little free time, so have not had time to wire up my C8 as a BMP yet, but I will hopefully have some time at the weekend

Rick,

I’m not sure why, but when I tried to apply your patch, I couldn’t get MinGW patch to patch the file

Basically it rejected the patch and didnt modify either file, it just spat our some .rej and also some orig files instead

But as it was a really small patch I’ve applied it my hand and I will push to the repo…

However I’m not sure it works on Windows.

I get these messages when I ran it

GNU gdb (GNU Tools for ARM Embedded Processors) 7.6.0.20140228-cvs
Copyright (C) 2013 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=i686-w64-mingw32 –target=arm-none-eabi”.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
0x8000004: 0x8000004 expect 0xffffffff after erase
COM3: No such file or directory.
“monitor” command not supported by this target.
Don’t know how to attach. Try “help target”.
Cannot access memory at address 0x8000004
“monitor” command not supported by this target.
Cannot access memory at address 0x8000004
C:UsersrclarkAppDataLocalTempbuild7632203454613856955.tmp/usb_test.cpp.elf: No such file or directory.
No executable file specified.
Use the “file” or “exec-file” command.
Cannot access memory at address 0x8000004
The program is not being run.
No symbol table is loaded. Use the “file” command.
Don’t know how to run. Try “help target”.
The program is not being run.
0x8000004: Starting program:

usb_test.cpp.elf uploaded!

I’m going to write a window batch file to handle this on windows, I suspect it would be best to do the same on Linux, as its far easier to do stuff in a script than in one line in platform.txt

[EDIT] I updated this to version 1 –
o modified command line args in platform.txt (boards.txt did not change)
o removed windows batch file usage
o tested successfully on both windows and linux, (nice if someone could try on OS/X
[/EDIT]
full boards.txt and platform.txt as a zip

patched_stm32f1_txt_v1.zip

(4.99 KiB) Downloaded 82 times

Hi Rick,

No worries

I’m just doing the ancilliary script for Windows, hopefully the Linux stuff will be left untouched.

I’m looking at the windows bat file now, but I don’t know if I will get it finished tonight, as its 9:45 already and I have to make an early start tomorrow ;-(

Edit.

Seems a bit better when I use an external script

This is the final command string that is being called

C:\Users\rclark\Documents\Arduino\hardware\arduino_stm32\tools\win>C:\Users\rclark\AppData\Roaming\Arduino15\packages\arduino\tools\arm-none-eabi-gcc\4.8.3-2014q1/bin/arm-none-eabi-gdb.exe -b 230400 -ex “set debug remote 0” -ex “set target-async off” -ex “set remotetimeout 60” -ex “set confirm off” -ex “set height 0” -ex “target extended-remote COM3” -ex “monitor swdp_scan” -ex “attach 1” -ex “x/wx 0x8000004” -ex “monitor erase_mass” -ex “echo 0x8000004 expect 0xffffffff after erase\n” -ex “x/wx 0x8000004” -ex “file C:\Users\rclark\AppData\Local\Temp\build8034241370519985939.tmp\sketch_may19a.cpp.elf” -ex “load” -ex “x/i *0x8000004” -ex “kill” -ex “tbreak main” -ex “run” -ex “detach” -ex “echo \n\n\n uploaded!\n” -ex “quit”

which strangely doesnt seem to give the same errors, even though the only fix up is the last slash in the elf file

I can’t fully test this, as I’ve not wired up my BMP to another board, I’m just running it on its own.

Anyway, I’ll commit the changes as they currently are, so you can check I’ve manually patched things correctly, and I’ll try to find time to wire up my BMP to another board tomorrow

Edit

I’ve pushed the changes

Rick, can you see if my manual patching is OK for you.

Cheers

Roger

I just cranked up a windows xp VM session. On windows xp at least the file name is wrong. It looks like it needs to be quoted. The BMP part seems to work fine if you give it the proper name. I’m not sure how to quote quotes in the Arduino build system platform.txt for windows. Although, thinking about it. If the file name had spaces in linux it would probably fail too.

Do you know much about the argument quoting in platform.txt?

Here is what it looks like on windows xp:

win32xp.png (69.58 KiB) Viewed 949 times

https://github.com/arduino/Arduino/issues/2052 .. hmm I’ll play around with this on windows and see what I can come up with.

-rick

RogerClark wrote:I’ve pushed the changes .. Rick, can you see if my manual patching is OK for you. …

Rick

Thanks

I will give that a try

Rick,

Can you confirm the electrical connections.

In one of your previous postings, you said it needs between 10k and 100k pullup and 22 ohms inline. with TCK and TDIO

However I’ve looked at the BMP schematics https://raw.githubusercontent.com/wiki/ … c_mini.pdf and and https://raw.githubusercontent.com/wiki/ … ic-1.0.pdf

and I can’t see anywhere on either schematic that has those resistors

Is this a later addition than the pdf’s that are on GitHub.

Edit.

I tried your new upload pattern and it seems OK on Windows 7

However I have not connected my C8 BMP to another board as I’m not sure about the connections.

BTW. I had something strange go on with the USB Enumeration on Windows. I plugged in my F103ZET board that still has BMP flashed to it, but Windows initially reported unknown USB device (just on device), so I disconnected and connected my by F103C8 board with BMP on it, and I got the same result.

So I connected my STLink to reflash the C8 board and Windows then decided it could see the BMP USB devices

and now when I disconnect and reconnect either board all the BMP usb devices are enumerating OK

It looks like enumeration may be a bit flakey, but I guess thats a small price to pay for using an unmodified board as a BMP

BTW. Looking at the schematics it looks like BlackSphere are using PA8 for USB enumerayion, as its 1.5k to USB D+ so looks suspiciously as USB re-enumeration hardware

[Edit] Note: read my later post before believing any of what I’ve wrote here
http://www.stm32duino.com/viewtopic.php … t=30#p1169

You do not need any resistors, inline or pull-down or pull-up. I’ve left this post here to
let you see how I had previously decided to suggest the use of them.

[/Edit] RogerClark wrote:
In one of your previous postings, you said it needs between 10k and 100k pullup and 22 ohms inline. with TCK and TDIO

RogerClark wrote:
So I connected my STLink to reflash the C8 board and Windows then decided it could see the BMP USB devices
and now when I disconnect and reconnect either board all the BMP usb devices are enumerating OK
It looks like enumeration may be a bit flakey, but I guess thats a small price to pay for using an unmodified board as a BMP

Ok, further investigation leads to more information.

I had looked at the BMP Native schematic and compared it to the STLink one and wondered why the BMP didn’t have any resistors.

I have been testing with with my jc66_coreboard on a breadboard. I hadn’t removed it from the breadboard before I started testing all this stuff. After a conversation in ##stm32 about the proper resistors for the SWD lines. They suggested that no resistors are needed. I pulled my jc66_coreboard with the BMP firmware off the breadboad and just connected the wires directly to my target board and it worked just fine.

So you probably don’t want your BMP board on a breadboard when you are trying all this out. If you do the capacitance on the breadboard might be causing issues. By the same token, if your target board is on a breadboard it might also cause problems.

The bottom line don’t use any resistors between the BMP and the target.

Thanks go to the ##stm crew!

[Edit] And here is why we don’t need pull downs and pull ups ( they are internal )
http://www.st.com/web/en/resource/techn … df#page=19
[/Edit]

-rick

I updated the zip file on the first post. I created a github fork project of the blackmagic code and made the source changes in the jc66_coreboard branch. See the first post of this thread for the url.

-rick

Rick

With the pull up or pull down

As the value of the pull-up is between 10 and 100k, is there any reason that the BMP code doesn’t use the internal pull up or pull down as required.

According to the page you liked to, TCK is always pulled pow, and TDIO always is pulled up.

I’m not sure why TCK needs to be pulled down, I didn’t realise it was bidirectional pin.
But I can see why TDIO needs to be either open collector or input pull up etc.

RogerClark wrote:I’m not sure why TCK needs to be pulled down, I didn’t realise it was bidirectional pin.
But I can see why TDIO needs to be either open collector or input pull up etc.

Hi Rick,

No worries

When I get chance I’ll try hooking it all together, but I’ve had some other non-Arduino stuff I’ve needed to do over the last few days

Cheers

Roger

RogerClark wrote:According to the page you linked to, TCK is always pulled pow, and TDIO always is pulled up.

I’m not sure why TCK needs to be pulled down, I didn’t realise it was bidirectional pin.
But I can see why TDIO needs to be either open collector or input pull up etc.

So more insight. Today I was loaded the code onto one of the blue generic stm32f103c8t6 boards. It didn’t enumerate after reset. In fact it didn’t enumerate after I unplugged it and plugged it back in. When I measured the resistance between (PA12) USBDP+ and 3.3v it is 10k .. instead of 1.5k ..

Does anyone have a schematic for these boards I didn’t see a transistor that might be used to control it. Hmm .. bummer.

-rick

My larger C8 board doesn’t enumerate either.

It’s probably got either no resistor or a high value.

Would it be possible to turn on the internal pull-up. I know its a high value ( I can’t recall what value), but the internal and external values in parallel may be enough to re enumerate.

Also how about putting the USB pin, (pa12) into push pull and driving it high

This is a false alarm. Now it is working for me.

I cleaned the board to make sure flux wasn’t any issue and now it works. But it still measures 10k .. so I have no idea what is going on there. On the red board I can identify the 1.5k resistor. On this board there is no 1.5k resistor in sight.

BTW: I’m talking about this specific blue pill board http://www.ebay.com/itm/321569700934

-rick

Rick

OK.

Shame the Blue boards are different from the red ones. Well, it actually sounds like there are red boards that exhibit the same traits as the blue boards or a mix of traits.

I would suggest that we post a picture of the boards that work, but… I know a lot of eBay vendors just use stock images, so there is no way to know for sure you will get whats in the picture, unless you pre-confirm with the vendor first.

Yeah I’ll take a picture of it. My board is actually different from the picture of the one the vendor displayed.
Dark here now. I’ll do it tomorrow.

-rick

I agree, most sellers are using “symbol photos”, but most of them have a big stock on the same boards.
Maybe it would help to post your “good board” sellers here?

Matthias

We could try the list of good sellers, but its possible they change stock, and don’t get the boards they think they get.

I had an issue I posted about with a “CC Debugger” clone, and the seller had 100% rating and had sold 8 others and no complains, but mine didnt have any firmware

Dont know if you already looked it up, but the internal resistors are 40K (30-50k), so yeah, bit higher.

~Straw

Did you find a schematic for that board? @strawberrymaker?

For the Probe? Internal resistance is from the 103×8 datasheet.
~Straw

You have me way confused. I’m not using the Blacksphere hardware. I’m using this board .. Just took a picture:

bluepill_top by Rick Kimball, on Flickr

bluepill_bottom by Rick Kimball, on Flickr

R10 .. is a 10k .. that is connected to VCC and PA12 (USBDP+)

the hole next to C6 is PA12.

Has anyone seen that voltage regulator before (U1) ? It seems puny.

-rick

Oh sorry, Didnt understand it. I have the blue pill and the big one which Roger uses too, guess Theres no need to make a New picture. Currently not available, will take a look at both pcbs when im back.

Dont know who is making U1, but i think its a 150mah one, (also Seen on arduino pro mini?)

~

Rick Kimball wrote:Has anyone seen that voltage regulator before (U1) ? It seems puny.

I updated the firmware and source files on the first post.

I also added a picture of the stm32c8t6 “Red Pill” board I’m using as the Black Magic Probe hardware and how you connect it to a target device. Re-reading what I originally wrote, it wasn’t obvious in the first few paragraphs which hardware I was using. Hopefully, you can see that now with pictures.

-rick

Rick can an st-link clone be used for Black Magic?
I am waiting on one to arrive. Would be great if I can swap the fw to a Black Magic, but I still don’t have it so I don’t even know what pins it uses.

EDIT: I see you are including the source, so hopefully the pins can be changed. I’ll check that pins are connected in the st-link clone once I get it.

Victor

I think the main issue with flashing BMP onto an STLink is access to the pins in order to program it.

My STLink looks like this

I can see 4 through holes, which may be for reflashing, as one of the wholes seems to have a track to PA14 which is SWD Clock.

As they are more expensive than the BluePill / red pill board and also don’t have access to PA9 and PA10 for USB Serial via the BMP’s own usb to serial driver, I’m not sure its worth buying one.

I know that Andy has a different STLink (in a box), so I wonder if that one is any better.
I think he has this one

Personally I’m going to flash BMP onto the Red Pill and use that.

victor_pv wrote:Rick can an st-link clone be used for Black Magic?
I am waiting on one to arrive. Would be great if I can swap the fw to a Black Magic, but I still don’t have it so I don’t even know what pins it uses.

EDIT: I see you are including the source, so hopefully the pins can be changed. I’ll check that pins are connected in the st-link clone once I get it.

RogerClark wrote:Victor

I think the main issue with flashing BMP onto an STLink is access to the pins in order to program it.

My STLink looks like this

I can see 4 through holes, which may be for reflashing, as one of the wholes seems to have a track to PA14 which is SWD Clock.

As they are more expensive than the BluePill / red pill board and also don’t have access to PA9 and PA10 for USB Serial via the BMP’s own usb to serial driver, I’m not sure its worth buying one.

I know that Andy has a different STLink (in a box), so I wonder if that one is any better.
I think he has this one

Personally I’m going to flash BMP onto the Red Pill and use that.

Funny .. while I think the BMP is the bee’s knees : ) .. I’d never sacrifice a working ST Link V2 to BMP … A V1 .. in a heart beat a V2.1 never ..

Rick Kimball wrote:Funny .. while I think the BMP is the bee’s knees : ) .. I’d never sacrifice a working ST Link V2 to BMP … A V1 .. in a heart beat a V2.1 never ..

Roger, those 4 pins are indeed for reflashing. This page has some information on what is each of them:
http://wiki.paparazziuav.org/wiki/STLink

I find it amusing that the whole stm32f103 environment has a red vs blue battle

Until some chinese clone shows up with a yellow or black PCB…

victor_pv wrote:Roger, those 4 pins are indeed for reflashing. This page has some information on what is each of them:
http://wiki.paparazziuav.org/wiki/STLink

From the link above, it seems that there are 4 pins too, so it probably there. (I didn’t received mine yet, maybe next week …)

Will have to check once I get it here. I may need to cut the traces to some of the duplicated pins (gnd, 3.3 or 5v) and wire them to the MCU pins directly.

You’d need to connect to PA9 and PA10 on the microprocessor to get Hardware Serial 1, which would be tricky.

I’m still not convinced that converting a STLink to a BMP is the best way to do it.

They are more expensive than a Maple mini, and apart from that they have a USB plug on one end (which I’m not sure is a benefit, as you’d probably need a usb extension cable to get the BMP in the same place on the bench as a board connected via a normal USB cable)

so I suspect flashing a Maple mini to a BMP is probably a better option.

Note. When reflashing a Maple mini, remember that boot1 floats by default, so if you are uploading via serial, you need to tie Boot1 to GND via 1k etc

It may not be, but I’m not too concerned about the uart part. I mostly want to get whichever working with GDB in Windows, so if I get the BMP fw in this board, I’ll give it a try to see what’s better, if BMP or ST-Link, then stay with one.

Victor

You don’t need to flash BMP to use GDB.

Texane provides the interface between GDB and stlink, which works with these clone boards

I’m thought I’d posted about how to run GDB via st-util , but let me know if you can’t find it and I will write it up again

I finally got around to soldering some pins on my maple mini clone and wiring it up so I can use it with BMP.

Red Pill board configured as a Black Magic Probe, Maple Mini as target:

maple_mini_bmp.jpg (218.33 KiB) Viewed 1114 times

I think
PA13 –> (SWDIO)
PA14 –> (SWCLK)

PA13 and PA14 are the SWDIO and SWCLK pins of the mcu, they cant be remapped (or?). The SWDIO and SWCLK pins are laid out on PA4 and PA5 and connect to the PA13 and PA14 Pin of the target MCU

~Straw

strawberrymaker wrote:PA13 and PA14 are the SWDIO and SWCLK pins of the mcu, they cant be remapped (or?).

Rick

I’m not suggesting this as an option, because I agree that if people choose a BMP STLink upload the debug pins should be enabled…

But, If anyone accidentally uploads code which turns the SWD pins into GPIO, you can still upload by running the stlink upload, and then press reset while its waiting to time out.

Obviously this is a pain for normal development, and I wouldn’t recommend it. But it’s what I used when working on the bootloader, because I needed to test that all the GPIO pins were available for the button or the LED

Rick, I recevied my st-link clone and have been using it fine.
So you think it is better keeping it as st-link?

I understand with BMP you get a server available as soon as you connect the device, while with st-link you need to run texane.
That is a point in favor of BMP. Is there anything that’s better on st-link?

BMP is limited to the chips it knows about. Luckily, for us that is all the stm32F10x chips. The texane stlink host code is also limited to the devices it knows about, which is limited to another set of STM32 devices.

If you pair your stlink device with openocd, you can use it to flash and program a much wider list of chips. I’ve used the stlink device with NXP LPC1114FN28 chips and LPC8XX, and some stm32f0xx chips just sitting on a pcb. The openocd crew is constantly adding support for new chips and jtag/swd devices. The only problem is you need to get a openocd binary, and this might become less of a problem now that the Arduino Zero is using openocd as its upload.

I’m using linux and openocd, I’ve added support for new chips openocd and new programmers didn’t support. The openocd is fairly well organized and adding support for new things usually just involved adding an entry to a table. Eventually, those chips and devices got supported and I could just use the stock code. The texane stuff, is more a hack when it comes to how they handle a lot of the responses to gdb rsp and devices. Although you can certainly get lost using the openocd vs texane. Texane is simple and openocd is more complex but flexible.

I think you have a lot more choices if you just leave it as a stlink device. But if you only plan to use the BMP device with this port. It certainly removes having to deal with either openocd or texane on the host side. All you need is arm-none-eabi-gdb.

-rick

oh man, no more options… I just want something simple that works at once…
I’ll just leave it as st-link for the time being.

Another small change …

I just tweaked the speed settings on the SWDIO and SWCLK pins. I lowered it from 50MHz to 10MHz. 50 was working fine with my maple mini clone and my red pill/blue pill boards. However, I tried using this with an old stm32vl discovery board. It was failing intermittently. I lowered the speed and those problems went away. I guess it was driving the slew harder than it needed to.

Those value line discovery boards have some issues. It has an STLink V1 interface and they are a pain on linux, as they try and create a mass storage device and linux has issues with how it is done. The target chip is the stm32f100rbt6, a lower price point version of the cortex-m3. It doesn’t have much going for it though. It only has 8k of RAM and runs at 24MHz max, although I was able to run it at 48MHz and it did seem to work. I guess the only good thing about it is a couple of DAC peripherals, and all of its pins are broken out. Oh and yeah, this board is used in the Indiana University Computer Science course:

http://www.cs.indiana.edu/~geobrown/book.pdf

https://github.com/geoffreymbrown/STM32-Template

I pushed my minor changes to the github source.

-rick

Oh and yeah, this board is used in the Indiana University Computer Science course:

http://www.cs.indiana.edu/~geobrown/book.pdf

https://github.com/geoffreymbrown/STM32-Template
@rick:

Thx for the link.

Ray

I’m trying to score github link brownie points ; )

victor_pv wrote:Rick, I recevied my st-link clone and have been using it fine.
So you think it is better keeping it as st-link?

I have 2 different STLink adaptors, one in an aluminium case which you can slide off over the USB connector

I took a look at the internals and I think the 4 solder pads on the board are for programning it via another Stlink adaptor, as I don’t think they connect to PA9 and PA10 to do a serial upload

If you don’t have another Stlink to program it with, but you have a USB to Serial adaptor, I think you’d need to solder some small wires directly to PA9 and PA10 on the chip, and also put a wire on Boot0

alex wrote:victor_pv wrote:Rick, I recevied my st-link clone and have been using it fine.
So you think it is better keeping it as st-link?

victor_pv wrote:alex wrote:victor_pv wrote:Rick, I recevied my st-link clone and have been using it fine.
So you think it is better keeping it as st-link?

RogerClark wrote:
I took a look at the internals and I think the 4 solder pads on the board are for programning it via another Stlink adaptor, as I don’t think they connect to PA9 and PA10 to do a serial upload

Thanks Alex

Its good to have that as reference.

RogerClark wrote:Thanks Alex
Its good to have that as reference.

ok.

i will check

alex wrote:

I have two blue pills already. They can be easily turnned into “st-link” just by connect B12 and B14 with a 100Ω resistor, flash st-link fw into it, B13 is SWCLK, B14 is SWDIO. I even made a adapter for it, I also modified the BMP source to use B13 and B14 for SWD, so I can use the same “diy adapter”.

But st-link clones are cheaper than the pills in my universe. Clone is about 13.5 CNY, and blue/red pill is about 20 CNY.

I use BMP mainly for semihosting to get rid of usb-ttl adapter, st-term is alse a choice for me.

victor_pv wrote:
Yeah the price in the st-link clones is almost unbeatable, in part because they use STM32F100 rather and F103.
I am sure the BMP firmware can be adapted and flashed to it, but is it worth the trouble having to solder extra wires etc for the small price difference to get a red/blue pill?
I see them in taobao for just 17cny:
https://item.taobao.com/item.htm?spm=a2 … t=4#detail

And there are even better boards for just as cheap:
https://item.taobao.com/item.htm?spm=a2 … t=4#detail

Personally, unless you need a bunch of BMP, and converting the st-link can be done with no soldering at all, I dont think it’s worth the time, you time is probably more valuable used on something else.

@alex

I think it would be more fun to load the bootloader onto the stlink

The LED seems to be on PA9, and there appear to be 4 usable GPIO pins on routed to the connector at the end. I’m not sure if thats enough to do very much. You could connect a I2C periperal to 2 of those pins, or perhaps use them as analog inputs, e.g. some sort of mini data logger etc.

alex wrote:
Using stlink as BMP is for tidy.
It very quik to convert the stlink to BMP, no soldering at all, just to make a 2.54 to 1.27 4 pins adapter first (in fact I already have one before for somethings else). Tools can save time.

to RogerClark: Do you mean load different firmware by usb for different usage? how to do that ?
to victor_pv: Usart is not available, you need to solder to A2 A3, but the good news is they are at corner.

BTW

My STLink, which is in the same metal enclosure is a F103.

Re:Alternative software.

I mean use it as an Arduino. Flash the bootloader using another STLink board.
Not you can flash most F103 boards with the STlink binary to make them into an STLink board.
The binary for stlink is on various russian websites

RogerClark wrote:BTW

My STLink, which is in the same metal enclosure is a F103.

Sorry,

I double checked. Both of my are F101’s

Different boards, one is in the metal case, the other does to have a case

I wonder what the difference is between the F101 and the F103. I know the STLink binary works on the F103 boards, but I suppose that makes sense, as I presume the F103 is a better device than the F101

Edit.

I’ve just looked at the spec on the F101 and one key difference is the clock speed of 36 instead of 72Mhz. I’m not sure if there is anything in the bootloader which would prevent it working on the F101, and of course the core is generally set to 72Mhz, and I’m not sure whether if that value was changed in the core, whether it would work either, as we’ve never tried

Given that the F103’s are so cheap, I guess its hardly worth messing around with getting Arduino etc onto these F101 board (unless they were $1 or something).

RogerClark wrote:Sorry,

I double checked. Both of my are F101’s

Different boards, one is in the metal case, the other does to have a case

I wonder what the difference is between the F101 and the F103. I know the STLink binary works on the F103 boards, but I suppose that makes sense, as I presume the F103 is a better device than the F101

Edit.

I’ve just looked at the spec on the F101 and one key difference is the clock speed of 36 instead of 72Mhz. I’m not sure if there is anything in the bootloader which would prevent it working on the F101, and of course the core is generally set to 72Mhz, and I’m not sure whether if that value was changed in the core, whether it would work either, as we’ve never tried

Given that the F103’s are so cheap, I guess its hardly worth messing around with getting Arduino etc onto these F101 board (unless they were $1 or something).

Victor

Umm.

Does that mean that these F101’s in the STLink adaptors are possibly F103’s ?

They are the same package, I really can’t see how its worth them making the 101 as well as the F103

RogerClark wrote:Victor

Umm.

Does that mean that these F101’s in the STLink adaptors are possibly F103’s ?

They are the same package, I really can’t see how its worth them making the 101 as well as the F103

Victor

Yes. I read the other day, the clock must be 48Mhz or 72Mhz for usb to work, as the USB clock speed is 48Mhz, and the F103 has 2 divider modes from the main clock, either divide by 1 or divide by 1.5

Well, I’ve managed to erase my new STLink but I can’t see to reprogram via STLink

STLink will connect to the other STLink and reads this data

17:29:31 : Device ID:0x410
17:29:31 : Device flash Size : 128KBytes
17:29:31 : Device family :STM32F10xx Medium-density

However as soon as I try to program the device, STLink has an error and it disconnects.

I’m not sure if this is because both devices are connected to USB, and perhaps it would be better if I disconnect the target board from USB and just use the power and ground from the programmimg STLink, but this seems somewhat unlikely

However I’ll give it a go.

Edit.

OK. When I disconnected the STLink board from USB and powered it from the other STlink board, I was able to program it.

I installed the generic bootloader and the device appeared as a Maple DFU device, and I was able to upload the blinky sketch and which also prints to USB

So the STM32F101 microcontroller seems to work perfectly as a 128k STM32F103CB !

Victor you were soooo right

The new cheapest Arduino on STM32 looks like its the STLink dongle !
LED is on PA9

You beat me to it. I was in the process of modifying a 0.1″ header to use as a probe by bending the pins in to the correct spacing for the smaller header on my purple programmer yesterday, but real work inconveniently got in the way. I might continue with this when I’m back in the office next week.

Did you manage to read the existing flash before firing on the new program?

Have you thought of any projects that would benefit from the tiny USB dongle form factor?

I presume that this means that at 2.11 GBP (3.29 USD) this is the cheapest stm32duino on ebay… auction prices not withstanding.

With the Blue Pill costing not much more, having a RTC resonator and all the pins broken out for an extra 40 pence makes the StlinkV2 programmer less attractive, except where the project lends itself to the tiny case and low pin count.

However the “because you can” factor means I feel compelled to find some use for the programmer as stm32duino.

ahull wrote: You beat me to it. I was in the process of modifying a 0.1″ header to use as a probe by bending the pins in to the correct spacing for the smaller header on my purple programmer yesterday, but real work inconveniently got in the way. I might continue with this when I’m back in the office next week.

Did you manage to read the existing flash before firing on the new program?

Have you thought of any projects that would benefit from the tiny USB dongle form factor?

I presume that this means that at 2.11 GBP (3.29 USD) this is the cheapest stm32duino on ebay… auction prices not withstanding.

With the Blue Pill costing not much more, having a RTC resonator and all the pins broken out for an extra 40 pence makes the StlinkV2 programmer less attractive, except where the project lends itself to the tiny case and low pin count.

However the “because you can” factor means I feel compelled to find some use for the programmer as stm32duino.

I suspect that will depend on what price they are purchasing the 101 and 103 at, if there is little to choose between the two, then whichever makes the most profit is the one they will go for. More likely however is that some clever clogs will start laser etching 103cbt6 on the 101c8t6 chips and flogging them for the higher price.

ahull wrote:I suspect that will depend on what price they are purchasing the 101 and 103 at, if there is little to choose between the two, then whichever makes the most profit is the one they will go for. More likely however is that some clever clogs will start laser etching 103cbt6 on the 101c8t6 chips and flogging them for the higher price.

Guys

I just soldered 2 small wires to my board, which i have now removed, as i can now upload via the bootloader.

I added a “generic-pa9” version to the bootloader to support this board
So the led on my board now flashes like it should.

Re:Readback

No. It was read locked.

There must be something in the STLink binary which sets the read disabled flag, as even if you download the stlink binary from those russian websites, and flash it into a F103, as soon as it starts running, you are no longer able to read the contents of flash back out.

I suspect it would be easy to hack the binary to prevent it doing this, i.e just look in the binary for the address of the locking register and change it for an address in ram.
That is… unless it checksums its self, but as its updates are uploaded in an encrypted form the devs may not have bothered to do that.

Overall, its not really worth messing around with the Stlink binary, as Black Magic Probe does as least as good a job and is open source.

I don’t really see much use for this board, unless someone had an application for something with very low pin count.
Perhaps a small data logger.

I dont know what pins it uses for its outputs on the connector at the end. I cant seem to find a schematic for the dongle version of the stlink, i can only find diagrams for the stlink on the discovery boards.

Anyway if the pins have analog capabilities, perhaps it could be used as a cheap data logger.

The other thing that this sort of device could be used for is for some basic form of encryption, e.g Rot13, just get the Serial USB to echo back Rot 13 versions of the incomming chars.

Or secure micro storage e.g keep your passwords in it. send the website address in via serial and it looks them up and sends back the username and password for that website.

Re: laser etching a different code.

Ive noticed that its very hard to read the markings on the devices on the stlink dongles.
I had to use a 10x eye glass, and hold it to bright sunlight, and look at an oblique angle to see it was an F101

Its like they made a half hearted attempt to remove the markings already.

Anyway, I guess the thing to do would be to test the RAM size as F101s have either 10 or 16k RAM not 20k, and to see if it has more than one USART, in which case its almost certainly a 103 in disguise

RogerClark wrote:

I dont know what pins it uses for its outputs on the connector at the end. I cant seem to find a schematic for the dongle version of the stlink, i can only find diagrams for the stlink on the discovery boards.

Victor

The only official schematics i can find are the ones for the discovery and nucleo boards, but the firmware on the Nucleo stlink is definitely not the same as on the Discovery as it also has USB serial.

I think the stlink software reads some version information and uses this to download the correct binary for the target board.

So i cant really guarantee that the schematics for the Discovery stlink section is the same as the dongle.
I did find this

http://www.micromouseonline.com/wp/wp-c … ink-v2.png

But it doesn’t seem to include the Reset line that the dongle has.

However i could test the Sdio and Sclk pins

RogerClark wrote:Victor

The only official schematics i can find are the ones for the discovery and nucleo boards, but the firmware on the Nucleo stlink is definitely not the same as on the Discovery as it also has USB serial.

I think the stlink software reads some version information and uses this to download the correct binary for the target board.

So i cant really guarantee that the schematics for the Discovery stlink section is the same as the dongle.
I did find this

http://www.micromouseonline.com/wp/wp-c … ink-v2.png

But it doesn’t seem to include the Reset line that the dongle has.

However i could test the Sdio and Sclk pins

How to load STLink binary to stlink with a BMP? In case I need it, gdb does not recognize the “STLinkV2.J16.S4.bin” file.

alex wrote:How to load STLink binary to stlink with a BMP? In case I need it, gdb does not recognize the “STLinkV2.J16.S4.bin” file.

RogerClark wrote:alex wrote:How to load STLink binary to stlink with a BMP? In case I need it, gdb does not recognize the “STLinkV2.J16.S4.bin” file.

@victor_pv You can’t load stlink fw to a stlink by usart directly since there’s no pads.
The only work order is:
1. Load stlink fw to blue/red pill by usart.
2. Load stlink fw to stlink by “blue/red pill stlink”.
So it’s a litte trouble. Maybe the best way is to buy another stlink.

alex wrote:How to load STLink binary to stlink with a BMP? In case I need it, gdb does not recognize the “STLinkV2.J16.S4.bin” file.

Rick Kimball wrote:alex wrote:How to load STLink binary to stlink with a BMP? In case I need it, gdb does not recognize the “STLinkV2.J16.S4.bin” file.

alex wrote:Rick Kimball wrote:alex wrote:How to load STLink binary to stlink with a BMP? In case I need it, gdb does not recognize the “STLinkV2.J16.S4.bin” file.

I decided that years of Ram Pack Wobble experience suggested the best bet if I wanted to mess with the ST-Link V2 probes internal header was to solder the wires on rather than attempt to hold a tiny header in place.. This was relatively painless, but I did need a good magnifier, and almost set my hair on fire because my face was so close to the soldering iron while I was working.

Not perfect, but not bad… It was only once I had finished the job that I realised I probably didn’t need to solder on the 3V3 and GND leads as I can access those signals on the jtag header.

More pictures here if anybody is interested.

Unfortunately since my other ST-Link V2 probe is at home, I can’t probe the probe at the moment.

link is 403 Forbidden – No Permissions

i stll keep trying to add images with file:///home/stephen…….

stephen

zmemw16 wrote:link is 403 Forbidden – No Permissions

i stll keep trying to add images with file:///home/stephen…….

stephen

For the record, (and this may have been mentioned before), you can upgrade a Generic ST-Link V2 clone with the utility on ST’s website here… – I have just verified that this works with Linux. Upgrade takes the probe to V2j24s4 released 22-Jul-2015 – see here for details.

ahull wrote:For the record, (and this may have been mentioned before), you can upgrade a Generic ST-Link V2 clone with the utility on ST’s website here… – I have just verified that this works with Linux. Upgrade takes the probe to V2j24s4 released 22-Jul-2015 – see here for details.

I managed to update all my STLink devices, as well…

Buy I have since installed the bootloader on my aluminium cased one.

Can I trust my eyes? Is ST going to supportn more and more Linux and OSX?

alex wrote:How to load STLink binary to stlink with a BMP? In case I need it, gdb does not recognize the “STLinkV2.J16.S4.bin” file.
GDB has a “restore” command.
https://sourceware.org/gdb/onlinedocs/g … Files.html

(gdb) restore ../STLinkV2.J16.S4.bin
‘../STLinkV2.J16.S4.bin’ is not a recognized file format.
(gdb) restore ../STLinkV2.J16.S4.bin binary
Restoring binary file ../STLinkV2.J16.S4.bin into memory (0x0 to 0x10000)
warning: restore: memory write failed ((undocumented errno -1)).
(gdb) restore ../STLinkV2.J16.S4.bin binary 0x8000000
Restoring binary file ../STLinkV2.J16.S4.bin into memory (0x8000000 to 0x8010000)
Writing to flash memory forbidden in this context
(gdb)

nice trick

i finally got a sketch running under the debugger with serial output, not entirely sure how:-)
thanks rick.

what i have found is that for anything more than blink (just need to insert #include <Arduino.h> in the cpp file) it gets interesting, mainly with SPI and ‘standard’ definitions(PA4 etc).
i’m using the using-spi-ports example with my additions, heading towards a driving nokia 5110 (my success with adafruit_gfx_as is really, really non stella)
waggles are for my ols.

can anyone list the various headers needed for spi/i2c, the sequence and where they need to go, wrapper or cpp?
so i’m currently relying on the #ifndef’s for blocking a reload of the header files.
i’ve played with various commenting out of the headers. keeping all works, may well be overkill.

stephen

the wrapper is
#include <Arduino.h>
#include <SPI.h>
#include "using_SPI_ports.cpp"


zmemw16 wrote:nice trick
<…>
i’m using the using-spi-ports example with my additions, heading towards a driving nokia 5110 (my success with adafruit_gfx_as is really, really non stella)
<…>

Rick,

I tried to Flash you BMP binary onto a GD32, but it didnt work.

But now that I think about it….. Its impossibe for it to work because the Xtal is 12Mhz instead of 8Mhz, so all the PLL’s will be wrong for it to enumerate on USB. (The USB prescaler PLL also has 2 bits instead of 1 bit on the STM32)

If I get time, I”ll download all the sources and see if it will Make on my Windows PC (As I make the stm32duino bootloader using my Windows PC, so I should have an equivalent setup)

In the mean time I’ve flashed it onto a STM32 to I can take a look at if it can see the RNF51822

Thanks

Roger

Rick,

This is probably a really dumb question,but here goes.

If cloned your repo then ran git submodule update to get the libopencm3, however it won’t make because the code can’t find the stm32 directory in libopencm3

I just went into src and then ran make, but possibly because I’m trying to do this on Windows, it seems to have something missing from the path, as it is looking in libopencm3/stm32/…. but the actual structure appears to be libopencm3/lib/stm32/…

Do I need to Make libopencm3 ? (Its not that easy for me to do that as I’d need to sort out the Python stuff on my machine)

Or is there something else I’ve missed?

run the make from the top level directory. it will do the git submodule stufffor you

Rick,

Thanks.

I’m not sure why I didnt see the top level makefile after I cloned your repo.

I perhaps I was just having a bad day.

Update

OK. I figured out why I didnt run the top level make file… It was because it was using Python, which I didnt have setup for command line usage.

So I’d manually run the git submodule update stuff, but when I ran make on both libopencm3 and the src folder, I’d not included the correct make options as specified in the top level make file.

Anyway. I can now make the code, but the resulting bin doesnt work on my RedPill, but your binary does.

You bin file is 49k but mine is 65k

I’m using the ARM compiler installed by the Arduino IDE, I just set the Windows PATH ENV to include it.

I’m on the jc66_coreboard branch, and I”m running make from the top level and don’t get any errors.

I guess the first thing I should try and do is recompile on Linux. Can you let me know your setup for gcc on Linux, as although I could use the one from the Arduino IDE, I’d rather use whatever you used, in case this is some sort of library issue

Thanks

Roger

I have the linaro arm-none-eab-gcc binary for linux version 4.8.4 in my path:
$ arm-none-eabi-gcc --version
arm-none-eabi-gcc (GNU Tools for ARM Embedded Processors) 4.8.4 20140725 (release) [ARM/embedded-4_8-branch revision 213147]

Rick

Thanks.

I will try setting the probe host.

I didnt do that before, as it looked like you had created a branch in your repo which defaulted to those files.

But its possible it still effects the build process.

I will let you know how i get on

thanks

roger

yes I originally had changed the PROBE_HOST value in the Makefile in my branch. However, it takes less effort on my part to use their Makefile if I want to easily get in synch with the master branch. Sorry.

Success

Thanks

make PROBE_HOST=jc66_coreboard all

Rick,

FYI.
I just posted about Arduino on the nRF51822 , being available

viewtopic.php?f=45&t=682

However I’m not sure if its reliant on Red Bear hardware

If it’t not too much to ask: what is the status of BMP on generic ST32F103[CR][8B]’s?
I’ve been going through this thread, but am having some difficulty distilling the answer to that question.

jcw wrote:If it’t not too much to ask: what is the status of BMP on generic ST32F103[CR][8B]’s?
I’ve been going through this thread, but am having some difficulty distilling the answer to that question.

jcw wrote:If it’t not too much to ask: what is the status of BMP on generic ST32F103[CR][8B]’s?
I’ve been going through this thread, but am having some difficulty distilling the answer to that question.

Just a note.

The C8 generic board shown in the posting in the first link is junk. (aka the Ugly board)

I find it unreliable and have given up using it.

I know some people get it to work, but personally i would not recommend it.

Thanks, R & R.

@Roger – I’m not sure why that “Ugly Board” is being so, eh, ugly to you. I had one lying around and re-flashing Rick’s build onto it seems to work – well, at least it shows up on USB (on Mac). I did have to change the jumpers: outermost one is towards the corner, but the inner one is away from the board edge.

Now I’m wondering whether PA8/PA9 serial can also be used.

Update – confirmed, this unit seems to work.
Update #2 – serial pass-through also works, on PA2/PA3, as documented.

Perhaps mine has a component fault.

I know some of them work, but a lot seem to fail to start.

Actually I think the issue is that the HSE clock (external crystal clock ) fails to start first time.

The libmaple core doesn’t include any checks to see if the HSE has started, it just hangs while waiting.

I suspect the BMP code handles this correctly and retries starting then HSE, which then works Ok.

The HSE timeout and restart is on the bottom of a long ToDo list for me

I’ve tried to use the BMP to flash a Nordic nRF51822, and gdb seems to accept all the commands, but it doesnt seem to actually write the sketch to flash.

I’ve adapted Ricks platform.txt gdb commands and removed the STM specific memory reads, and have also manually typed and executed the commands, but with no luck so far.

On Windows I have 2 other issues.
1. The COM port seems to need to be preceded by \\.\ , as described I think in BMPs own wiki
2. On the nrf51, the quit command is not getting executed by gdb, so gdb ends up
locking up the BMP, and the only way to release is to reboot the pc, or to remove the target power or one of the SWD lines.

I will need to see if I have the same issues with quitting when targeting the stm32.

However I’ve no idea why the nrf51 is not getting flashed by the load command.
The bmp is supposed to support the nrf51 series.

BTW. mass erase is not available in the gdb commands for the nrf51, although mass erase is available on the mcu, ( as openocd does it via the. nrf51 mass_erase. command

I dont think the flash is being erased at all, as after Its supposedly flashed and running, I still see the debug messages from the exiting ( different ) sketch.

The \\.\ stuff is due to COM port numbers above 9 (or 4?), I think. Gdb (cygwin?) doesn’t recognise “COM<n>” as a special name (which is a horrible Windows anachronism, if you ask me – try creating a file named “COM3” …).

Indeed, I’d try this on an F1 first. Perhaps you have to update your BMP to get the latest chip support.

Never a dull moment, eh? 🙂

jcw wrote:Indeed, I’d try this on an F1 first.

Ok

I will try again on an F1 to prove its not some other problem.
Which could be the case as I’m using a GD32 board, but all I changed was the line in the source that specified it had a 12mhz crystal instead of the 8mhz on the normal SMT32F103 boards.

i.e I’m still running it at 72Mhz and didnt go the whole way and changed the USB prescaler and push it up to 120MHz.

It definitely connected to the F1, and gdb shows all the signs that its working, scan of devices recognizes it as a CortexM0 device etc and attaches OK.

I do get some notices / warnings e.g. cant read target voltage, and a few other messages, but I get the same sort of thing using OpenOCD and an STLink adaptor to flash the same module, and it does flash OK with STLink.

I guess I could try running the Texane STLink server and see if GDB can flash using that method, but I’d really like to use the BMP as it provides serial as well as SWD, and also its self contained, i.e you don’t additionally need the OpenOCD binaries ( and as yet I cant find a way to script OpenOCD to do the upload unless I pipe a script in via Telnet ( which gets very messy)

As I rebuilt from your github sources less than a week ago ( so I could use the GD32) it should all be up to date with the nRF51 stuff, but I guess I could post an issue / question on the main blacksphere repo to see if there are any known nrf51 issues.

If you use the gdb command ‘monitor help’, does an option show up for mass erasing the NRF51? It should. Of you course you have to do this after you have done the ‘monitor swdp_scan’ and the ‘attach 1’

FWIW, here’s example output with an STM32F103:

(gdb) tar ext /dev/cu.usbmodemD5D4C5E1
Remote debugging using /dev/cu.usbmodemD5D4C5E1
(gdb) mon swdp
Target voltage: Not Implemented!
Available Targets:
No. Att Driver
1 STM32F1 medium density
(gdb) at 1
Attaching to Remote target
0x080013ac in ?? ()
(gdb) mon help
General commands:
version -- Display firmware version info
help -- Display help for monitor commands
jtag_scan -- Scan JTAG chain for devices
swdp_scan -- Scan SW-DP for devices
targets -- Display list of available targets
morse -- Display morse error message
connect_srst -- Configure connect under SRST: (enable|disable)
ARM Cortex-M specific commands:
vector_catch -- Catch exception vectors
STM32 LD/MD specific commands:
erase_mass -- Erase entire flash memory
option -- Manipulate option bytes
(gdb)

RogerClark wrote:I do get some notices / warnings e.g. cant read target voltage, and a few other messages, but I get the same sort of thing using OpenOCD and an STLink adaptor to flash the same module, and it does flash OK with STLink.

I actually had the voltage reading coded and then ripped it out as you needed to provide some external circuitry. It isn’t required so I tanked it.

No worries.

FYI.

I just modified the STM32 upload pattern, and just removed the code that displayed the memory locations, and to solve the COM issue i had with the double digit COM port issue

tools.bmp_upload.upload.pattern="{path}{cmd}" -cd "{build.path}" -b {upload.speed} {upload.verbose} -ex "set debug remote 0" -ex "set target-async off" -ex "set remotetimeout 60" -ex "set mem inaccessible-by-default off" -ex "set confirm off" -ex "set height 0" -ex "target extended-remote \\.\{serial.port}" -ex "monitor swdp_scan" -ex "attach 1" -ex "file {build.project_name}.elf" -ex "load" -ex "tbreak main" -ex "run" -ex "echo \n\n\nUpload finished!" -ex "quit"


Can you post the exact output? Most useful would be doing it in stages by hand at first from the command line

0.) launch arm-none-eabi-gdb

1.) Connect .. make sure you are connected
target extended-remote \\.COM9
monitor swdp_scan
attach 1

2.) Examine memory where you expect to write
(gdb) x/4x 0x20000000

look to see if the memory where you are going to write, address 0x20000000 in the case above, is empty (0xffffffff)

3.) Try erasing memory
(gdb) monitor erase_mass

go back to step 2 and see if it is erased

Turning it up to 11 might be a little too adventurous to start with.

-rick

I dont think mass_erase is supported

But I’ll try again just be sure

It should be:

https://github.com/RickKimball/blackmag … rf51.c#L44
https://github.com/RickKimball/blackmag … f51.c#L208

umm

I’m sure that didnt work last time I tried it

Perhaps it doesnt know its an nRF51

How do I tell GDB what process it is, perhaps the version info in the chips don’t match what BMP / GDB expect ? I know there are multiple versions of nRF51 though I’m not sure what the AAxx letters at the end of the part number actually mean.

Its saying that mass_erase is not supported

GNU gdb (GNU Tools for ARM Embedded Processors) 7.6.0.20140228-cvs
Copyright (C) 2013 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=i686-w64-mingw32 --target=arm-none-eabi".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
(gdb) target extended-remote \\.\COM38
Remote debugging using \\.\COM38
(gdb) monitor swdp_scan
Target voltage: Not Implemented!
Available Targets:
No. Att Driver
1 ARM Cortex-M
(gdb) attach 1
Attaching to Remote target
warning: while parsing target memory map (at line 1): Required element <memory> is missing
0x00002fa0 in ?? ()
(gdb) monitor mass_erase
Target does not support this command.
(gdb)


BTW. In the longer term its better if we don’t do mass_erase, because the way the nRF stuff is implemented it has sort of library, which they call a SoftDevice, which sits in the bottom part of the flash, which basically does some small init and then jumps to the start of the first flash page after the SoftDevice flash memory

In the case of the “S130” Softdevice, that address seems to be 0x1C00 (the S110 Softdevice is smaller, but the code I’m currently using, is pseudo linking against the S130 sofdevice / library)

From what I’d read about the BMP, the “load” command was suppose to pre-erase the pages necessary, before flashing.

However I suspect if it doesnt know its an nRF51 that none of this stuff is happening

As a matter of interested, I looked at 0x1c00

(gdb) x/4x 0x1c000
0x1c000: 0x20004000 0x0001c789 0x0001c7c5 0x0001c7c7


RogerClark wrote:Perhaps it doesnt know its an nRF51
How do I tell GDB what process it is, perhaps the version info in the chips don’t match what BMP / GDB expect ? I know there are multiple versions of nRF51 though I’m not sure what the AAxx letters at the end of the part number actually mean.

Is there a command to read the ID?

so use an ST-Link to debug your BMP device connected to your NRF51 … a very James Taylorish looking in my review mirror moment.

Or give me a couple of days and I should have the carrier board and I can connect up my own and figure it out:

http://i66.tinypic.com/20az9yh.jpg

* you could also use 2 BMP devices to figure this out, one debugging the other.

RogerClark wrote:Is there a command to read the ID?

Rick

I actually just looked an it seems that the device ID register is at 0x1000005c

https://devzone.nordicsemi.com/question … gh-segger/

and in the BMP code this seems to be just shown as 0x5C so I guess they are the same

anyway, reading that address gives

(gdb) x/4x 0x1000005c
0x1000005c: 0xffff0084 0xa1ff477e 0xfdf8eecc 0xffffffff
(gdb)

nice, you seem to have the QFAC chip. 256/32

I updated the code for 0x0084 and pushed it to github.

Yes

It seems to have QFACAA printed on it

I think both the modules i have, are contain the same chip

I have ordered a motherboard, and it comes with another module board (well I chose to buy a motherboard that came with a module so that I’d have 3 of them)

I’ve actually found some cheaper modules, which would be more practical to use in actual real world scenarios, and which are a bit cheaper

http://www.aliexpress.com/item/10pcs-lo … 69314.html

But for dev they would need a breakout board

LOL

I was just about to post this

target_add_ram(t, 0x20000000, 0x8000);

But I’ll see what you did

Edit

I pulled your changes

I thought it was 32k ram ???

Not that it will affect the upload

Arrggg

Made and flashed it but forgot to set

PROBE_HOST=jc66_coreboard all

So USB didnt work

So I’ll have to reconnect it all and reflash it again

PS. It a rare event but I”ve turned on IRC

OK

Some progress

Its now recognised as the NRF51

(gdb) monitor swdp_scan
Target voltage: Not Implemented!
Available Targets:
No. Att Driver
1 Nordic nRF51
(gdb) attach 1
Attaching to Remote target
0x00002fa0 in ?? ()

you can ‘load’ .elf files. to upload a .hex you need to use ‘restore’

(gdb) help restore
Restore the contents of FILE to target memory.
Arguments are FILE OFFSET START END where all except FILE are optional.
OFFSET will be added to the base address of the file (default zero).
If START and END are given, only the file contents within that range
(file relative) will be restored to target memory.
So …
(gdb) restore blink.hex


RogerClark wrote:PS. It a rare event but I”ve turned on IRC

lol

Command is erase_mass not mass_erase

Sorry, its my dyslexia (well kind of, as I’m not really dyslexic )

I’ll see if it gets erased

Edit

address 0 seem to have ffff

umm

Seems to load the ELF file OK and the memory at 0x01c000 seems to look like the start of the bin file that was also created by the IDE

Ah.

Looks like it is kind of working.

If I manually load the SoftDevice and then manually load the sketch

I’ll try changing the sketch

Edit. Just to close off this chapter…

The latest BMP code in Rick’s repo worked with my nRF51822 (32k) device !

Rick,

2 things really

(a) BMP on Maple mini.

Any ideas on if its that invasive to change the code so that it uses the Maple hardware to reset the USB ?
(Actually I don’t know how you did it on the Blue Pill, I presume you used the GPIO USB D+ method

(b) Following on from (a)….

If we can run it on the Maple mini, I presume we can change the Vector table address and also the loader file and load the BMP via DFU into a Maple mini while still retaining the bootloader.

i.e Have this for an option for people who are not comfortable with flashing their Maple mini over to BMP using external USB to serial etc.

Either way. I think adding support for the Maple mini board would be a benefit as the Maple mini boards are physically much more robust than the Blue Pill.

Personally I don’t buy Blue Pills any more, I’d rather spend the extra couple of dollars and have a better made more reliable board.

Funny I was actually thinking about spinning a maple mini …

Rick Kimball wrote:Funny I was actually thinking about spinning a maple mini …

Rick,

One minor annoyance, which I don’t know if it occurs on the STM32

If I disconnect the BMP (connected to the NRF51) and reconnect.

The default condition seems to be that the BMP halts the nRF51. The only way to get it to run without uploading again, is to pull one of the SWD wires off.

Even if I reconnect or power cycle the nRF51 (but removing its power wire from the BMP), it still goes into halt

I’ve not disconnected it and connected it to a STM32, so I don’t know if it does the same thing, but either way, I probably need to modify it, so it doesn’t default to halting the processor like this.

You should be able to issue the ‘run’ gdb command to restart without reloading

Yes. I could, but it still means I have to fire up gdb and connect to the board, albeit I could write a script to do it.

Update.

I think I have fixed my issue of the target board being halted on powerup.

If I change the code so that the SWD and SDIO pins are not driven low in the platform_init code e.g. change _clear to _set
like this
/* Setup GPIO ports */
gpio_set_mode(SWDIO_PORT, GPIO_MODE_OUTPUT_10_MHZ,
GPIO_CNF_OUTPUT_PUSHPULL, SWDIO_PIN);
gpio_set(SWDIO_PORT,SWDIO_PIN);

gpio_set_mode(SWCLK_PORT, GPIO_MODE_OUTPUT_10_MHZ,
GPIO_CNF_OUTPUT_PUSHPULL, SWCLK_PIN);
gpio_set(SWCLK_PORT,SWCLK_PIN);

gpio_set_mode(LED_PORT, GPIO_MODE_OUTPUT_2_MHZ,
GPIO_CNF_OUTPUT_PUSHPULL, LED_IDLE_RUN);

Odd – I don’t see this behaviour on my various BMP incarnations.
There’s also a “detach” command in gdb, perhaps that’s of use?
BTW, I’m using this with various non-Maple-Mini boards.

Perhaps its something specific to the nRF51 series or perhaps Cortex M0 in general.

I need to some more investigation, but I think its just one of the pins being LOW is halting the core, At the moment I just Set them both and that fixes it.

Just leaving them in their default state was no good, they definitely needed to be set High.

But I have no knowledge about how SWD works.
I presume that the programmer provides the clock signal, and the SDIO is bi directional.

I will see if I can find a simple explanation of SWD on ARM

RogerClark wrote:
…
But I have no knowledge about how SWD works.
I presume that the programmer provides the clock signal, and the SDIO is bi directional.

I will see if I can find a simple explanation of SWD on ARM

jcw wrote:There’s also a “detach” command in gdb, perhaps that’s of use?

RogerClark wrote:I’ve posted an issue on blacksphere’s repo to ask if this is the correct thing to do, and see if anyone can advise me

Hi Rick

No worries about the j66_coreboard.

I did wonder where it came from, as i noticed it wasn’t in the Master repo as far as i could tell.

Perhaps for the GD32 and maple mini, I should copy your j66 folder and make changes, rather than trying to put #ifdef s in the j66 platform

That would be cleaner.

Or even fork off the upstream.

Rick Kimball wrote:That would be cleaner.

Or even fork off the upstream.

RogerClark wrote:Rick Kimball wrote:That would be cleaner.

Or even fork off the upstream.

LOL

Ok..

Rick,

Why did you “clear” both SWD pins in the init () ??

I took a look at the stlink files and they don’t seem to clear those bits.

Actually they don’t clear them either, so I suspect the default state is LOW, but I’d need to double check.

Set’ing those bits seems to fix things for me, so I think I’ll leave it like that

But I’ll clone off blacksphere’s repo, then add you j66 coreboard as GD32F103_120Mhz – with my changes, and also make Maple mini version and a generic stm32f103c version (very similar to your j66)

I’ll credit you in the comments.

I also want to add a binaries folder to the repo. I’m not sure if this is politically correct for github, but a lot of projects have hex files etc for download in the repo.

RogerClark wrote:Why did you “clear” both SWD pins in the init () ??

Clearing seems to do the same thing as doing nothing

If I remove them the nRF51 still seems to go into halt on power up.

I actively need to set them

I’m not sure what the default input state is on the SWD pins on the nRF51, if they are not connected, I suspect that both pins just float.
However I’m not sure if they float high or just float.

I suspect they must have some sort of pull up of pull down on them, otherwise the SWClock will get noise pickup and it may think its being clocked with random data, which sounds like a recipe for unreliable start-up’s

Yeah at the beginning of the thread is a conversation about how you don’t need pullup/pulldowns for the stm32f chips .. And originally that is all I cared about. You might try to find a similar document from Nordic, explaining about the default state of the JTAG/SWD pins

Thanks, I’ll see if I can find the equivalent Nordic doc

Edit.

https://devzone.nordicsemi.com/question … resistors/

Strange.

They seem to say that both pins are OK in a default state of being pulled down. However, If the BMP “clears” both, the module goes into debug mode.

From the posting on Nordic’s site there seems to be some differences between which revision of the chip is being used, but they all seem to need to default to being LOW; either with internal or external.

But its strange if I do this using the BMP there seems to be a problem with this.

I’ll need to try just pulling those lines low using resistors and see if it has the same effect, as I wonder if its caused because the platform init() is being caused some time after powerup.
I’ll probably need to stick my scope / logic analyser on it.

Aha, great trick, Rick – thanks!

Sorry.

I posted a follow up to the other Offtopic nRF thread.

It appears that SWDIO on the nRf51 doubles up as the Reset pin.
Rick. If you look on your nRf motherboard, the button marked Reset appears to connects / shorts SWDIO to Gnd when you press it.

I’m still waiting for my motherboard ;-(

Greetings,

Great work on the diy BMP! That is a handy tool.
I’ve had good luck using a Blue Pill and the pre-complied binary: downloading sketches works fine, also gdb works as described.
The only hardware modification was replacing the 10k (R10) pullup with 1.5K.

Was wondering what additional features are in the latest git sources?
I managed to build a new BMP bin file after fixing paths to the ARM toolchain resulting 65,604 byte binary.
The pre-compiled binary was 50,096 bytes.

Does that sound reasonable?

Thanks for all the efforts.

Rick has made some changes to support the nRF51 device (Nordic Bluetooth Low Energy), but I don’t think that would account for the difference in file size, as its only a minor change.

If you binary is over 64k (which I think it now is), then technically it won’t fit in a stm32f103c8 however in reality most of the chips labelled as stm32103C8 are actually the stm32f103CB i.e the larger flash version.
So I think you should be OK even if it is that size

I’d just give it a try and if its no good, reflash back to the precompiled version

FWIW, I’ve posted an article about the Black Magic Probe here http://jeelabs.org/book/1546d/
With thanks to @rick for creating and sharing his BMP build.

I just thought I’d let you know that I modified the source code a tiny bit and the BMP works fine on the Maple mini (no surprises here)

The changes are very minor, you just change the USB reset stuff to use a different pin, and swap the Set and Clear calls around the other way, and you don’t need the delay loop.

I will put the new ‘platform’ in my clone of blacksphere’s repo, but I need to push just the NRF51 changes first as I want to do a PR back to blacksphere’s repo just for the nRF51 stuff.

I was hoping to do a version of the BMP which I could relocate to run from 0x8005000 so it couldnt be installed on a Maple mini via the bootloader, but the base address in libopencm3 doesnt seem easy to change, as it appears to be defined in lots of places, and I didnt want a custom version of libopencm3 in my BMP repo.

Congrats on getting BMP into an MM.

RogerClark wrote:[…] the base address in libopencm3 doesnt seem easy to change, as it appears to be defined in lots of places

Hang on, the “native” BMP itself also loads higher, IIUC – it has a DFU boot loader at the bottom.
This might be of use: https://github.com/blacksphere/blackmag … inc#L9-L13

JeanClaude

Interesting link…

I will need to check the libopncm3 code on my machine

I searched the current github repo version and I cant find 0x800000 in the source, but I am fairly sure its in the version I am using for the BMP ( but I will need to double check)

Umm hang in, i will find what version it us and search github

Edit.

I meed so search in my codebase as i cant see in it blackspheres version either.
ummm. very strange.. I may be talking rubbish.

Edit

OK.

I was not going totally mad.

The base address for STM32 is defined inside libopencm3 (at least the version that the Blacksphere’s repo uses)

See this search

https://github.com/libopencm3/libopencm … x08000000U

So… It could be changed, but, you’d need to change stuff inside libopencm3

I’ve just check again, and even the most recent version of openlibcm3 has this hard coded into the stm32f1 device

So as far as I can tell, you’re going to need to fork openlibcm3 and modify it, then you’ll need to detach the libopencm3 submodule from your code (if you have attached a submodule) and attach your fork of openlibcm3 which has the base address changed in a few places.

Any tips on how to tell on a Mac, which device is the the GDB server

(actually its a shame that the name is not displayed on either windows or OSX)

You mean which of the two virtual serial ports of a BMP is for gdb and which is serial pass-through?
On Mac OSX, the gdb port’s name always end in “1”, serial pass-through always ends in “3”.

@jcw

Yes. Thats what I was trying to ask

Unfortunately on Windows its not so clear as they just have 2 different COM numbers and I think it matters which order you install the drivers which around the 2 comm numbers are assigned

Hi Roger

I’m looking for a super-easy, beginner’s flasher for my Arduino-on-nRF51822 project.

So that means:

• – very cheap (£10/$15 say)
  – very easily sourced (so Adafruit ideally)
  – no flasher needed to create the flasher! (so already flashed, software-driven or flashable through serial)

I’ve been playing with ST-Link/V2+OpenOCD, which already meets these requirements, and have pre-ordered an IBDAP and some FT232H boards, both of which could also meet them, along with OpenOCD.

But I discovered BMP through your own Arduino-on-nRF51822 article
http://www.rogerclark.net/arduino-on-th … ontroller/
and this gives us two significant bonuses:

• – the GDB connection
  – the Serial connection

Which brings me back to the above requirements list, and a list of questions about STM32F103-based boards – which I’m hoping you’ll kindly answer..

Option 1 – re-purpose an ST-Link/V2 mini:

• – can I use something like the ST firmware upgrader to re-flash an ST-Link/V2 mini through USB?
  – or somehow through Serial like you did? (I believe they have SWD pads, but that’s the circular problem)

Option 2 – commodity STM32F103 boards:

• – what is this ‘red pill’ / ‘blue pill’ thing all about? are these essentially Maple Minis?
  – can they all be flashed through serial or is the one you used (which you said was a Maple Mini) special?
  – are they only available from China? I see local UK suppliers, but I’m not sure what I’m getting

I’d also love to see a photo of (a) your board being flashed through serial, and (b) your board all wired up to the target! I find pictures make it easier for me to understand what’s going on!

Hope that’s not too much to ask for a first posting to this forum!

Cheers!
Duncan

Duncan

It is possible to put the BMP onto a STLink dongle, but there are reasons why this is not ideal…

STLink dongles do not break out the Serial port pins (PA9 and PA10) and solderimg to the STM32 is challenging

You cant use the STLink updated progam by STM to update to BMP, you have to flash using another STLink.

So I would keep your STlink to program other STM32 and STM8 boards

Re:Blue Pill etc
This is the name someone coined for the cheap generic STM32F103C8 boards that are easily available on eBay. They are a bit like an Arduino Nano, just a bit longer.

But a better option is the Maple mini, which is the same size but is well made and has the 128k flash F103CB chip

Im not sure who sells STM32 boards apart from the eBay and Aliexpress vendors, but if you want local stock, just look on ebay for a local supplier of the Maple Mini board

Once you have the Maple mini or the blue pill etc, you can flash the bmp using your stlink

BTW. I added Segger JLink as an upload option, and Jlink compatible programmers are available farily cheaply on eBay, and the home / educational version from Segger is not too expensive, But both options are more expensive than using a Maple mini.

I’m currently using Jlink, but may go back to BMP, as I have some wierd things going on with a WT51822-S2 module that I’m trying to use.

The most reliable modules to start with, seem to be the development motherboard and modules from WaveShare. They all work fine for me ( both the QFAC and QFAA device types ).
BTW. I dont have any QFAB modules as they are only 128k flash and the S130 Softdevice takes 109k, and user code starts at 112k, which does not leave enough room for a user application that actually uses the Softdevice.

Thanks for that quick and detailed reply, Roger, much appreciated.

Sad that the ST-Link/V2 can’t be flashed by serial – or rather, we haven’t managed to work out how ST do it with their upgrade tool through USB!

So I want the users of my project to be able to easily buy a board and download BMP to it via serial – but I don’t know where I’d point them to find a board – they could either pick up a Maple Mini clone or one of the red/blue boards it seems? Could you provide links to definitive examples of each to get me started – I may have to just buy one of each and try it myself..

Do the red/blue boards support serial flashing on PA9/10 like the Maple? I found this article on your site, which implies that they do:

http://www.rogerclark.net/stm32f103-and … 1-5-x-ide/

Is that a ‘blue pill’, then?

Cheers!
Duncan

Duncan

Most STM32 board support flashing via serial. The serial bootloader is built into the hardware of the F103 chip

The only reason that its hard to flash the STLink dongles is that the pins for PA9 and PA10 and also for Boot0 are hard to get to, as they are not broken out onto a pad or pin

The STLink dongles generally have the SWD (SWDIO and SWCLK) pins plus power and ground, connected to 4 small pads on the dongle, so that its possible for mere mortals to solder onto the pads, and connect another STLink (or BMP etc) and program them

If you are good at soldering it would be possible to solder directly onto pins PA9 and PA10 and Boot0 on the chip and connect a USB to serial adaptor and also to set Boot0 HIGH (you may also need to set Boot1 low, as this may be floating – I can’t remember if the STLink dongles bother to tie this low as Boot1 only makes a difference when Boot1 is HIGH)

The Blue and Red Pill are basically the forums’ names for the board you found on my blog (http://www.rogerclark.net/stm32f103-and … 1-5-x-ide/)
e.g you can get them on ebay for a few pounds.

This is an example on eBay, but you may find cheaper or want to get from a local supplier
http://www.ebay.co.uk/itm/STM32F103C8T6 … Sw6aVUo1Pq

For the Maple mini, I forget precisely which thread its in, but most people buy them from a company called “Baite” as they actually manufacture the boards, and hence you get ones which have passed their QA process.

Often Maple Mini’s from other suppliers are actually Baite reject boards that have been reflow soldered to fix dry joints.
And I think perhaps there are other manufacturers..

@mrburnette is the Maple mini supply expert

But any STM32F103 board should technically be capable of being flashed with the BMP firmware via Serial

I have versions for the Blue / Red pill as well as the Maple mini (which has different USB reset hardware), and also the GD32 (like the STM32 but faster) (but the GD32 boards normally have a 12Mhz crystal instead of an 8Mhz on the STM32 – though this is not why the GD32 is faster, as the master clock frequencies for them both is still 72Mhz)

there is a maple mini not from Baite, it’s got a red led, not the Baites bright brilliant blue and the silkscreen is a subtly different style.
price is similar.

i’d suggest you get a Baites 5 off set, go to their store and search for ‘STM32’, pricing is almost the same per unit as a singleton, single postage though.

i don’t think i’ve killed a single 103c8t6 as yet, but definitely a zet6 with 12v and not any of the pills i have, similar comment as to purchasing them.

stephen

Baite store on Aliexpress

5 pack Maple Mini clone

Yes, you may find some $0.50 less. However, my belief is to build a relationship with a vendor who has consistently providedme with excellent product – out of 40+ devices, 100% satisfied. Ss they say, your results msy vary.

Warning: Chinese New Year is next month – almost all of China will be on vacation. Expect delays.

Ray

Thanks mrburnette, zmemw16 and Roger for all that excellent detailed and useful info – bookmarked!

Could I ask a couple more questions..? On USB flashing – which I have just realised may be an option instead of PA9/10/Boot0 or SWD.

I believe Maple clones can be flashed over USB, but you (Roger) didn’t suggest that approach in your article: http://www.rogerclark.net/arduino-on-th … ontroller/ – was there a reason for that?

I presume there’s no hope of flashing a Red/Blue board over USB?

As we know, ST-Links can be upgraded over USB (http://www.st.com/web/en/catalog/tools/PF258194), so has anyone looked around the ST Java code to see how to do generic flashing? I poked around and saw AES encryption in there, so maybe they’ve got some kind of protection guff.

Finally, if you did flash BMP onto an ST-Link mini, using any approach, do you think you could use the non-SWD pins (marked RST and SWM on my board) as the serial connection, if BMP were re-built accordingly?

Apologies if all this is out there and I shoulda known it!

Cheers!

Duncan

Duncan

The STM32F103 does not have a built in USB upload feature built into the chip (the STM32F4 series does but not the F1 series)

Normally when we program the Maple mini and the generic STM32F103 boards using the Arduino IDE, we use the STM32duino-bootloader
(This is updated version of the original Maple-bootloder written by Leaflabs)

The bootloader comes pre-installed on Maple mini boards and can be flashed onto generic STM32 boards (e.g. Blue Pill), and then remains resident and provides the upload / reflashing via USB.

i.e when you power on the Maple mini it runs the bootloader code in the base of flash which enumarates on USB as a DFU device for about 1 second.

If the host PC does not start sending data to the DFU device in about the first second after booting, the bootloader looks to see if there is any code at the sketch start address 0x8002000 and if so it jumps to that address and the sketch starts to run.

In order to get the BMP to work in this way, it would need to be compiled so that the base address of the code is 0x8002000 instead of the start of flash (which is 0x800000)
I did briefly look at doing this, but the code that would need to be changed seems to be deep inside libcm3 and it looked like it would take quite some time to modify, test and debug.

So as there was very little gain in doing this apart from allowing Maple mini users to run the BMP as if it was a sketch, I didnt feel it was worth me spending any of my very limited time on doing that as an option.

Re: Repurposing some of the pins on the STlink as Serial

Its a nice idea, but I’m not sure whether it would be possible

Although the STM32F103 has multiple USARTS, I’m not sure if any of them are on the pins use by RESET and SWIM

You’d need to find a schematic for the STLink stick and find which pins are used (I think one of them my be PB0), you’d then need to check if any of them are USART pins.
If they are not primary USART pins, there are remap / alternative pins for the USARTS, so you need to check that as well

If they are remap pins, in theory you could modify the BMP code to remap the pins and use the appropriate USART.

However the pins may not be both on the same USART

I suspect you are making yourself a huge amount of work.

the v2.0 of the bootloader is a major speed improvement, certainly on the maple mini, not done it with a pill.

flashing a pill for bmp install is easy, it’s puzzled me or i was unsure and then it was so simple i posted a comment to that effect.
istr 2 photo’s from a rick thread, combining them shows all 4 wires that will connected to the target, programming it is
via 4 pins on end of the pill. careful pin counting is reccomended. also there is a link to a binary zip you can install, beginning of the thread and it gets updated.

after that it gets interesting and maybe a tad confusing for my braincell. openocd is suggested. using it is not a gui.

stephen

I am cross posting to this thread on Richard’s suggestion from http://www.stm32duino.com/posting.php?m … 37&p=15530

Rick Kimball wrote:Darius wrote:Hi all,
I’m just trying out STM32Duino and so I cloned https://github.com/rogerclarkmelbourne/ … _STM32.git and checked out the development branch.
I twiddled STM32F1/platform.txt to change ‘runtime.tools.arm-none-eabi-gcc.path’ to point to my build environment.

Go back to the start. Delete all those extra things you downloaded. Get rid of the launchpad arm-none-eabi-gcc toolchain. Unpack the stm32duino stuff in the right place. Then start up the IDE and install the boards package for the Arduino Zero. The will get rid of the missing g++. Then report back.

https://github.com/rogerclarkmelbourne/ … stallation

Step 2:

Run the IDE, and on the Tools menu, select the Boards manager, and install the Arduino Due from the list of available boards.

*NOTE: this step installed the arm-none-eabi-g++

Are you running the bootloader on your stm32f103c8?

Rick Kimball wrote:Go back to the start. Delete all those extra things you downloaded. Get rid of the launchpad arm-none-eabi-gcc toolchain. Unpack the stm32duino stuff in the right place. Then start up the IDE and install the boards package for the Arduino Zero. The will get rid of the missing g++. Then report back.

https://github.com/rogerclarkmelbourne/ … stallation

Step 2:

Run the IDE, and on the Tools menu, select the Boards manager, and install the Arduino Due from the list of available boards.

*NOTE: this step installed the arm-none-eabi-g++

BMP and gdb can load(flash) .hex now.
‘STM32 ST-LINK Utility’ is needed for convert .bin to .hex, I tried to use arm-none-eabi-objcopy for convertion but failed.
$ arm-none-eabi-gdb -batch -ex 'tar ext COM3' -ex 'mon ver' -ex 'mon sw' -ex 'at 1' -ex 'mon option erase' -ex 'load x.hex'
Black Magic Probe (Firmware xxx) (Hardware Version 1)
Copyright (C) 2015 Black Sphere Technologies Ltd.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

Target voltage: Not Implemented!
Available Targets:
No. Att Driver
1 STM32F1 medium density
0x0800cc98 in ?? ()
0x1FFFF800: 0x5AA5
0x1FFFF802: 0xFFFF
0x1FFFF804: 0xFFFF
0x1FFFF806: 0xFFFF
0x1FFFF808: 0xFFFF
0x1FFFF80A: 0xFFFF
0x1FFFF80C: 0xFFFF
0x1FFFF80E: 0xFFFF
Loading section .sec1, size 0x2000 lma 0x8000000
Loading section .sec2, size 0x2000 lma 0x8002000
Loading section .sec3, size 0x2000 lma 0x8004000
Loading section .sec4, size 0x2000 lma 0x8006000
Loading section .sec5, size 0x2000 lma 0x8008000
Loading section .sec6, size 0x2000 lma 0x800a000
Loading section .sec7, size 0x2000 lma 0x800c000
Loading section .sec8, size 0x318 lma 0x800e000
Start address 0x0, load size 58136


You should be able to get the IDE to generate HEX

Try using the Export Compiled Binary menu option on the Sketch menu

RogerClark wrote:You should be able to get the IDE to generate HEX

Try using the Export Compiled Binary menu option on the Sketch menu

alex wrote:

This is only for closed source firmware.

Hi there, I was planning to create my BMP for upload & debug purpose.
I’ve seen suggestions about using the cheapest blue pill anyway I have a concern on this: blue pills (and newer black pills – viewtopic.php?f=28&t=117&start=170#p18316) have a quite low power LDO so:

• Would the blue pill LDO be enough to power up the target board, upload and debug at least non power demanding sketches?
• In case the power provided by the blue pill based BMP is not enough, how else should I power the target board?
• Could it be better to use a board which features a AMS1117?!

Thanks in advance and bye, E.

Side questions for who have both the blue pill and the new black pill: which one would you suggest and why?

The one blue pill I have setup as a BMP programmer I had to replace the LDO with a microchip mcp1702. If I hadn’t shorted the power pins I’d still be using the original LDO. The mcp1702 is a 250mA max device and seems to work fine. Others have indicated the typical LDO on the blue pills are 300mA max. Seems like it would be fine with the one that ships onboard.

-rick

Rick Kimball wrote:The one blue pill I have setup as a BMP programmer I had to replace the LDO with a microchip mcp1702. If I hadn’t shorted the power pins I’d still be using the original LDO. The mcp1702 is a 250mA max device and seems to work fine. Others have indicated the typical LDO on the blue pills are 300mA max. Seems like it would be fine with the one that ships onboard.

-rick

Yes that is what I was doing. Of course if the target board is power hungry, that isn’t going to work.

I’ve read almost the whole discussion but I can’t decide… I have two ST-Link V2 dongles and blue stm32F103c8t6 boards. Which option is suggested ?

1) Flash BMP FW into st-link using the second st-link dongle
2) Flash BMP FW into blue stm32F103c8t6 board

michael_l wrote:I’ve read almost the whole discussion but I can’t decide… I have two ST-Link V2 dongles and blue stm32F103c8t6 boards. Which option is suggested ?

1) Flash BMP FW into st-link using the second st-link dongle
2) Flash BMP FW into blue stm32F103c8t6 board

Rick Kimball wrote:michael_l wrote:I’ve read almost the whole discussion but I can’t decide… I have two ST-Link V2 dongles and blue stm32F103c8t6 boards. Which option is suggested ?

1) Flash BMP FW into st-link using the second st-link dongle
2) Flash BMP FW into blue stm32F103c8t6 board

BTW.

I tried to compile and flash the latest version of the BMP onto a STLink made by Baite ( the same company that sell the Maple mini clones)

But it doesn’t work at all. ( USB is not working)

I do have an old version of the BMP that works in those STLinks, which is based on Ricks BluePill port of the BMP.
But the BMP core code has changed a lot since Rick did has BluePill version, so its not possible to simply copy the platform files for the Baite STLink into the new code.

And at the moment I don’t have the time to bring the old code up to date, so I’m continuing to use the old version.

In the longer term however I was intending to do a Baite STLink “platform” and submit it as a PR.
However as Gareth is now doing a commercial push for to sell the BMP via kickstarter, I have a concern that doing this would allow Baite to bring out a $3 BMP, as they already use the same hardware has another programmer as well as a STLink, and it would be incredibly easy for them to drastically undercut Gareths price.

Thanks Roger, that’s good to know. Yes, ST Link dongle might be a bit more compact as a BMP compared to bluepill and it has that nice metallic cover too.Since I have another St Link V2 dongle it’s easy to flash any board.

I’ll try latest stlink binary and see how it works on bluepill.

do you mean the BMP binary for STLink?

i would be surprised if it runs on the Blue Pill if it doesnt work on the Baite STLink as the Baite STLink is basically the same as the BluePill, just with much less GPIO.

Actually, after saying that… I guess i should look at the schematic for a STLink dongle vs a STLink on a Nucleo, as AFIK the BMP code is designed to run on a Nucleo or Discovery STLink and the USB enumeration reset circuit may be different between those 2 types of board.

michael_l wrote:
EDIT: found these from platform.h
* TMS = PA4 (input for SWDP)

Rick

Paypal link seems to be working again now. Perhaps it was an issue with paypal

can you try it again

Re: BMP not working on the Baite STLink dongle

ummm..

OK. I’m not sure what the difference is between the dongle and the Nucleo / Discovery hardware but perhaps it doesnt work on either at the moment

I don’t want to reflash any of my Nucleos as there is no way to get back to the version of stlink that uses USB mass storage and also has USB Serial ( as that binary has never been hacked and released)

But I think my Discovery F4 board doesnt have the mass storage, so I guess I could blow that away, but I’d loose USB serial so I could not go back to the original config by loading the hacked version of stlinks for the dongle

When I looked for a debugger I found “real” BMP just too expensive for a user beginning with STM32 boards. But the idea is great – to have GDB server ready on the board. Actually I started with Arduino’s but quickly found out that there’s not a decent debugger that does not cost fortune. I guess I’m the one of people who want sometimes do debugging step by step. ‘That’s why I started digging (in the other thread ) how to use STM32Duino framework with ST Link with openocd. After some work and a patch in Arduino IDE debugging works. So with a little cost it’s possible to buy stm32 boards and develop in Arduino framework and debug also. I’m a programmer for over 10+ years and I understand the value of debugging but if the BMP price had been around $20 I may have bought it. Roger, do you have a paypal button somewhere so I can donate to you ?

Michael

Re:Donations

Unfortunately if I accept donations, as it will almost certainly cause problems for me.

I provide the code etc, “as is”. I don’t make any guarantees that things work or that I will fix bugs.. As I simply don’t have time.

I’m sure that if I added a Donate button, that some people would make a donation and then expect some bug to be fixed in return.

I already get loads of unsolicited emails asking me for help with various projects. I used to respond politely saying that I can’t give individual help via email.
But I have received abusive emails when I’ve done that, so I simply do not reply to unsolicited emails any more.

Also. I’m sure the Australian Tax Office would tell me that “donations” were payment for services and hence taxable, and I’d need to individually account for each one, and declare them as part of the Business Activity Statement I have to do every 3 months

So the admin time involved would also make it not worth the hassle.

RogerClark wrote:Michael

Re:Donations

Unfortunately if I accept donations, as it will almost certainly cause problems for me.

I provide the code etc, “as is”. I don’t make any guarantees that things work or that I will fix bugs.. As I simply don’t have time.

I’m sure that if I added a Donate button, that some people would make a donation and then expect some bug to be fixed in return.

I already get loads of unsolicited emails asking me for help with various projects. I used to respond politely saying that I can’t give individual help via email.
But I have received abusive emails when I’ve done that, so I simply do not reply to unsolicited emails any more.

Also. I’m sure the Australian Tax Office would tell me that “donations” were payment for services and hence taxable, and I’d need to individually account for each one, and declare them as part of the Business Activity Statement I have to do every 3 months

So the admin time involved would also make it not worth the hassle.

michael_l wrote:Rick, do you know if latest BMP source contains some important fixes ? Or should I be fine with this version ? Thanks

Thanks Rick for the help. Sorry if this is a basic question but does BMP need any drivers for Windows 7 ?

Edit: found

http://www.blacksphere.co.nz/downloads/driver.w32.zip

Hmm.. these drivers don’t seem to work and install

Changes I made to the latest standard BMP stlink platform to get it to run on a bluepill:

# I copied the src/platforms/stlink to src/platforms/bluepill
# then in the BMP/src directory:
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)

modified: Makefile

Untracked files:
(use "git add <file>..." to include in what will be committed)

platforms/bluepill/

no changes added to commit (use "git add" and/or "git commit -a")
$ git diff
diff --git a/src/Makefile b/src/Makefile
index 8bc2659..55bc99e 100644
--- a/src/Makefile
+++ b/src/Makefile
@@ -108,6 +108,6 @@ all_platforms:

include/version.h: FORCE
$(Q)echo " GIT include/version.h"
- $(Q)echo "#define FIRMWARE_VERSION \"`git describe --always --dirty`\"" > $@
+ $(Q)echo "#define FIRMWARE_VERSION \"`git describe --always --dirty`-rk\"" > $@

-include *.d
$ diff platforms/bluepill platforms/stlink
diff platforms/bluepill/Makefile.inc platforms/stlink/Makefile.inc
14c14
< LDFLAGS = $(LDFLAGS_BOOT) -Wl,-Ttext=0x8000000
---
> LDFLAGS = $(LDFLAGS_BOOT) -Wl,-Ttext=0x8002000
24c24
< .phony: install all host_clean
---
> all: blackmagic.bin blackmagic_dfu.bin blackmagic_dfu.hex dfu_upgrade.bin dfu_upgrade.hex
26c26,32
< all: blackmagic.bin
---
> blackmagic_dfu: usbdfu.o dfucore.o dfu_f1.o
> @echo " LD $@"
> $(Q)$(CC) $^ -o $@ $(LDFLAGS_BOOT)
>
> dfu_upgrade: dfu_upgrade.o dfucore.o dfu_f1.o
> @echo " LD $@"
> $(Q)$(CC) $^ -o $@ $(LDFLAGS)
31,32d36
< install:
< openocd -f ~/openocd_cfg/st_nucleo_f103rb.cfg -c 'program blackmagic verify reset exit'
diff platforms/bluepill/platform.c platforms/stlink/platform.c
104c104
< //SCB_VTOR = 0x2000; /* Relocate interrupt vector table here */
---
> SCB_VTOR = 0x2000; /* Relocate interrupt vector table here */
diff platforms/bluepill/platform.h platforms/stlink/platform.h
66c66
< #define TMS_PORT GPIOA
---
> #define TMS_PORT GPIOB
70c70
< #define TMS_PIN GPIO4
---
> #define TMS_PIN GPIO14
$ make PROBE_HOST=bluepill clean all install

Michael

I’m not sure if these are the same file but…

Try

https://github.com/rogerclarkmelbourne/ … ter/driver

Rick Kimball wrote:Changes I made to the standard BMP stlink platform to get it to run on a bluepill:

# I copied the src/platforms/stlink to src/platforms/bluepill
# in the BMP/src directory:
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)

modified: Makefile

Untracked files:
(use "git add <file>..." to include in what will be committed)

platforms/bluepill/

no changes added to commit (use "git add" and/or "git commit -a")
$ git diff
diff --git a/src/Makefile b/src/Makefile
index 8bc2659..55bc99e 100644
--- a/src/Makefile
+++ b/src/Makefile
@@ -108,6 +108,6 @@ all_platforms:

include/version.h: FORCE
$(Q)echo " GIT include/version.h"
- $(Q)echo "#define FIRMWARE_VERSION \"`git describe --always --dirty`\"" > $@
+ $(Q)echo "#define FIRMWARE_VERSION \"`git describe --always --dirty`-rk\"" > $@

-include *.d
$ diff platforms/bluepill platforms/stlink
diff platforms/bluepill/Makefile.inc platforms/stlink/Makefile.inc
14c14
< LDFLAGS = $(LDFLAGS_BOOT) -Wl,-Ttext=0x8000000
---
> LDFLAGS = $(LDFLAGS_BOOT) -Wl,-Ttext=0x8002000
24c24
< .phony: install all host_clean
---
> all: blackmagic.bin blackmagic_dfu.bin blackmagic_dfu.hex dfu_upgrade.bin dfu_upgrade.hex
26c26,32
< all: blackmagic.bin
---
> blackmagic_dfu: usbdfu.o dfucore.o dfu_f1.o
> @echo " LD $@"
> $(Q)$(CC) $^ -o $@ $(LDFLAGS_BOOT)
>
> dfu_upgrade: dfu_upgrade.o dfucore.o dfu_f1.o
> @echo " LD $@"
> $(Q)$(CC) $^ -o $@ $(LDFLAGS)
31,32d36
< install:
< openocd -f ~/openocd_cfg/st_nucleo_f103rb.cfg -c 'program blackmagic verify reset exit'
diff platforms/bluepill/platform.c platforms/stlink/platform.c
104c104
< //SCB_VTOR = 0x2000; /* Relocate interrupt vector table here */
---
> SCB_VTOR = 0x2000; /* Relocate interrupt vector table here */
diff platforms/bluepill/platform.h platforms/stlink/platform.h
66c66
< #define TMS_PORT GPIOA
---
> #define TMS_PORT GPIOB
70c70
< #define TMS_PIN GPIO4
---
> #define TMS_PIN GPIO14
$ make PROBE_HOST=bluepill clean all install

It was just the latest version.
$ git pull
Already up-to-date.
$ git log
commit d6e29774feee9cad275f97d7e5c7fcfccfeb190b
Merge: dc9073b 085c980
Author: Gareth McMullin <[email protected]>
Date: Mon Dec 5 10:55:24 2016 +1300

Merge pull request #174 from ChuckM/sam4l

Target Driver for Atmetl AT91SAM4L target


Rick

Why did you move the vector table, are you loading it where the sketch normally resides, i.e at 0x2000 hex ?

I’ll need to give the STlink binary a try on my Black Pill (All my blue pills now have broken USB connectors )

But on the Baite STlink it would not enumerate at all on USB, which is a bit strange, as all you seem to have done is change the vector table and the TMS pin, and I can’t see how that would effect the USB enumeration on Baite STlink

Roger wrote:Why did you move the vector table, are you loading it where the sketch normally resides, i.e at 0x2000 hex ?

BTW.

According to @denis the Baite STlink has the same circuits as the all STLinks e.g.

http://www.avrki.ru/picture/articles/sa … ink_v2.jpg

So there isnt any USB enumeration hardware

Umm.. Strange that blacksphere’s precompiled binary did work on it, nor did the version I compiled myself

RogerClark wrote:…But on the Baite STlink it would not enumerate at all on USB, which is a bit strange, as all you seem to have done is change the vector table and the TMS pin, and I can’t see how that would effect the USB enumeration on Baite STlink

Yep

PS. I tried using gitter, do you still have an account or did you delete it again?

OK, I moved the discussion over there to gitter

RogerClark wrote:Michael

I’m not sure if these are the same file but…

Try

https://github.com/rogerclarkmelbourne/ … ter/driver

OK. I can’t remember where I found those drivers, but it was somewhere on the blacksphere site.
However they may have since removed the originals from their site

Roger, Driver I was using was dated 2011 and used USB VID 0483, PID 5740. Current one uses VID 1D50, PID 6018. Funny thing is that yesterday I managed somehow to brake my ST link V2 clone. Windows does not recognize the device anymore, no leds etc. Good thing is that BMP on bluepill seems to work okay.

michael,

Do you think its a hardware of software problem with your STLink ?

Well I guess it must be the hardware because I didn’t flash anything to it. Maybe I accidentally put 3.3V to GND or something.

michael_l wrote:Well I guess it must be the hardware because I didn’t flash anything to it. Maybe I accidentally put 3.3V to GND or something.

BTW.

Getting back to the original topic

FYI.

The STLink binary on blacksphere’s website (linked from the Readme on their github repo), are not actually usable.

The compiled binaries do not contain the new Blackmagic bootloader, (blackmagic_dfu.bin) which sits at the base of flash.
They are the main / runtime code that needs to be flashed to 0x8002000

So in order to flash the BMP onto a STLink, you still need to build from source, because Gareth is not going to publish compiled binaries for the stm32 version of blackmagic_dfu.bin – basically for commercial reasons, because Blacksphere make money from selling the BMP hardware rather than from the software.

So… I’ve attached the STLink binaries I built last night, both the blackmagic_dfu.bin which needs to be flashed to 0x800000 and also blackmagic.bin which needs to be flashed to 0x8002000

You can just flash blackmagic_dfu.bin to 0x800000 and then restart the board and then upload blackmagic.bin via the BMP’s own DFU, (as documented here https://github.com/blacksphere/blackmag … g-Firmware )

But if you’ve already got the Serial or STLink etc uploader open , its going to be quicker and easier just to do both of them in that tool

Edit.

I may have a chat with STM to find out if there is any way to write an updater (a bit like the Segger updater) which allows users to replace their STLink firmware on their Nucleo with the Segger JLink code.

To see if they would be interested in allowing update from STLink to Blackmagic probe. But I suspect that for various reasons they would not be open to this. (especially as there would be no official way back to STLink)

RogerClark wrote:I may have a chat with STM to find out if there is any way to write an updater (a bit like the Segger updater) which allows users to replace their STLink firmware on their Nucleo with the Segger JLink code.

To see if they would be interested in allowing update from STLink to Blackmagic probe. But I suspect that for various reasons they would not be open to this. (especially as there would be no official way back to STLink)

@devan

Very interesting

How big is the STLink bootloader ?

The BMP code is normally set to have its base address at 0x8002000, but I know we could change this to match the STLink code address

@devan

Thanks for the links to those articles

I’m not sure if I’m reading this correctly, but the bootloader for all STLInk boards may be the same, apart from the USB VID PID, and the ST Firmware update tool may be reading this data to determine which firmware to install

But perhaps there is some other ID data in the bootloader which the ST uploader reads in order to determine which firmware to upload.

Of course if we make a BMP version and encrypt it, it doesn’t make much difference as long as the bootloader just accepts our BMP code.

Flashing the STLink-v2 bootloader onto an STLink-v2-1 causes the updater to pick the STLink-v2 firmware, so I’m pretty sure that the bootloaders are not the same.

Unfortunately, I didn’t dump the STLink-v2-1 bootloader correctly, so doing any further analysis is difficult unless I sacrifice another Nucleo board.

@devan

Have you tried changing the VID/PID on the bootloader ?

I presume you can get hold of a copy of the STLink binary that was on some russian forum. It would be easy to use a hex editor to find and change the VID /PID pair as those sorts of things are usually stored close to each other in the binary

BTW. Does the bootloader set the read protection on the STLink binary, or do you think the main binary protects its self (possibly both). But even if the app protected its self, the simple thing to do would be to prevent the bootloader jumping to the main STLink binary at all, so it couldn’t protect its self

* chuckles * I thought you were all hardware guys ? Normally, software types like me would be spending days looking for a software solution to fix a problem like this : )

I guess I most becoming more of a sparky. It only took me abot 15 minutes to switch a few solder bridges, load the bmp stlink platorm, and switch the solder bridges back. Now I have a very useable stm32vl discovery board running the latest bmp firmware. Now I just need to get the courage to solder some bodge wires for the uart port.

-rick

RogerClark wrote:Have you tried changing the VID/PID on the bootloader ?

I presume you can get hold of a copy of the STLink binary that was on some russian forum. It would be easy to use a hex editor to find and change the VID /PID pair as those sorts of things are usually stored close to each other in the binary

@devan

I just noticed what you said about the STLink V1 not doing anything until the bootloader gets a command

OK. So its probably only possible to update boards that have the mass storage version ?

That’s my understanding based on what I’ve seen and what the article said, but I don’t know much about the STLink protocols, since I normally just immediately replace them with open-source debugger firmware.

For some reason ST-Link 2-1 refused to enter DFU mode after I flashed it and just kept booting into the user-code, so make sure that you have another programmer to flash back the original bootloader once you dumped it. No such problem on ST-Link v2. Use at your own risk.

Based on what lujji wrote on the eevblog forum, the “problem” of the V2-1 bootloader running the user code every time is exactly the behavior we want, assuming we can figure out where to jump to rerun the bootloader later.

RogerClark wrote:michael_l wrote:Well I guess it must be the hardware because I didn’t flash anything to it. Maybe I accidentally put 3.3V to GND or something.

Guys

Just as a matter of interest, I tried following the instructions on https://lujji.github.io/blog/reverse-en … -firmware/ and changed the binaries in the update jar file so that they were all the f2_3.bin version

This did successfully update, but I dont see any change in the Windows device manager, i.e no mass storage or USB Serial devices, so either that binary only has the stlnk device or the upgrade didnt work correctly

I tried doing the same thing with one of the larger binaries, but the firmware updater would not load it onto my STLink as it would technically not fit in flash.

Looking at that article, it seems to imply that the stlink bootloader is in the lower 0x4000 (16k) which is big for a bootloader, but it would explain how a 49k binary could not fit in a 64k device

I also looked to see if I could move the BMP start location to 0x8004000 and attempt to encrypt the binary and get the STLink updater to install it on one of my unmodified Baite STLink’s, but when I changed the

LDFLAGS = $(LDFLAGS_BOOT) -Wl,-Ttext=0x8002000

Thanks Roger, thats interesting info.

I think I’ve asked this before. Does BMP support printf through SWO in stm32duino? I have a project that uses serial and it would be handy to output debug prints somewhere else but still by using only BMP.

Micheal

On the BMP you have to wire its serial Tx and Rx pins to the STM32 PA9 and PA10 ( USART 1)
Note. I cant recall if Tx or Rx connects to PA9, but its well documented elsewhere

Thanks, I’ll try that.