pichenettes / mutable-dev-environment Goto Github PK

Yesterday I tried compiling the code for grids. The README says the following:

make -f clouds/bootloader/makefile hex

Unfortunately there is no hex target for grids. I was still able to generate the hex file by running make -f grids/bootloader/makefile

I don't know what would be the best option between fixing the doc or adding the hex target to the grids makefile.

The filename for stlink source zip in texane github has changed, causing vagrant provisioning to fail.

Modifying 0_install-toolchain.sh and adding a "v" in front of the filename fixes it.

The two lines which need to be changed are in the #install stlink section

wget -nv https://github.com/texane/stlink/archive/v1.1.0.tar.gz
tar xfz v1.1.0.tar.gz

I have manually modified the file and reprovisioned and verified that the stlink source downloads and installs correctly.

Have you ever thought of moving the vagrant deploy to a docker image? Building and hosting the image would probably make the deployment of the dev environment a bit quicker. I would be happy to throw up a PR if you're interested.

I just finished building a Clouds module, it was a full kit that I purchased from synthCube. The STM chip was supposed to be pre-flashed but the module does not do anything upon power-up. I have set up the VirtualBox/Vagrant environment on my computer (MacMini running Sierra), using an STLink V2 with an Olimex ARM-JTAG-20-10 to connect to the module. When I try to upload this is what I get:

vagrant@vagrant-ubuntu-trusty-64:/vagrant/eurorack-modules$ make -f clouds/makefile upload_combo_jtag
openocd -s /opt/local/share/openocd/scripts/ -f interface/stlink-v2.cfg -f target/stm32f4x.cfg -c "init" -c "halt" -c "sleep 200"
-f stmlib/programming/jtag/erase_f4xx.cfg
-c "flash write_image erase build/clouds/clouds_bootloader_combo.bin 0x08000000"
-c "verify_image build/clouds/clouds_bootloader_combo.bin 0x08000000"
-c "sleep 200" -c "reset run" -c "shutdown"
Open On-Chip Debugger 0.9.0 (2020-08-25-19:04)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first available session transport "hla_swd". To override use 'transport select '.
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
adapter speed: 2000 kHz
adapter_nsrst_delay: 100
none separate
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
Info : clock speed 1800 kHz
Info : STLINK v2 JTAG v29 API v2 SWIM v7 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 3.007456
Error: init mode failed (unable to connect to the target)
in procedure 'init'
in procedure 'ocd_bouncer'

make: *** [upload_combo_jtag] Error 1

It appears that the computer is not seeing the processor. I have gone over the entire PCB several times, touched up several solder connections, checked continuity and routing against the circuit schematic and I can't find any errors. Does this mean that the processor chip is bad or is there some other communication error in play here??

TIA,
Dennis Kulpa

This came up for me and some others recently when trying to get the VM up on Win10 20H2 (which may or may not be relevant). After the 1st Vagrant up, it works fine but once the machine is halted and restarted it will no longer connect to the /vagrant folder and goes into a timeout loop. The work around is to "do-release-upgrade" on the first successful login which updates to Ubuntu 16.04.7 LTS, there is probably a much less time consuming fix but thats a bit above my pay grade.