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 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
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 )
- Can anybody clue me in in the wiring. it didnt came with cable just with some jumpers.
- 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/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
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.
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.