On Ubuntu 20.04.
(I have not yet tried the Black Magic Probe and gdb parts)
First install the arm compiler:
sudo apt install gcc-arm-none-eabi gcc-arm-none-eabi-source
Get the mutable codebase from here https://github.com/pichenettes/eurorack
(or Parasites here: https://github.com/mqtthiqs/parasites )
AND UPDATE THE SUBMODULES:
git submodule init && git submodule update
Then set the TOOLCHAIN_PATH variable in your environment as following:
export TOOLCHAIN_PATH=/usr/
Try compiling the frames (or whatever) firmware into a build/frames/frames.hex file using the first following command. You should probably also build the bootloader hex file as well (the second command):
make -f frames/makefile
# Not working for me ...
# make -f frames/bootloader/makefile hex
If you modify anything in the source tree, you maaay need to run this:
touch frames/resources/resources.py && make -f frames/makefile resources
Note: This will NOT work if the module is bricked or has a fresh STM32 micro (you built the module last night or whatever).
The firmware can be updated using a wave file:
# No default Python2 on Ubuntu 20.04, but we need it ... so ...
virtualenv -p /usr/bin/python2 ~/.virtualenvs/eurorack
source ~/.virtualenvs/eurorack/bin/activate
# We need an older version of numpy
pip install numpy==1.11.3
# Update the PYTHONPATH so the `stm_audio_bootloader` module is always found
export PYTHONPATH=$PYTHONPATH:$(pwd)
make -f frames/makefile wav
Custom wav file generation settings - I found updating via the wav file very unreliable (probably 100s of failed tries under different volumes, devices etc). You can tweak the parameters of the generated wav, eg:
python stm_audio_bootloader/qpsk/encoder.py -s 48000 -b 12000 -c 6000 -p 256 build/frames/frames.bin
YMMV - I found the defaults were probably still the most reliable. What did seem to help is increasing the duration of the blank_duration used by encoder.code in stm_audio_bootloader/qpsk/encoder.py.
Then follow the manual to figure it out from there: http://mutable-instruments.net/modules/frames/manual
Note: This method does NOT use the upload scripts included in the Mutable Instruments eurorack repo's Makefiles!
Note: A fresh chip will turn all 4 LEDs on out of the gate. This is in contrast to what is written on the clouds open source Firmware hacking page. That page says that you can boot the thing into it's serial bootloader in a way that gets the LEDs to turn off. That is only the case if the module already has firmware on it as far as I can tell. My fresh module had all lights on. This is normal.
One the toolchain is installed and the code and bootloader are compiled, you can hook the probe up directly to the module's JTAG header and use gdb to push the code to the module.
Once you're hooked up, start up the ARM gdb and scan for the device. Note that Mutable Instruments modules need to use monitor swdp_scan to see the device.
Follow these steps to get everything working:
% git clone [email protected]:pichenettes/eurorack.git
% cd eurorack/
% git submodule init && git submodule update
% export TOOLCHAIN_PATH=/usr/
% make -f clouds/makefile
% make -f clouds/bootloader/makefile hex
% arm-none-eabi-gdb
[...]
(gdb) monitor swdp_scan
(gdb) attach 1
(gdb) set mem inaccessible-by-default off
(gdb) load build/clouds_bootloader/clouds_bootloader.hex
[...]
(gdb) load build/clouds/clouds.hex
[...]
(gdb) quit
After running the final load, you should see the module blink through it's bootup and then turn off all of it's LEDs.
Unplug the programmer, power cycle the module, and make sure it boots up by blinking it's leds!
You should have a working module now!
getting started: https://github.com/blacksphere/blackmagic/wiki/Getting-Started
Useful commands (and debugging help): https://github.com/blacksphere/blackmagic/wiki/Useful-GDB-commands