Making firmware hacking easier
  • This week, I plan to fix a couple of things to make the firmware hacking of modules easier.

    The first step is to provide an official build environment that can be installed with only a few commands. I settled with VirtualBox running a Linux virtual machine, the whole thing managed by vagrant. It’s still a tiny bit of work to install VirtualBox and Vagrant on OS X / Windows / Linux, but from there we can all have the same development environment.

    You can find the vagrant file and virtual machine initialization script * here *.

    The second step is to progressively check that the firmware of all modules are not over capacity (code size and/or CPU) when compiled with a more recent versions of gcc than the antiquated 4.5.2 originally used during the development of braids (2012 !). For this purpose, I have rewritten a significant part of Braids’ code resulting in leaner and faster code, that is not so ticklish about compiler version. A few more tweaks and I’ll be able to publish a release candidate of the Braids code by the end of the week. After that, I’ll focus on all the other STM32F1 modules (Tides, Frames, Peaks, Yarns, and Streams).

  • wow and USB support. Just in time for a new linux box

  • Hot damn! I’m excited! :)
    Thanks again for all of your work and commitment to staying opensource!

  • This is cool, thank you pichenettes!

    a|x

  • Thanks a lot for making your products living and evolving gems !

  • Confirmed working on 64 bit win7 and win10 using bitvise as the SSH client.

    I see the STlink in the USB devices, is that confirmed working? That’s one thing I’d love to get working in a linux shell

  • Great! Looking forward to the firmware refactorings and the compiler upgrade which was indeed much needed.

    Isn’t Vagrant a bit overkill for the task though? Last time I used it, it was to install a dev env of gigabytes of Java, C and Scala shared library and complex configs of database servers and… Compare to this, you only need the cross-compilation toolchain, don’t you? Anyway, he who can do more can do less I guess.

    A small remark though: in my experience, it’s never good to stick with one particular compiler version. It can result in brittle code that is hard to debug and port, because you are using particular bugs or idiosyncrasies of that version. On the contrary, code that can run on, say, 3 minor versions of GCC will be very robust and time-proof. I know, it’s a lot of work, but it will save you some in the long run.

  • > is that confirmed working?

    No, I don’t have one. I would appreciate if someone wrote a makefile rule for sending files to the device with stlink, though. It seems to be a popular device.

    > Isn’t Vagrant a bit overkill for the task though?

    Any other way of publishing a linux installation “recipe”. I’m not too keen on publishing an already “frozen” VM environment – the file is too large!

    > it’s never good to stick with one particular compiler version

    For the older projects, the problem is the CPU use and flash storage of the generated code. For the newer projects, there might be small issues of CPU use.

    The alternatives are:

    • writing very large chunks of code in assembly.
    • downgrading the performance/audio quality of some products.
    • upgrading to a bigger processor (which one??) or overclocking with risks of unexpected glitches/failures.

  • @pichenettes You sir are a hero.

  • > Any other way of publishing a linux installation “recipe”. I’m not too keen on publishing an already “frozen” VM environment – the file is too large!

    What’s the problem you see with the situation now?

  • No idea what I am talking about but could this be usefull as platform

  • > What’s the problem you see with the situation now?

    Currently, to build the code, you have to install a bunch of stuff, which might or might not interfere with things already present on your machine.

    The goal is to provide a way of having on your machine, in as few steps as possible, a development environment “blessed” by Mutable Instruments, be 100% sure that everything is correctly configured, and be able to throw everything away without messing with your machine in case you want to move on.

  • > you have to install a bunch of stuff

    On a mac, it basically boils down to unzipping an archive wherever you want, and setting a path in the makefile stmlib, and install Python Libserial/OpenOCD if you want FTDI/JTAG support. Wouldn’t a step-by-step tutorial be quicker? Is it more complicated on Windows?

    If you want it to be simpler than that, then you’ll have to go the VM route, but in this case a standard Linux distro with the tools, compiler and couple of text editors will suffice.

  • Nice! Having a known-good setup is quite useful, I ended up with a similar VM until I figured out my programmer hardware was defective and not openocd/drivers/system/me.

  • There are extensive and detailed notes on how to set up the toolchain etc on a Mac on this forum, compiled by @flocked, but lots of people on MW fell at that hurdle, it seems. Thus a packaged build environment seems like a good idea, although I wonder that people able to fiddle with the code can’t install toolchain. But then, lots of people who program for a living seem to need a graphical IDE these days. Have a standard toolchain with a standard compiler version is the more important objective, and a Vagrant environment seems like a good way of doing this. I’ll test it with ST-Link v2 when I get home next week.

  • I’ve added some stuff for ST-link support, and for installing the FTDI drivers. What’s missing: rules in stmlib/makefile.inc for sending the firmware to the device with STlink.

  • Olivier, have you looked at my OpenOCD config for the ST-link v2? I’m not using the proprietary ST-link utilities, and it’s integrated in your makefiles. With a bit of massaging one could make it parametric on the adapter. Here’s the commit:

    https://github.com/mqtthiqs/stmlib/commit/bc00be289e0c64395ef3fba65158e9ad34977300

  • Thanks! Let me know if this works

    You have to change the PGM_INTERFACE and PGM_INTERFACE_TYPE variables in stmlib/makefile.inc and that’s it!

  • Cool, I’ll try the tiny version later! Wouldn’t ?= allow setting without editing the makefile?

  • > Let me know if this works

    I’d rather let someone else test it if possible, I don’t have all the software installed… sorry :-/

  • I’m not asking you to test the vagrant environment, but the new makefile / openocd scripts!

  • Oh sorry, ok! I’ll try that tomorrow.

  • Did a quick upload with PGM_INTERFACE=arm-usb-tiny-h in VM, seems to have worked without issues.

  • Yep, I can confirm, communication with my st-link-v2 works fine.

  • Ok, I guess I have a VM issue since this is what I get when trying to program via the VM:

    Error: The specified debug interface was not found (hla)
    The following debug interfaces are available:
    1: ft2232
    2: ftdi
    Runtime Error: stmlib/programming/jtag/interface_stlink-v2.cfg:28:
    in procedure ‘script’
    at file “embedded:startup.tcl”, line 58
    in procedure ‘interface’ called at file “stmlib/programming/jtag/interface_stlink-v2.cfg”, line 28
    Open On-Chip Debugger 0.7.0 (2015-09-03-11:04)
    Licensed under GNU GPL v2
    For bug reports, read http://openocd.sourceforge.net/doc/doxygen/bugs.html
    Error: The specified debug interface was not found (hla)
    The following debug interfaces are available:
    1: ft2232
    2: ftdi
    Runtime Error: stmlib/programming/jtag/interface_stlink-v2.cfg:28:
    in procedure ‘script’
    at file “embedded:startup.tcl”, line 58
    in procedure ‘interface’ called at file “stmlib/programming/jtag/interface_stlink-v2.cfg”, line 28
    make: *** [upload_combo_jtag] Error 1

    I cloned the contents of the stmlib directory, changed the programmer the st-link and interface to hla

    Also added a filter for the stlink since the one in the virtualbox list was listed as “inactive” and there was a different entry available for the stlinkv2

  • Let me check… maybe openocd needs to be built with special flags to support stlink.

  • altitude: 1/ rebuild a VM with the file I have just committed. It compiles openOCD with STLINK support.

    2/ Try it! The OpenOCD config files appear to work for Mqtthiqs, but I get errors here. Try removing some stuff in stm32f4xx_hla.cfg and stm32f10x_hla.cfg:

    • The arguments -irlen 4 -ircapture 0x1 -irmask 0xf
    • The line jtag_ntrst_delay 100

    From that point I can’t do any further test because I don’t have any STLink board!

  • Will do. I’ll report back later when I’m back at the lab

  • Nice idea, though I’m not sure if it should be that specific to Virtualbox/Vagrant. Actually it’s pretty easy – at least with Linux – to use KVM/Qemu with libvirt/virt-manager instead, so I think a more generic bootstrap-script (without the Virtualbox/Vagrant stuff) which could be run after a fresh installation (doesn’t even need to be a virtual machine) could be also much of use. But then again, a preseed file for the Debian/Ubuntu Installer could also be sufficient.

    Anyways, I guess >99% of MI users will be just happy with Virtualbox/Vagrant, and all others are happy to read such a script instead of searching through forum postings.

  • still no dice. I tried it as is and with the changes

    jtag
    adapter speed: 1000 kHz
    adapter_nsrst_delay: 200
    trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain connect_deassert_srst
    Runtime Error: embedded:startup.tcl:20: Unknown param: -irlen, try one of: or -expected-id
    in procedure ‘script’
    at file “embedded:startup.tcl”, line 58
    in procedure ‘hla’ called at file “stmlib/programming/jtag/stm32f10x_hla.cfg”, line 64
    in procedure ‘ocd_bouncer’
    at file “embedded:startup.tcl”, line 20
    Open On-Chip Debugger 0.8.0 (2015-09-03-22:25)
    Licensed under GNU GPL v2
    For bug reports, read http://openocd.sourceforge.net/doc/doxygen/bugs.html
    jtag
    adapter speed: 1000 kHz
    adapter_nsrst_delay: 200
    trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain connect_deassert_srst
    Runtime Error: embedded:startup.tcl:20: Unknown param: -irlen, try one of: or -expected-id
    in procedure ‘script’
    at file “embedded:startup.tcl”, line 58
    in procedure ‘hla’ called at file “stmlib/programming/jtag/stm32f10x_hla.cfg”, line 64
    in procedure ‘ocd_bouncer’
    at file “embedded:startup.tcl”, line 20
    make: *** [upload_combo_jtag] Error 1
    vagrant@vagrant-ubuntu-trusty-64:/vagrant/eurorack-modules$

  • ok, there was an -irlen 5 argument as well so I ditched that and now I have some blinky going on on the programmer but and this is the output

    jtag
    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 : This adapter doesn’t support configurable speed
    Info : STLINK v2 JTAG v23 API v2 SWIM v4 VID 0x0483 PID 0x3748
    Info : using stlink api v2
    Info : Target voltage: 3.247895
    Warn : Invalid ACK 0 in JTAG-DP transaction
    Error: Target not examined yet
    Runtime Error: stmlib/programming/jtag/prelude_f10x.cfg:25:
    in procedure ‘script’
    at file “embedded:startup.tcl”, line 58
    in procedure ‘halt’ called at file “stmlib/programming/jtag/prelude_f10x.cfg”, line 25
    make: *** [upload_combo_jtag] Error 1
    vagrant@vagrant-ubuntu-trusty-64:/vagrant/eurorack-modules$

  • mqtthiqs: did you have to remove the irlen arguments to make the makefile work? If not, which version of openocd are you using?

    If we can’t get it working this way, I’ll add a rule that I’ll use st-flash.

    altitude: can you check that this command does the right thing?

    st-flash write build/braids/braids_bootloader_combo.bin 0x08000000

  • Hi. No, didn’t have to remove the irlen argments, it worked out of the box (setting the variables PGM_INTERFACE and PGM_INTERFACE_TYPE). I’m using OpenOCD 0.9.0 as packaged by Macports on OSX. There is among others an “st-link” port variant, which means that there is probably a build option for it. My OpenOCD uses only the default port variants.

  • Will try to upgrade openocd to 0.9.

  • I’m working with a tides btw, but I dont think that matters

    vagrant@vagrant-ubuntu-trusty-64:/vagrant/eurorack-modules$ st-flash write braids/braids_bootloader_combo.bin 0x08000000
    2015-09-04T11:09:58 INFO src/stlink-common.c: Loading device parameters….
    2015-09-04T11:09:58 INFO src/stlink-common.c: Device connected is: F1 Medium-density device, id 0x20036410
    2015-09-04T11:09:58 INFO src/stlink-common.c: SRAM size: 0x5000 bytes (20 KiB), Flash: 0x20000 bytes (128 KiB) in pages of 1024 bytes
    open(braids/braids_bootloader_combo.bin) -1 2015-09-04T11:09:58 ERROR src/stlink-common.c: map_file() -1
    stlink_fwrite_flash() == -1

  • build/braids/braids_bootloader_combo.bin?

  • (deleted silly messages because I realized you were trying stlink directly, not openocd)

    And yeah, pld is right, the path to the bin file is wrong!

  • I tried this again with the right file and path. I think you’re almost there, I get activity on the programmer.

    For your reference, I have the STlink2 running the the latest firmware (V2.J23.S4)

    vagrant@vagrant-ubuntu-trusty-64:/vagrant/eurorack-modules$ st-flash write build/tides/tides_bootloader_combo.bin 0x08000000
    2015-09-04T11:35:19 INFO src/stlink-common.c: Loading device parameters….
    2015-09-04T11:35:19 INFO src/stlink-common.c: Device connected is: F1 Medium-density device, id 0x20036410
    2015-09-04T11:35:19 INFO src/stlink-common.c: SRAM size: 0x5000 bytes (20 KiB), Flash: 0x20000 bytes (128 KiB) in pages of 1024 bytes
    2015-09-04T11:35:19 INFO src/stlink-common.c: Attempting to write 121064 (0x1d8e8) bytes to stm32 address: 134217728 (0x8000000)
    2015-09-04T11:35:19 WARN src/stlink-common.c: unknown coreid 3ba00477, page erase failed
    2015-09-04T11:35:19 ERROR src/stlink-common.c: Failed to erase_flash_page(0x8000000) -1 stlink_fwrite_flash() -1

  • Maybe you have to use another command before to erase the chip?

  • 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 bootstrap.sh 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 with this 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 ;)

  • 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/depends.mk’ 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 :) ). 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 https://www.adafruit.com/products/2548 )
    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?
    Thanks

  • 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/makefile.inc

  • 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 :)

  • Sorry ignore this, i worked it out
    Thanks
    Jam

  • 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
    https://www.adafruit.com/products/2094 and a cable like this one https://www.adafruit.com/product/1675 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/makefile.inc :
    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_INTERFACE_TYPE ?= hla
    PGM_SERIAL_PORT ?= /dev/stlinkv2_1
    PGM_SERIAL_BAUD_RATE ?= 115200
    PGM_SERIAL_VERIFY ?= -v
    

    /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/depends.mk
    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
    	http://openocd.org/doc/doxygen/bugs.html
    hla_jtag
    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.

  • Hello Mqtthiqs,
    Thanks for your answer. i’ve tried with and without the 2 jumpers. When they’re off the stinkv2 tries to connect to an external chip. when they’re on, the stinkv2 is linked to the internal chip. (i’ve validated this with the ST Windows tool).
    Do you suggest that i comment the PGM_SERIAL_PORT line ?

    i’ve ordered a cable and will wait for it ! :)

  • Don’t change anything about the PGM_SERIAL_PORT line. It’s not used anyway but any of the commands you use.

  • Thanks ! Received the adapter and it works perfectly well with the real hardware :) Thanks so much for sharing this hacking environment !

  • Hi , try this and don’t understand the tutorial , the vagrant ssh must be run in OS X or the GUI of the VBOX ?
    i did in the virtual box but ask me for a password

    ==> default: Checking if box ‘ubuntu/trusty64’ is up to date…
    Your VM has become “inaccessible.” Unfortunately, this is a critical error
    with VirtualBox that Vagrant can not cleanly recover from. Please open VirtualBox
    and clear out your inaccessible virtual machines or find a way to fix
    them.
    E-s-Pro:mutable-dev-environment-master E_$

  • “the vagrant ssh must be run in OS X”

    yes.

    “but ask me for a password”

    default password is “vagrant”.

  • hi ! i start from scratch and im going to somewhere , but my /vagrant is empty
    why could be that ??

    thank again !!!!

    Screen Shot 2015-12-06 at 13.44.42.png
    1019 x 480 - 65K
  • Ok pardon the noob question (but I assume this environment partially set up to make things easy)...
    I have the vagrant up and running on OSX 10.10
    I can build the hex and makefile
    ALL GOOD! Thank you!

    Now, I want to use my FTDI232 to flash Elements (or some other module).
    The Customization Page says that to use the stlink you can set your device like so…
    export PGM_INTERFACE=stlink-v2
    export PGM_INTERFACE_TYPE=hla

    a) how do I know what string to use for my FTDI?
    b) what does the “export PGM_INTERFACE_TYPE=hla” line do?

  • Do you have a FTDI232 device (USB->serial adapter) or a STlink board?

  • I also have a F4discovery I can test for you.
    I’m on OSX 10.10

  • Then you don’t need to mess with the jtag configuration since you won’t be using jtag.

  • Ah. Then I think I missed the part where I tell it how to use my FDTI232. Is it in the instructions somewhere?

    Just trying the :
    make -f clouds/makefile upload_combo_serial

    I get :
    Traceback (most recent call last): File “stmlib/programming/serial/stm32loader.py”, line 405, in <module> cmd.open(conf[‘port’], conf[‘baud’]) File “stmlib/programming/serial/stm32loader.py”, line 57, in open timeout=0.5 # set a timeout value, None for waiting forever File “/usr/lib/python2.7/dist-packages/serial/serialutil.py”, line 261, in init self.open() File “/usr/lib/python2.7/dist-packages/serial/serialposix.py”, line 278, in open raise SerialException(“could not open port %s: %s” % (self._port, msg))
    serial.serialutil.SerialException: could not open port /dev/ftdi-usbserial: [Errno 2] No such file or directory: ‘/dev/ftdi-usbserial’
    make: *** [upload_combo_serial] Error 1

    And for elements (still had to build the bootloader hex btw)

    vagrant@vagrant-ubuntu-trusty-64:/vagrant/eurorack-modules$ make -f elements/makefile upload_combo_serial
    cat build/elements/elements.hex build/elements_bootloader/elements_bootloader.hex | \ awk -f stmlib/programming/merge_hex.awk > build/elements/elements_bootloader_combo.hex
    /usr/local/arm-4.8.3/bin/arm-none-eabi-objcopy -I ihex -O binary build/elements/elements_bootloader_combo.hex build/elements/elements_bootloader_combo.bin
    python stmlib/programming/serial/stm32loader.py \ -p /dev/ftdi-usbserial \ -b 115200 \ -e -v \ -w build/elements/elements_bootloader_combo.bin
    Traceback (most recent call last): File “stmlib/programming/serial/stm32loader.py”, line 405, in <module> cmd.open(conf[‘port’], conf[‘baud’]) File “stmlib/programming/serial/stm32loader.py”, line 57, in open timeout=0.5 # set a timeout value, None for waiting forever File “/usr/lib/python2.7/dist-packages/serial/serialutil.py”, line 261, in init self.open() File “/usr/lib/python2.7/dist-packages/serial/serialposix.py”, line 278, in open raise SerialException(“could not open port %s: %s” % (self._port, msg))
    serial.serialutil.SerialException: could not open port /dev/ftdi-usbserial: [Errno 2] No such file or directory: ‘/dev/ftdi-usbserial’
    make: *** [upload_combo_serial] Error 1

  • What do you see when you run the following command:

    ls /dev/

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

  • I believe so. Here is the screenshot of the VB settings.

    However, when I ls that dir in mac terminal, I also do not see it :( I just installed the 32 bit driver on this page http://www.ftdichip.com/Drivers/VCP.htm
    and I had been flashing before from Mac with it before at home. Just tried a flash from mac and no luck either. So obviously not a flaw in the vagrant so far, but any clues what’s going on?

    here is what I see in Mac terminal (10.11.2 work computer)
    mattjacksonsoma:~ mattjackson$ ls /dev
    afsc_type5 ptyw7
    auditpipe ptyw8
    auditsessions ptyw9
    autofs ptywa
    autofs_control ptywb
    autofs_homedirmounter ptywc
    autofs_notrigger ptywd
    autofs_nowait ptywe
    bpf0 ptywf
    bpf1 random
    bpf2 rdisk0
    bpf3 rdisk0s1
    bpf4 rdisk0s2
    console rdisk0s3
    cu.Bluetooth-Incoming-Port rdisk1
    disk0 rdisk10
    disk0s1 rdisk10s1
    disk0s2 rdisk10s2
    disk0s3 rdisk11
    disk1 rdisk11s1
    disk10 rdisk11s2
    disk10s1 rdisk12
    disk10s2 rdisk12s1
    disk11 rdisk12s2
    disk11s1 rdisk2
    disk11s2 rdisk2s1
    disk12 rdisk2s2
    disk12s1 rdisk3
    disk12s2 rdisk3s1
    disk2 rdisk3s2
    disk2s1 rdisk4
    disk2s2 rdisk4s1
    disk3 rdisk4s2
    disk3s1 rdisk5
    disk3s2 rdisk5s1
    disk4 rdisk5s2
    disk4s1 rdisk6
    disk4s2 rdisk6s1
    disk5 rdisk6s2
    disk5s1 rdisk7
    disk5s2 rdisk7s1
    disk6 rdisk7s2
    disk6s1 rdisk8
    disk6s2 rdisk8s1
    disk7 rdisk8s2
    disk7s1 rdisk9
    disk7s2 rdisk9s1
    disk8 rdisk9s2
    disk8s1 stderr
    disk8s2 stdin
    disk9 stdout
    disk9s1 systrace
    disk9s2 tty
    dtrace tty.Bluetooth-Incoming-Port
    dtracehelper ttyp0
    fbt ttyp1
    fd ttyp2
    fsevents ttyp3
    io8log ttyp4
    io8logmt ttyp5
    io8logtemp ttyp6
    klog ttyp7
    lockstat ttyp8
    machtrace ttyp9
    nsmb0 ttypa
    null ttypb
    pf ttypc
    pfm ttypd
    pmCPU ttype
    profile ttypf
    ptmx ttyq0
    ptyp0 ttyq1
    ptyp1 ttyq2
    ptyp2 ttyq3
    ptyp3 ttyq4
    ptyp4 ttyq5
    ptyp5 ttyq6
    ptyp6 ttyq7
    ptyp7 ttyq8
    ptyp8 ttyq9
    ptyp9 ttyqa
    ptypa ttyqb
    ptypb ttyqc
    ptypc ttyqd
    ptypd ttyqe
    ptype ttyqf
    ptypf ttyr0
    ptyq0 ttyr1
    ptyq1 ttyr2
    ptyq2 ttyr3
    ptyq3 ttyr4
    ptyq4 ttyr5
    ptyq5 ttyr6
    ptyq6 ttyr7
    ptyq7 ttyr8
    ptyq8 ttyr9
    ptyq9 ttyra
    ptyqa ttyrb
    ptyqb ttyrc
    ptyqc ttyrd
    ptyqd ttyre
    ptyqe ttyrf
    ptyqf ttys0
    ptyr0 ttys000
    ptyr1 ttys001
    ptyr2 ttys1
    ptyr3 ttys2
    ptyr4 ttys3
    ptyr5 ttys4
    ptyr6 ttys5
    ptyr7 ttys6
    ptyr8 ttys7
    ptyr9 ttys8
    ptyra ttys9
    ptyrb ttysa
    ptyrc ttysb
    ptyrd ttysc
    ptyre ttysd
    ptyrf ttyse
    ptys0 ttysf
    ptys1 ttyt0
    ptys2 ttyt1
    ptys3 ttyt2
    ptys4 ttyt3
    ptys5 ttyt4
    ptys6 ttyt5
    ptys7 ttyt6
    ptys8 ttyt7
    ptys9 ttyt8
    ptysa ttyt9
    ptysb ttyta
    ptysc ttytb
    ptysd ttytc
    ptyse ttytd
    ptysf ttyte
    ptyt0 ttytf
    ptyt1 ttyu0
    ptyt2 ttyu1
    ptyt3 ttyu2
    ptyt4 ttyu3
    ptyt5 ttyu4
    ptyt6 ttyu5
    ptyt7 ttyu6
    ptyt8 ttyu7
    ptyt9 ttyu8
    ptyta ttyu9
    ptytb ttyua
    ptytc ttyub
    ptytd ttyuc
    ptyte ttyud
    ptytf ttyue
    ptyu0 ttyuf
    ptyu1 ttyv0
    ptyu2 ttyv1
    ptyu3 ttyv2
    ptyu4 ttyv3
    ptyu5 ttyv4
    ptyu6 ttyv5
    ptyu7 ttyv6
    ptyu8 ttyv7
    ptyu9 ttyv8
    ptyua ttyv9
    ptyub ttyva
    ptyuc ttyvb
    ptyud ttyvc
    ptyue ttyvd
    ptyuf ttyve
    ptyv0 ttyvf
    ptyv1 ttyw0
    ptyv2 ttyw1
    ptyv3 ttyw2
    ptyv4 ttyw3
    ptyv5 ttyw4
    ptyv6 ttyw5
    ptyv7 ttyw6
    ptyv8 ttyw7
    ptyv9 ttyw8
    ptyva ttyw9
    ptyvb ttywa
    ptyvc ttywb
    ptyvd ttywc
    ptyve ttywd
    ptyvf ttywe
    ptyw0 ttywf
    ptyw1 urandom
    ptyw2 vboxdrv
    ptyw3 vboxdrvu
    ptyw4 vboxnetctl
    ptyw5 zero
    ptyw6

  • Found out that Apple installs FTDI drivers that conflict with the VCP drivers in the Yosemite/El Capitan updates.
    Will try the fix here tomorrow

  • No luck. Not showing up even in my apple system profiler in the USB. It’s getting the red power light though. Tried different cables.

  • Tried on two other computers using mac terminal to connect. No luck. Maybe my programer is fried. I ordered two new ones. If it still doesn’t work with a brand new one, then I’m curious what the missing info to install the FTDI driver is and will find out elsewhere and post to a new discussion.

  • Why don’t you just order an FTDI Friend from Adafruit, as Olivier recommends on the relevant web pages? It is known to work.

  • I got a new one and it works. my old one but have broken. So … carry on. Confirmed that serial upload works from vagrant without any config (using FTDI chips)

  • I have an Olimex, but not the adaptors. Unfortunate that I’m in Thailand and ordering from Adafruit will cost me several times the purchase price in shipping! I do have a Discovery board and I’m comfortable using the STLink utility. Does anyone here have experience with this setup, particularly the connection of the Discovery to the MI SWD? Thanks!

  • Alternatively, can someone give me the pinout for the adaptor for the Olimex? I’m sure I can rig something. Much appreciated.

  • @Gary:

    Yes, I always use openocd / SWD via the 6 pin discovery header.

    It’s a bit messy / fiddly without a proper 2x5 1.27 cable and suitable adapter though. Here is a template for a 6 pin SWD < > 2x5 Cortex Debug < > Old school JTAG adapter : https://github.com/PatternAgents/JTAG20M-STLV2F (Someone posted it on Muffwiggler.com)

    As there’s only a few (SWD) signals involved, I suppose the alternative would be to just solder some cables onto a 2x5 1.27 socket, directly.

  • @ubiubu

    Many thanks. I’m trying to figure out the 6-pin first, as I haven’t had any luck finding the right socket for the 2x5 locally. (pain in the arse)

    There’s only 3 pins connected on the Peaks board, 4 and 5 being RX and TX respectively on Peaks, and TMS and TRST/ on discovery. Do you happen to know if I need to swap these or connect them straight?

  • That’s USART1 you’re looking at — For JTAG/SWD, you need to use the 2x5 header:

    SWDIO (4) < > JTMS (2) and SWDCLK (2) < > JTCK (4) , as well as VDD and GND.

  • Is openocd support of SWD good? I have a few upcoming boards which are very dense and I’d like to use something lighter than the 2x5 JTAG and all those damn traces.

  • I’m using SWD with OpenOCD on a newer project. Works like a charm (once you find the right combination of arcane options in the config file). I don’t know about the gain with traces, but the standard-sized 4-pins headers are not that larger than the tiny 8-pins JTAG ones…

  • It’s faster to put 4 big blobs of solder than 10 small ones – and this frees a few MCU pins. Sometimes it’s just enough to make a project doable with a 48 pin MCU instead of the 64-pin version.

  • I see (and yes, it’s 10 pins not 8).
    Well, what I can say is that all features I used with JTAG on your modules (code upload, memory mangling, break/watchpoints…) still work with SWD with no apparent difference. The updated config files with SWD support are in my stmlib fork on GH.

  • I had no issues with SWD either, did the 4ms SMR which only had SWD headers and the process was no different on windows/STlink2 other than the different connector

  • @altitude

    Maybe you can help me. I just finished flashing 4ms DLD (I’m the co-designer) using STlink2 with Discovery board. Works simply and flawlessly Then I moved to Peaks and had no luck at all. I could put Peaks into ‘load’ mode but STlink reports ‘No target detected.’ Experimented with connections, settings in STlink etc. But no joy. Do you see anything I might be misunderstanding or neglecting? Thanks.

  • The SMR has a 4 pin SWD header, that’s P13 (SWDIO) and P14 (SWCLK) (and VDD and GND), as with Peaks (and I presume, the DLD). Except on Peaks, these two signals are available on the 2x5 “Cortex debug” header. It will work the same way, if you use those signals.

    As I said above, I strongly suspect you’re looking at the wrong header (which has PA9 (TX) and PA10 (RX) (and no VDD)). It simply happens to be 6 pins.

  • Yes, the TX/RX pins are for a serial adapter (like those FTDI thingies).

    My modules don’t have connectors for SWD – but with the right adapter cable, you can use a SWD programmer.

  • Okay! I got it.

    The DLD uses a 6-pin SWD the first 4 pins of which match the SMR’s connector. I couldn’t tell you why. Dan changed it in a relatively recent turn of the board.

  • What is the best way to work with this virtual environment and organize changes/branches to my firmware hacking endeavors? As someone who is still learning and making mistakes along the way through trial and error, I am curious how to best approach this without having to make a bunch of back up files whenever I make changes. I know branches with git is very useful for this but I am not sure how to handle this with the virtual box and how to move files back and forth efficiently.

  • You can use all the git commands you want (for example, the very useful “git stash”) from the VM command line.

  • Ah okay, that makes sense. Git stash looks very useful, I’ll need to do some more research to get used to the available commands. Thank you, I’m excited to try to wrap my head around what is going on under the hood of my favorite modules. Hopefully I can make something useful enough to share in the future.

  • Edit: oops, double posted

  • bonobo: if you’re not already I suggest to get really confortable with Git, it’s an invaluable tool. My whole life basically happens under git control :). The key is to commit really often, and even to split your commits into atomic changes, so that you can go back and analyze your log if things go wrong.
    A useful tool for the beginner (that I still use every day) is “git gui”: it allows you to prepare commits by selecting changes line-by-line. “git stash” is indeed irreplaceable too. In many cases, “git bisect” can also help you spot long-standing issues. And don’t underestimate the power of “git diff”!

  • I use git very often, too. Very useful tool. I find the command line interface very unconvenient (maybe because I’m too lazy to learn it properly) so I use Atlassian Source tree as a gui. Very handy, as it includes all the useful features and presents them on a very clean interface.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

In this Discussion