Making firmware hacking easier


Maybe st-flash erase? Another makefile I have just does the write, but it’s an F4 project, maybe the F1 is different. I might still have an f4discovery board somewhere so can try that over the weekend.


I erased the chip with the windows utility before try this. Mind you this is still using yesterdays build, nothing new has been installed since then


Try editing all references to 0.8.0 into 0.9.0 into the file and rebuilding the VM. This is the latest version of openocd, it accepts all the extra hla newtap arguments and it looks like this is what mqtthiqs is using.


With a newly built VM (running on OS X) and the stm32f4Discovery jumpered to…
-> Peaks: st-flash write build/peaks/peaks.bin 0x08000000
-> H405: st-flash write build/clouds/clouds_bootloader_combo.bin 0x08000000
both resulted in “INFO src/stlink-common.c: Flash written and verified! jolly good!”

With some poking of the .cfg files, I was able to at least upload_jtag_combo to Peaks (the erase and debug targets don’t work though). Mainly it needs hla_swd as transport, and expected a different CPUTAPID of 0x1ba01477 instead of 0x3ba00477. The openocd files comment this withthis is the SW-DP tap id not the jtag tap id_. I checked the debug output of st-flash and it also shows a core id of 0x1ba01477 instead of the 3ba00477 for altitude’s Tides.

I guess the cabling makes the STLinkV2 work in jtag, not swd mode since st-flash has no such option? Anyway, openocd seems easier :wink:


success! Going to 0.9.0 did the trick, no other changes made (other than changing to STlink and hla)

Successfully flashed tides combo on Win10 with the VM and the STlinkV2


this is great! thanks pichenettes.

at first the vm wouldn’t start.
after i enabled the intel virtualisation feature in my uefi bios, i worked right away. (i am on win 7-64; intel i5)


I haven’t tried it with my STLinkV2 yet, however, installation of the VirtualBox and Vagrant environment was straightforward as per the instructions, and the firmware code compiles correctly. However, make is emitting this warning:

make: warning: Clock skew detected. Your build may be incomplete.

At first I thought that was because I am running in the GMT+10 timezone, but of course the VM is using GMT time. However, buried in the make output, not adjacent to the warning shown above, is the following warning:

make: Warning: File `build/braids/’ has modification time 0.75 s in the future

The actual time skew reported seems to vary between 0.17 s and 0.9 s. The host is a MacBook Pro running OS X 10.10.5 and yes, it syncs its time from the Apple time servers (the Asian one, but changing to the European or US Apple time servers makes no difference).

None of this matters - the code compiles fine, I am just mentioning it for completeness. I’ll install on my Mac Pro as well and report if the warning appears there as well.


I installed the vagrant environment on my 2008 Mac Pro, also running OS X 10.10.5, and no such warnings are evident. I think they are an ignorable anomaly and I shan’t be investigating them further.


Hello, warning noob post here.
I run win7 on x64. I succesfully compiled the firmware the classic way…and the vagrant way (witch blew my mind :slight_smile: ). Anyways, i planned carefully the build of clouds. Made the pcb, sourced the parts (on the way)… and found a second hand st-link v2( this one to be more specific )

  1. Can anybody clue me in in the wiring. it didnt came with cable just with some jumpers.
  2. This v2, as i read, is suported by the latest vagrant so it should work with no probs?


if its compatible it should work fine. You still need the right cable (1.27mm pitch) and you have to change the PGM_INTERFACE and PGM_INTERFACE_TYPE variables in stmlib/


Ok. After some reserch on adapters from jtag to swd i need to connect 4 pins. on clouds PIN 1 - 3.3v and PIN 3 - GND; and PIN2 JTMS to SWDIO and pin 4 - JTCK to SWCLK. Is this correct?
And could i upload via stlink utility? first bootloader and then firmware?


the VM includes scripts for uploading through OpenOCD (which now supports the STLink adapter). Don’t know about the stlink utility.


dont know why you would use SWD instead of JTAG, just get the 10 pin 2.54mm pitch to 1.27mm pitch cable from adafruit and you’re done…


There’s nothing wrong with using SWD. (The thing in question, if I see it right, is SWD only anyways.)

The only slightly inconvenient thing with those cheap USB thingies (or disco & nucleo boards) is there seem to be few readily available adapters that map those pin outs to the orthodox 2x5 Cortex Debug header. The cheap ones available (adafruit, olimex) are all 20-pin “legacy” to 2x5, AFAIS. That’s all there is to it; some kind of adapter is needed either way. A more suitable, proper adapter is not expensive to get fabbed.

@condor13 – As for the pins, this looks about right.


This raises an import question: what’s the most standard, “orthodox” debug port? JTAG or SWD? Should I switch to SWD?


I don’t know. There doesn’t seem to be much in the way of SWD orthodoxy; unlike the previous discovery boards (1x6) the M7 discovery boards for instance now have a new 1x4 2.54mm SWD header, it looks like.

I guess in cases where there’s enough space, it might be convenient to have some kind of 2.54mm header in addition, though much the same can be achieved with a little adapter pcb. As per ARM, the fine pitch 2x5 one is advertised for both JTAG and SWD, so from that perspective that’s totally fine, I’d say.


altitude - this is what i found around (buying olimex, or ordering from adafruit just for one adapter would have taken time, more money bla bla...) i read that some people have succeeded with the "dongle" but not so good explanation with the pin out.pichenetts - i would totally agree with ubiubu on the “orthodox” debug port.
@ubiubu - thanks :slight_smile:


Sorry ignore this, i worked it out


Hi ! Thanks a lot for sharing this vagrant / vm.
I’m not really familiar with FTDI / JTAG or SWD so i’ve bought a STM32F407 discovery Board as well as a genuine STlink-v2.
I think i need an adapter like this one and a cable like this one in order to go deeper inside the firmware hacking on real MI modules.

I’ve tried to upload the compiled braids code to the discovery board without success (i’ve seen that Mqtthiqs has successfully managed to do it). Using the Windows ST "STM32 ST-LINK utility " tool on a VM is ok to upload the bin or the hex file.
i’m using the 0.9.0 version of openocd

lsusb seems to be ok :

vagrant@vagrant-ubuntu-trusty-64:/vagrant$ lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 013: ID 0483:3748 STMicroelectronics ST-LINK/V2
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

Here is my ./stmlib/ :
i’ve set the PGM_SERIAL_PORT to /dev/stlinkv2_1 as i have not tty.usb*

TOOLCHAIN_PATH ?= /usr/local/arm/
# Supported: arm-usb-ocd, arm-usb-ocd-h, arm-usb-tiny-h, stlink-v2
PGM_INTERFACE ?= stlink-v2
# hla for stlink-v2 ; jtag otherwise
PGM_SERIAL_PORT ?= /dev/stlinkv2_1

/dev/stlinkv2_1 links to /bus/usb/002/013 :

vagrant@vagrant-ubuntu-trusty-64:/vagrant/eurorack-modules$ ls -alh /dev/stlinkv2_1 
lrwxrwxrwx 1 root root 15 Oct  5 16:30 /dev/stlinkv2_1 -> bus/usb/002/013

vagrant@vagrant-ubuntu-trusty-64:/vagrant/eurorack-modules/stmlib$ ls /dev/
autofs           cuse      log           mapper              ptmx   ram2    rtc       stdout      tty15  tty24  tty33  tty42  tty51  tty60      ttyS10  ttyS2   ttyS29  uhid       vcs5   vcsa7
block            disk      loop0         mcelog              pts    ram3    rtc0      stlinkv2_1  tty16  tty25  tty34  tty43  tty52  tty61      ttyS11  ttyS20  ttyS3   uinput     vcs6   vga_arbiter
bsg              dri       loop1         mem                 ram0   ram4    sda       tty         tty17  tty26  tty35  tty44  tty53  tty62      ttyS12  ttyS21  ttyS30  urandom    vcs7   vhci
btrfs-control    ecryptfs  loop2         net                 ram1   ram5    sda1      tty0        tty18  tty27  tty36  tty45  tty54  tty63      ttyS13  ttyS22  ttyS31  vboxguest  vcsa   vhost-net
bus              fd        loop3         network_latency     ram10  ram6    sg0       tty1        tty19  tty28  tty37  tty46  tty55  tty7       ttyS14  ttyS23  ttyS4   vboxuser   vcsa1  zero
char             full      loop4         network_throughput  ram11  ram7    shm       tty10       tty2   tty29  tty38  tty47  tty56  tty8       ttyS15  ttyS24  ttyS5   vcs        vcsa2
console          fuse      loop5         null                ram12  ram8    snapshot  tty11       tty20  tty3   tty39  tty48  tty57  tty9       ttyS16  ttyS25  ttyS6   vcs1       vcsa3
core             hpet      loop6         port                ram13  ram9    snd       tty12       tty21  tty30  tty4   tty49  tty58  ttyprintk  ttyS17  ttyS26  ttyS7   vcs2       vcsa4
cpu              input     loop7         ppp                 ram14  random  stderr    tty13       tty22  tty31  tty40  tty5   tty59  ttyS0      ttyS18  ttyS27  ttyS8   vcs3       vcsa5
cpu_dma_latency  kmsg      loop-control  psaux               ram15  rfkill  stdin     tty14       tty23  tty32  tty41  tty50  tty6   ttyS1      ttyS19  ttyS28  ttyS9   vcs4       vcsa6

Here is the output error :

vagrant@vagrant-ubuntu-trusty-64:/vagrant/eurorack-modules$  make -f braids/makefile upload 
cat build/braids/analog_oscillator.d build/braids/braids.d build/braids/digital_oscillator.d build/braids/macro_oscillator.d build/braids/quantizer.d build/braids/resources.d build/braids/settings.d build/braids/ui.d build/braids/adc.d build/braids/dac.d build/braids/debug_pin.d build/braids/display.d build/braids/encoder.d build/braids/gate_input.d build/braids/internal_adc.d build/braids/system.d build/braids/uart_logger.d build/braids/random.d build/braids/bootloader_utils.d build/braids/system_clock.d build/braids/core_cm3.d build/braids/system_stm32f10x.d build/braids/misc.d build/braids/stm32f10x_adc.d build/braids/stm32f10x_bkp.d build/braids/stm32f10x_can.d build/braids/stm32f10x_crc.d build/braids/stm32f10x_dac.d build/braids/stm32f10x_dbgmcu.d build/braids/stm32f10x_dma.d build/braids/stm32f10x_exti.d build/braids/stm32f10x_flash.d build/braids/stm32f10x_fsmc.d build/braids/stm32f10x_gpio.d build/braids/stm32f10x_i2c.d build/braids/stm32f10x_iwdg.d build/braids/stm32f10x_pwr.d build/braids/stm32f10x_rcc.d build/braids/stm32f10x_rtc.d build/braids/stm32f10x_sdio.d build/braids/stm32f10x_spi.d build/braids/stm32f10x_tim.d build/braids/stm32f10x_usart.d build/braids/stm32f10x_wwdg.d build/braids/startup_stm32f10x_md.d > build/braids/
openocd -f stmlib/programming/jtag/interface_stlink-v2.cfg -f stmlib/programming/jtag/stm32f10x_hla.cfg -f stmlib/programming/jtag/prelude_f10x.cfg  -f stmlib/programming/jtag/erase_f10x.cfg -c "flash write_bank 0 build/braids/braids_bootloader_combo.bin 0x0" -c "verify_image build/braids/braids_bootloader_combo.bin" -f stmlib/programming/jtag/postlude.cfg || openocd -f stmlib/programming/jtag/interface_stlink-v2.cfg -f stmlib/programming/jtag/stm32f10x_hla.cfg -f stmlib/programming/jtag/prelude_f10x.cfg  -f stmlib/programming/jtag/erase_f10x.cfg -c "flash write_bank 0 build/braids/braids_bootloader_combo.bin 0x0" -c "verify_image build/braids/braids_bootloader_combo.bin" -f stmlib/programming/jtag/postlude.cfg
Open On-Chip Debugger 0.9.0 (2015-10-05-09:24)
Licensed under GNU GPL v2
For bug reports, read
adapter speed: 1000 kHz
adapter_nsrst_delay: 200
trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain connect_deassert_srst
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : clock speed 950 kHz
Info : STLINK v2 JTAG v14 API v2 SWIM v0 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 2.909911
Error: init mode failed (unable to connect to the target)
in procedure 'init' called at file "stmlib/programming/jtag/prelude_f10x.cfg", line 23
in procedure 'ocd_bouncer'

I know that i’m trying to do a “useless” upload, but i’m pretty sure that i’ll have the same problem with a MI board and the adafruit adapter.

Any help would be apreciated.

Thanks !


Hi arnaud,
First, as a remark, the PGM_SERIAL_PORT doesn’t have to be set like this. It’s only useful if you’re using an FTDI adapter. But that won’t help your problem.
All I can say is that the error message you get (“unable to connect to the target”) is the one I get when the st-link is properly connected to the computer, but not to a module on the other side. Have you looked at the position of the jumpers on the discovery board? I vaguely remember reading that one was switching between st-link mode or internal chip programming mode.
Otherwise, I’d recommend to wait for your adapter cable and try with a real MI module, I could see it working anyway.