Arduino for STM32

I'm at the end of my (limited) wits. I'm setting up a new dev environment (Atollic) for the STM32. I plan to use an eBay clone St Link as a BMP, by flashing the BMP_DFU and BMP binaries with another St Link clone.

I found a 1.6 RC0 binary already built (https://embdev.net/articles/STM_Discove ... agic_Probe) and successfully flashed BMP 1.6 RC0 on it. Everything works. But it's a rather old binary (mid 2016), and I wanted to update to 1.6.1 release, the latest

Problem is, I cannot compile the sources, and I'm spending way too much time trying to install a dev environment that works on Windows with the Makefile used by BMP. I tried installing the full mingw-w64 environment with the Arm toolchain, but I get a series of errors (I think because it used cmd.exe style syntax while the makefile uses Bash-like syntax). then I tried a full install of MSYS2, updated everything, installed mingw-w64 under it, plus the arm gcc toolchain, and the makefile seems to work a bit better, but still errors out not finding python in /usr/bin/env (even if python2 is installed in the usr/bin directory

Can anyone suggest how to install a minimal dev environment in Windows to compile BMP 1.6.1? I'm trying to avoid setting up a Linux VM, since I don't have that much free HD space, and would prefer to do it in Windows. It's just a temp install for me anyway, since I'll use either Atollic or STM32duino for my coding

Or, in alternative, can someone post the compiled dfu.bin, bmp.bin and update.exe from BMP 1.6.1, compiled with target=stlink?

thanks in advance, Rob

I gave up trying to build it also, openocd that was the failing point.

If you have win10, enable bash support then you will be able to build, I guess.

fpiSTM wrote: ↑

Tue Feb 12, 2019 2:57 pm

If you have win10, enable bash support then you will be able to build, I guess.

I was running it from within bash - can't remember the exact issue - I'll try again later and post so we can compare notes.

fpiSTM wrote: ↑

Tue Feb 12, 2019 2:57 pm

If you have win10, enable bash support then you will be able to build, I guess.

My main machine is on Windows 7, but I have a Windows 10 PC which I use rarely. I installed the Linux subsystem there, plus Ubuntu and a few apt-get later I have (finally) a working environment

Makefile works, but now I get a lot of errors "cast between incompatible function types" in command.c (which is in libopencm3_sam3, which I don't need and might find a way to remove), plus warnings "this use of defined might not be portable [-Wexpansion-to-defined] in the stm32 portion

Slow progress, I guess... time to Google libopencm3... and it looks like GCC 8 is causing problems, I'll try installing the GCC 7 ARm toolchain next

EDIT: I was trying to compile the 1.6.1 release (using --branch v1.6.1 when cloning the git repository). But it looks as if I'd need to go back in time to whatever specific toolchain they were using in May 2017, which is really too much work. If you use the latest precompiled ARM toolchain (https://developer.arm.com/open-source/g ... /downloads, v8 Q4 2018) with the current version of the git repository, everything compiles fine. Now I need to check if it works

For whoever wants to start from scratch like me on Windows 10, here's a brief summary of what I did:

Enabled the Linux subsystem on Windows 10
Installed Ubuntu
in the Ubuntu shell, I did first a sudo apt-get update, followed by sudo apt-get upgrade
installed make with sudo apt install make
followed by python with sudo apt install python-minimal
(libopencm3 uses python during compile)
Downloaded the Q4 2018 version of the precompiled ARM toolchain and copied that under my home directory (cp /mnt/c/users/(yourname)/downloads/gcc-arm-none* .)
expanded the tarball with tar -xjf gcc-arm-none*
renamed the long directory to gcc-arm with mv gcc-arm-none-eabi-8-2018-q4-major/ gcc-arm
exited the shell and from an administrator cmd.exe ran c:\windows\system32\bash.exe ~ --login
from that shell, I executed nano ~/.profile to add a line at the end of the profile (PATH=$PATH:/home/(yourname)/gcc-arm/bin). that way the path to the gcc arm toolchain is active in any shell you execute
relaunched the ubuntu/bash shell and checked that everything worked with arm-none-eabi-gcc -v to check the right version was installed and the path working
created a work directory under C: to have access from both Windows and Linux (mkdir /mnt/c/work followed by cd /mnt/c/work)
finally followed the blackmagic hacking instructions:
git clone https://github.com/blacksphere/blackmagic.git
cd blackmagic
git submodule init
git submodule update
and finally make PROBE_HOST=stlink
After a brief compilation with quite a few harmless warnings, I had a successful compilation. Now let's see if I can update my BMP-modified ST Link clone

Good news: everything worked, ended up with a blackmagic.bin and blackmagic_dfu.bin

Meanwhile I found what I wanted all along: precompiled binaries. I didn't notice, but in the BMP wiki, under Upgrade, there's a link to the automated nightly builds http://builds.blacksphere.co.nz/blackmagic/ where you can find the precompiled ST link binary, albeit no DFU

I downloaded Zadig and DFU-util, launched Zadig, inserted the BMP Stlink, Zadig offered to install the Winusb driver for it. Launched dfu-util with

dfu-util.exe -d 1d50:6018,:6017 -s 0x08002000:leave -D blackmagic-stlink.bin

this caused the ST link to detach and restart as an update, which aborted dfu-util since the new driver was not installed. Relaunched Zadig, new driver install, and upon reinserting the St link, the previous dfu command executed.

And promptly failed by saying that "last page at 0x0801351b" is not writeable". I suspect that the old DFU bootloader I used when originally flashing the St Link somehow is not fully compatible with 128k devices. So I reflashed the newly compiled DFU using another St Link connected to the BMP-ed St link (using the internal swdio and swclk pads), and lo and behold, everything woks, including dfu_utils

Incidentally, the best way to flash an St link with another St link, is to connect GND and 5V using dupont wires, then use two grabber test clips to connect SWDIO and SWCLK on the St link to be programmed. Do not use the 3.3V out of the St link, since most clones have rather dubious 3.3V regulators, and by connecting 5V together you are using the PC USB as a 5V supply, plus the 3.3V on each of the ST links. Picture enclosed
I'm also attaching the files I just compiled with TARGET=stlink, using the git repository as of today. Seems to be working fine. If you are converting an St link clone to BMP, might as well use this DFU and binary, so that in the future you can easily update with dfu_util, instead of having to use another ST link and test clips

I'm using this thread as a "brain dump" of all the issues I'm finding in Windows with BMP, to help others

While I can do pretty much anything using the Windows Subsystem for Linux (aka bash shell), it looks as if serial port support is still pretty flaky, and there's a problem using GDB in the WSL using BMP. In theory you would start the arm-none-eabi version of GDB, then connect to BMP with target extended-remote /dev/ttyS5 (for COM5, replace the value after ttyS with the first COM port BMP installs). But when you do, GDB hangs until you physically disconnect the BMP.

It turns out there's already an issue open, but no progress yet https://github.com/Microsoft/WSL/issues/3099

The workaround suggested in the issue works:

• However, if I run Putty and open the serial device, it show the `$OK` that indicates the GDB server is waiting. And now if I **go back** to WSL and try it, it works fine. And will continue to work until the next time I unplug and re-plug in the USB device.

(please note that you need to exit PuTTY after connecting to the port, and that the connection speed doesn't seem to matter)

So pretty much everything seems to work. Next step is to hack the BMP-ized st link and add the ability to do serial wire debug vis TRACESWO, as per https://lujji.github.io/blog/stlink-clone-trace/