Korg Volca FM is a great little FM synthesizer which also includes a step sequencer.

Inside there are 2 PCBs linked together via a 7pin connector. The main PCB has an ARM-CortexM4 which is the core of the whole synthesizer, all waveforms are computed inside this device. The second PCB has the touch sensitive keys and the sequencer LEDs which are all handled by a support microcontroller from Cypress. The two processors are probably talking to each other via the SPI interface (I haven't checked this).

There are 11 + 2 linear potentiometers on this board, each producing an analog voltage between 0-3.3V. These analog voltages are multiplexed and the read directly by two ADCs inputs of the ARM processor. A separate rotary encoder selects the algorithm.

Click on the images bellow to identify all the ICs used in this design:

There is only one DIN5 connector for MIDI In mainly for saving space but the MIDI Out pins are available and clearly marked on the board if someone wants to solder a second pigtail DIN connector. The MIDI Out is not so important if one doesn't want to use the internal sequencer to drive other instruments.

The touch keys of the Volca FM are not really made for playing, they feel more like toy keys so the great majority of users are playing the synthesizer via MIDI In. Unfortunately there is a major drawback by doing this, the NoteOn velocity parameter is ignored by the Volca. You can still change the velocity of the played notes using the slider potentiometer but you cannot do this remotely.

A firmware update could easily solve this problem but that seems unlikely to happen. Personally I don't see any kind of hardware limitation that pushed Korg to this decision.

There are a few workarounds for this problem. One is to buy the commercial RK-002 MIDI cable which has a programmable microcontroller inside. I don't like this mainly because this cable plus shipping is so expensive that it reaches almost half of the VolcaFM selling price. Another issue is that you have to pay attention to the direction in which you insert this cable.

I opted for a much less expensive mod which uses a little AVR processor. I've chosen an OpenLog board for its small size. You can purchase this board for 3-4$ delivered from various places like AliExpress and EBay.

The board is about 15×15mm in size and has all the necessary connections routed to .1" pins. The SPI on one side of the board needs to be used to program a special MIDI bootloader which after reset will listen for SysEx messages to load and program the main code running on this AVR chip. The microSD socket on the back of the PCB won't be used and it's better to mask it with tape to prevent any contacts with the components inside the Volca.

The board is small enough to fit near the MIDI In socket, where to optocoupler is located. Just four wires are needed to solder it inside: Vcc and Gnd to ground and 3.3V, Rx to the optocoupler output and Tx to the corresponding serial input of the ARM processor. The original trace between the optocoupler and the ARM processor needs to be cut.

The crystal on the OpenLog board is 16MHz which divides exactly to get the MIDI bitrate of 31250 bauds. The processor main code will intercept all the NoteOn messages "9n kk vv" and send before another Velocity message of "Bn 29 vv" followed by the unchanged NoteOn.

The insertion of this AVR processor will delay all the MIDI messages with about 1ms which is imperceptible. Also to avoid changing the global velocity before each played note first it should compare the new velocity to the previous one and ignore it if it doesn't differ more than +/-5 (velocity ranges from 0-127).

This mod will work for all of the Volca synthesizers series and also has the advantage of easy reprogram the code inside the AVR (bypassing it entirely if so needed) via SysEx messages using a free program like like MIDIOx on PC or SysEx Librarian on Mac OS.

Volca Firmware

Here are firmware dumps for some Korg Volca devices.

A much simpler way of tackling this problem would be to patch the ARM firmware directly if one can understand the wav update file format. A quick glance at the wav file reveals that it has a carrier at 5500Hz, left and right channels are different, there are 2 amplitudes and 4 phase shifts 90 degrees apart.

Since these wav files are computer generated, they have perfect periods. The Volca has to do a carrier recovery (probably based on a Costa's loop) before attempting to demodulate the signals but we can do this demodulation directly in software. Each of the L&R channels encodes two phase bits and one amplitude bit. So one symbol has a total of 6 bits.

I wrote a C program which multiples the wav files with a sine wave carrier and then extracts the amplitude and phase and maps them to 3bits per sample. Thanks to the Korg Syro Project I was able to understand the specific encoding and the volca_fw_decode now also parses the decoded firmware file and creates binary images.

Bellow is the extraction result for the first wav file included in the 1.09RC firmware upgrade:

File: volcafm_sys_1_0109RC.txt

The generated binary files are the part 1 - volcafm firmware v1.09RC and the part 2 - some routines and FL2H instrument data. The files have passed the CRC for each block. When joined together you get the full flash content of the Volva FM processor.

This allows one to patch the firmware and reflash it as a different version to the Volca. The above firmware is patched so it will allow any subsequent version and reverting later back to stock firmware if needed. The ARM code resides mostly in the first part of the firmware, with some routines (which are not involved in the firmware update process) in the second part.

When upgrading via WAV files both parts need to be sent to the Volca because the instruments data is overwritten while the first part of the firmware is programmed and the Volca will revert to the previous firmware if something goes wrong. Alternatively one can hook-up a J-Link programmer to the SwD connector on the main PCB and flash only the sectors with differences (for very fast programming during firmware development). If one programs a third party firmware with some bugs that brick the Volca, then SwD re-flashing is the only method to recover.

The SwD PCB footprint has a 2mm pin pitch and you can fit a PH 2.0 nylon connector. Since I wanted easy access while trying different firmware patches I've soldered PH 2.0 connectors in all my Volcas and I've also made some J-link adapters and various connection cables. Korg uses 2 variants of SwD signal order (depending of the processor type Toshiba or STM32/FM4). The PH 2.0 connector sometimes can only be soldered in reverse or on the other side of the board so this gives 4 cable combinations that cover all the Volca series. If you don't want to go to all this trouble then you can just solder 4 Dupont wires.

One can re-encode the firmware to WAV files using the volca_fw_encode program like this:

$ volca_fw_encode -n FM -b 0 -v 109 volcafm_sys_1_0109RC.bin volcafm_sys_2_0109RC.bin

This will create the following WAV files if you want to update your firmware over the audio cable: volca_sys_1_0109RC.wav and volca_sys_2_0109RC.wav
The volca_fw_encode [v1.2] and volca_fw_decode [v1.2] programs are perfectly reversible and they produce even the WAV file exactly as the Korg's originals.

To dump or program the Volca (or recover from a brick event) connect a J-Link interface to the SwD 6 pin connector and issue the following commands in the cmd line utility (usually JLinkExe):

si swd
speed auto
device MB9BF164L
connect
-- then --
savebin fw_name.bin,0x0,0x40000
--- or ---
loadfile fw_name_1.bin 0x0
loadfile fw_name_2.bin 0x20000