DIY Mutable Unsuccessful Builds

[Rumble]

Sorry for the third post in a row but i might have found the problem.
I don`t have continuity from Pin 25 of the ST32 to Pin 5 of the DAC. Pins 26 and 28 have continuity to Pins 6 and 7. I will try to resolder it later and hope for just this and no pcb error.

Always reflow reflow reflow when there are issues. What sort of magnification are you rocking?

I find a 10x magnification with a nice white led light shows up any smd errors I've made. Pity it doesn't spot the placement errors...

[iLmuCo]

Yes, thats true! And it did the job. It was indeed just this one pin, that caused the issues. I have 3.5x magnification, but this is often not enough. Maybe i have to look for a better solution for the next builds. But hey, 3/3 smd builds are working. So lets get another one started ;-)

[Rumble]

I have just tried to flash my warps module (previously working with parasites) back to original firmware and after flashing I am getting the following error:

19:49:20 : Error: ST-LINK error (DEV_TARGET_CMD_ERR)

I am flashing using the stm32 cube programmer client via JTAG.

Have tried changing frequencies and setting mode to under reset. Same error.

SOLVED. I updated firmware on my STLINK and it started working.

[blankpanels]

Hey guys, I'm putting together a Jakplugg nRings - I've populated all the smd components with the exception of the MC and made sure all the power is going where its supposed to be before hand.

On powering up I'm getting 3.29V off the +3V3 lines, so that's fine BUT after the MB1S I'm getting +11.27 and -11.30V on the rails. On the pins I'm getting 11.99V and -11.99V. Is there something I'm missing? Should the drop after the rectifier really be so substantial??

I've not soldered any of the jacks, pots, LEDs etc yet either

[cnicht]

Each diode in the bridge rectifier will give a voltage drop of about 0.6V

[blankpanels]

Each diode in the bridge rectifier will give a voltage drop of about 0.6V

Ahh okay, that's reassuring, cheers

[byndcivilization]

Hi all, I'm trying to wrap up a bunch of old failed modules and i came across a jackplugg nano rings build. I thought i had firmware flashing correctly but I'm getting weird results when I power it on. No lights, button selection doesnt seem to do anything, nor do knobs. It does emit a weird noise. The only thing i can think of to describe it is pixelated bells or chimes. when i add a trigger in it doesnt seem to change the carachteristics of the noise but its pretty distorted so it might be subtle.

I'm going through and measuring voltages but i looked back at the mutable-dev-env flash message and now I'm wondering if the flash was actually successful. I grabbed the hex files and tried with the stm ide and it looks successful there so I'm thinking i did in fact flash it, but i wanted to make sure. Aslo does anyone know if jackplugg uses different firmware than standared rings?

Does this look right?

```
vagrant@vagrant-ubuntu-trusty-64:/vagrant/eurorack-modules$ make -f rings/makefile upload
make: Warning: File `build/rings/depends.mk' has modification time 8.1e+02 s in the future
cat build/rings/cv_scaler.d build/rings/resources.d build/rings/rings.d build/rings/settings.d build/rings/ui.d build/rings/adc.d build/rings/codec.d build/rings/debug_port.d build/rings/leds.d build/rings/switches.d build/rings/system.d build/rings/trigger_input.d build/rings/fm_voice.d build/rings/part.d build/rings/resonator.d build/rings/string.d build/rings/string_synth_part.d build/rings/atan.d build/rings/units.d build/rings/random.d build/rings/bootloader_utils.d build/rings/system_clock.d build/rings/system_stm32f4xx.d build/rings/misc.d build/rings/stm32f4xx_adc.d build/rings/stm32f4xx_can.d build/rings/stm32f4xx_cec.d build/rings/stm32f4xx_crc.d build/rings/stm32f4xx_cryp_aes.d build/rings/stm32f4xx_cryp.d build/rings/stm32f4xx_cryp_des.d build/rings/stm32f4xx_cryp_tdes.d build/rings/stm32f4xx_dac.d build/rings/stm32f4xx_dbgmcu.d build/rings/stm32f4xx_dcmi.d build/rings/stm32f4xx_dma2d.d build/rings/stm32f4xx_dma.d build/rings/stm32f4xx_dsi.d build/rings/stm32f4xx_exti.d build/rings/stm32f4xx_flash.d build/rings/stm32f4xx_flash_ramfunc.d build/rings/stm32f4xx_fmc.d build/rings/stm32f4xx_fmpi2c.d build/rings/stm32f4xx_fsmc.d build/rings/stm32f4xx_gpio.d build/rings/stm32f4xx_hash.d build/rings/stm32f4xx_hash_md5.d build/rings/stm32f4xx_hash_sha1.d build/rings/stm32f4xx_i2c.d build/rings/stm32f4xx_iwdg.d build/rings/stm32f4xx_lptim.d build/rings/stm32f4xx_ltdc.d build/rings/stm32f4xx_pwr.d build/rings/stm32f4xx_qspi.d build/rings/stm32f4xx_rcc.d build/rings/stm32f4xx_rng.d build/rings/stm32f4xx_rtc.d build/rings/stm32f4xx_sai.d build/rings/stm32f4xx_sdio.d build/rings/stm32f4xx_spdifrx.d build/rings/stm32f4xx_spi.d build/rings/stm32f4xx_syscfg.d build/rings/stm32f4xx_tim.d build/rings/stm32f4xx_usart.d build/rings/stm32f4xx_wwdg.d build/rings/startup_stm32f4xx.d > build/rings/depends.mk
make: Warning: File `build/rings/depends.mk' has modification time 8.3e+02 s in the future
cat build/rings/rings.hex build/rings_bootloader/rings_bootloader.hex | \
awk -f stmlib/programming/merge_hex.awk > build/rings/rings_bootloader_combo.hex
/usr/local/arm-4.8.3/bin/arm-none-eabi-objcopy -I ihex -O binary build/rings/rings_bootloader_combo.hex build/rings/rings_bootloader_combo.bin
openocd -s /opt/local/share/openocd/scripts/ -f interface/stlink-v2.cfg -f target/stm32f4x.cfg -c "init" -c "halt" -c "sleep 200" \
-c "flash erase_address 0x08000000 32768" \
-c "reset halt" \
-c "flash write_image erase build/rings/rings_bootloader_combo.bin 0x08000000" \
-c "verify_image build/rings/rings_bootloader_combo.bin 0x08000000" \
-c "sleep 200" -c "reset run" -c "shutdown"
Open On-Chip Debugger 0.11.0
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
WARNING: interface/stlink-v2.cfg is deprecated, please switch to interface/stlink.cfg
Info : auto-selecting first available session transport "hla_swd". To override use 'transport select <transport>'.
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
Info : clock speed 2000 kHz
Info : STLINK V2J40S7 (API v2) VID:PID 0483:3748
Info : Target voltage: 3.210471
Info : stm32f4x.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : starting gdb server for stm32f4x.cpu on 3333
Info : Listening on port 3333 for gdb connections
target halted due to debug-request, current mode: Handler External Interrupt(14)
xPSR: 0x2100001e pc: 0x0801128a msp: 0x2001fdf8
Info : device id = 0x100f6413
Info : flash size = 1024 kbytes
erased address 0x08000000 (length 32768) in 0.905658s (35.333 KiB/s)

Info : Unable to match requested speed 2000 kHz, using 1800 kHz
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0xfffffffe msp: 0xfffffffc
auto erase enabled
wrote 131072 bytes from file build/rings/rings_bootloader_combo.bin in 6.524875s (19.617 KiB/s)

verified 122432 bytes in 1.949407s (61.333 KiB/s)

Info : Unable to match requested speed 2000 kHz, using 1800 kHz
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
shutdown command invoked
make: warning: Clock skew detected. Your build may be incomplete.
```

Thanks yall,
C

[Altitude909]

that all looks right. you probably have some hardware problems

[byndcivilization]

Hi all, I'm trying to wrap up a bunch of old failed modules and i came across a jackplugg nano rings build. I thought i had firmware flashing correctly but I'm getting weird results when I power it on. No lights, button selection doesnt seem to do anything, nor do knobs. It does emit a weird noise. The only thing i can think of to describe it is pixelated bells or chimes. when i add a trigger in it doesnt seem to change the carachteristics of the noise but its pretty distorted so it might be subtle.

I'm going through and measuring voltages but i looked back at the mutable-dev-env flash message and now I'm wondering if the flash was actually successful. I grabbed the hex files and tried with the stm ide and it looks successful there so I'm thinking i did in fact flash it, but i wanted to make sure. Aslo does anyone know if jackplugg uses different firmware than standared rings?

Does this look right?

```
vagrant@vagrant-ubuntu-trusty-64:/vagrant/eurorack-modules$ make -f rings/makefile upload
make: Warning: File `build/rings/depends.mk' has modification time 8.1e+02 s in the future
cat build/rings/cv_scaler.d build/rings/resources.d build/rings/rings.d build/rings/settings.d build/rings/ui.d build/rings/adc.d build/rings/codec.d build/rings/debug_port.d build/rings/leds.d build/rings/switches.d build/rings/system.d build/rings/trigger_input.d build/rings/fm_voice.d build/rings/part.d build/rings/resonator.d build/rings/string.d build/rings/string_synth_part.d build/rings/atan.d build/rings/units.d build/rings/random.d build/rings/bootloader_utils.d build/rings/system_clock.d build/rings/system_stm32f4xx.d build/rings/misc.d build/rings/stm32f4xx_adc.d build/rings/stm32f4xx_can.d build/rings/stm32f4xx_cec.d build/rings/stm32f4xx_crc.d build/rings/stm32f4xx_cryp_aes.d build/rings/stm32f4xx_cryp.d build/rings/stm32f4xx_cryp_des.d build/rings/stm32f4xx_cryp_tdes.d build/rings/stm32f4xx_dac.d build/rings/stm32f4xx_dbgmcu.d build/rings/stm32f4xx_dcmi.d build/rings/stm32f4xx_dma2d.d build/rings/stm32f4xx_dma.d build/rings/stm32f4xx_dsi.d build/rings/stm32f4xx_exti.d build/rings/stm32f4xx_flash.d build/rings/stm32f4xx_flash_ramfunc.d build/rings/stm32f4xx_fmc.d build/rings/stm32f4xx_fmpi2c.d build/rings/stm32f4xx_fsmc.d build/rings/stm32f4xx_gpio.d build/rings/stm32f4xx_hash.d build/rings/stm32f4xx_hash_md5.d build/rings/stm32f4xx_hash_sha1.d build/rings/stm32f4xx_i2c.d build/rings/stm32f4xx_iwdg.d build/rings/stm32f4xx_lptim.d build/rings/stm32f4xx_ltdc.d build/rings/stm32f4xx_pwr.d build/rings/stm32f4xx_qspi.d build/rings/stm32f4xx_rcc.d build/rings/stm32f4xx_rng.d build/rings/stm32f4xx_rtc.d build/rings/stm32f4xx_sai.d build/rings/stm32f4xx_sdio.d build/rings/stm32f4xx_spdifrx.d build/rings/stm32f4xx_spi.d build/rings/stm32f4xx_syscfg.d build/rings/stm32f4xx_tim.d build/rings/stm32f4xx_usart.d build/rings/stm32f4xx_wwdg.d build/rings/startup_stm32f4xx.d > build/rings/depends.mk
make: Warning: File `build/rings/depends.mk' has modification time 8.3e+02 s in the future
cat build/rings/rings.hex build/rings_bootloader/rings_bootloader.hex | \
awk -f stmlib/programming/merge_hex.awk > build/rings/rings_bootloader_combo.hex
/usr/local/arm-4.8.3/bin/arm-none-eabi-objcopy -I ihex -O binary build/rings/rings_bootloader_combo.hex build/rings/rings_bootloader_combo.bin
openocd -s /opt/local/share/openocd/scripts/ -f interface/stlink-v2.cfg -f target/stm32f4x.cfg -c "init" -c "halt" -c "sleep 200" \
-c "flash erase_address 0x08000000 32768" \
-c "reset halt" \
-c "flash write_image erase build/rings/rings_bootloader_combo.bin 0x08000000" \
-c "verify_image build/rings/rings_bootloader_combo.bin 0x08000000" \
-c "sleep 200" -c "reset run" -c "shutdown"
Open On-Chip Debugger 0.11.0
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
WARNING: interface/stlink-v2.cfg is deprecated, please switch to interface/stlink.cfg
Info : auto-selecting first available session transport "hla_swd". To override use 'transport select <transport>'.
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
Info : clock speed 2000 kHz
Info : STLINK V2J40S7 (API v2) VID:PID 0483:3748
Info : Target voltage: 3.210471
Info : stm32f4x.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : starting gdb server for stm32f4x.cpu on 3333
Info : Listening on port 3333 for gdb connections
target halted due to debug-request, current mode: Handler External Interrupt(14)
xPSR: 0x2100001e pc: 0x0801128a msp: 0x2001fdf8
Info : device id = 0x100f6413
Info : flash size = 1024 kbytes
erased address 0x08000000 (length 32768) in 0.905658s (35.333 KiB/s)

Info : Unable to match requested speed 2000 kHz, using 1800 kHz
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0xfffffffe msp: 0xfffffffc
auto erase enabled
wrote 131072 bytes from file build/rings/rings_bootloader_combo.bin in 6.524875s (19.617 KiB/s)

verified 122432 bytes in 1.949407s (61.333 KiB/s)

Info : Unable to match requested speed 2000 kHz, using 1800 kHz
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
shutdown command invoked
make: warning: Clock skew detected. Your build may be incomplete.
```

Thanks yall,
C

Okay tried to lift the stm chip and pulled a pad so got a new board. spent a fair amount of time transfering all components from the old board to the new board. Reflashed everything. I now get faint green lights. when i press both buttons i never enter calibration mode. if i send anything to strum or v/oct or in i get really pixelated heavily distorted sound that seems like what rings should sound like but just torn to shreds. ive lifted and resoldered all the tssop components again and nothing has changed. Has anyone encountered this before?

[byndcivilization]

I just reflashed it. now the lights dont come on at all, the selector doesnt seem to do anthing...but...the sound coming out is getting closer to a rings sound. I dont seem to be able to enter any sort of calibration mode. Can anyone confirm that nano rings uses the same firmware as regular rings?

[byndcivilization]

One other thing, I've gone back and forth on the solder jumpuer on nano rings. does anyone know if this is supposed to be jumped or if its for troubleshooting.

[byndcivilization]

fwiw i just resoldered the jumper and theres no difference. no lights, no selection, distorted rings sound that does respond to knob turning.

[the_laconic]

To answer the question that I was about to post, as a general service announcement:

If everything seems OK on the outside but it's not working as expected, RTFM.

[blankpanels]

Back with another nRings issue - so I had no issues flashing the MC (apparently) - I compiled the hex files with vagrant all fine, and used a cheapo chinese st link v2 and the older ST link utility. Both the bootloader and firmware went on fine, so I added all the through-hole stuff.

On powering the module it seems like it went into the firmware updating mode with the two LEDs flashing amber, then it changed to just the mode LED being illuminated a mostly solid but kind of weak red. I've tried the classic off and on again a few times, sometimes when holding the poly button on startup I can get it to go into the firmware update mode for a few seconds but it always goes back to the single red LED and the module doesn't respond to any input.

Does anyone know what the single red LED would represent?

Flashing the MC was done with the 3.3V from the st link - during the process it said it was done in low power mode, but it connected fine and verified fine, so I assume I'm okay there. Plus the LED behavior for a few seconds was consistent with the rings firmware. Either way I'll try reflashing and take some more measurements and reflow some stuff tomorrow.

[Funktion]

Anyone have suggestion on how to diagnose a DIY Mutable Instruments Plaits that fully works except none of the LEDs light up after flashing the firmware? The voltages between the 3.3V anode and the Red / Green lines is low (around 0.8V). I have another working Plaits module that reads 2.3V - 2.5V when I take the same measurement. The LED driver (TLC59281) is getting power and is grounded properly and continuity is good across all of the lines. I've checked pretty much the entire board for correct polarity or any shorts and have not found anything suspect. Any tips are appreciated! Thanks.

[KvotheKingkiller]

Anyone have suggestion on how to diagnose a DIY Mutable Instruments Plaits that fully works except none of the LEDs light up after flashing the firmware?

Did the LED's ever light up? Or do you just mean after last step?

I've checked pretty much the entire board for correct polarity or any shorts and have not found anything suspect. Any tips are appreciated! Thanks.

Dumb question, but I'm assuming you are 100% you installed the LED's themselves in the right polarity? So many times I've built stuff, had problems with LED's only to realize they were not soldered in the right way, and i've built LOTS of stuff, lol.

[batchas]

I've checked pretty much the entire board for correct polarity or any shorts and have not found anything suspect.

I agree with KvotheKingkiller. I thin the LED are installed the wrong way, wrong polarity.
Either they are turned/positionned the wrong way (most likely), or you got like I did once a batch of (very bright!) LEDs that had a reverse polarity. Anode is supposed to be on the long pin, but on these the anode was on the short pin. I spent a lot of time troubleshooting because of that!

You could cut only one of the LEDs, invert it and see if it lights, to be sure.
It's btw easier to unmount a LED if you cut both legs, than if you unsolder while the LED is still in one piece. Once it is cut, you can unsolder each leg separately easely.

[armandhammer]

Has anyone installed the Mutable Dev Environment recently? I'm using it on Windows 11 (all recent OS updates) and it's giving me a weird error about openocd not being installed. I've flashed modules a bunch in the past and never had this issue. This is with a brand new install of mutable-dev-environment and VirtualBox 6.1.42. Why would the initial "vagrant up" process not install openocd? I try to do (for example):

Code: Select all

vagrant@vagrant-ubuntu-trusty-64:/vagrant/eurorack-modules$ make -f stages/makefile upload
cat build/stages/chain_state.d build/stages/cv_reader.d build/stages/factory_test.d build/stages/resources.d build/stages/segment_generator.d build/stages/settings.d build/stages/stages.d build/stages/ui.d build/stages/cv_adc.d build/stages/dac.d build/stages/firmware_update_adc.d build/stages/firmware_update_dac.d build/stages/gate_inputs.d build/stages/leds.d build/stages/pots_adc.d build/stages/serial_link.d build/stages/switches.d build/stages/system.d build/stages/ramp_extractor.d build/stages/atan.d build/stages/units.d build/stages/random.d build/stages/bootloader_utils.d build/stages/system_clock.d build/stages/system_stm32f37x.d build/stages/stm32f37x_adc.d build/stages/stm32f37x_can.d build/stages/stm32f37x_cec.d build/stages/stm32f37x_comp.d build/stages/stm32f37x_crc.d build/stages/stm32f37x_dac.d build/stages/stm32f37x_dbgmcu.d build/stages/stm32f37x_dma.d build/stages/stm32f37x_exti.d build/stages/stm32f37x_flash.d build/stages/stm32f37x_gpio.d build/stages/stm32f37x_i2c.d build/stages/stm32f37x_iwdg.d build/stages/stm32f37x_misc.d build/stages/stm32f37x_pwr.d build/stages/stm32f37x_rcc.d build/stages/stm32f37x_rtc.d build/stages/stm32f37x_sdadc.d build/stages/stm32f37x_spi.d build/stages/stm32f37x_syscfg.d build/stages/stm32f37x_tim.d build/stages/stm32f37x_usart.d build/stages/stm32f37x_wwdg.d build/stages/startup_stm32f37x.d > build/stages/depends.mk
make: Warning: File `build/stages/depends.mk' has modification time 1.2 s in the future
openocd -s /opt/local/share/openocd/scripts/ -f interface/stlink-v2.cfg -f target/stm32f3x.cfg -c "init" -c "halt" -c "sleep 200" \
                                -c "flash erase_address 0x08000000 32768" \
                                -c "reset halt" \
                                -c "flash write_image erase build/stages/stages_bootloader_combo.bin 0x08000000" \
                                -c "verify_image build/stages/stages_bootloader_combo.bin 0x08000000" \
                                -c "sleep 200" -c "reset run" -c "shutdown"
/bin/sh: 1: openocd: not found
make: *** [upload_combo_jtag_erase_first] Error 127

[BlackieDawless]

I've checked pretty much the entire board for correct polarity or any shorts and have not found anything suspect.

I agree with KvotheKingkiller. I thin the LED are installed the wrong way, wrong polarity.
Either they are turned/positionned the wrong way (most likely), or you got like I did once a batch of (very bright!) LEDs that had a reverse polarity. Anode is supposed to be on the long pin, but on these the anode was on the short pin. I spent a lot of time troubleshooting because of that!

You could cut only one of the LEDs, invert it and see if it lights, to be sure.
It's btw easier to unmount a LED if you cut both legs, than if you unsolder while the LED is still in one piece. Once it is cut, you can unsolder each leg separately easely.

Just to clarify this, bi-color LEDs with three legs come in two forms, a “regular” version that has a common cathode, and a “CA” version that has a common anode. Just dealt with this on a Knit Plaits build where the wrong LEDs were used - for this module, you want the CA type, with a common anode! Good Luck!

[BlackieDawless]

Just figured I would try here,

I am troubleshooting a KNIT (PLAITS clone) and can’t figure out if my firmware is compiled incorrect, or if there is a hardware issue. Does anyone have a compiled .hex file for PLAITS that they would be willing to share? I know there was a link to a hex that was posted in a different post, but that link is now broken and I am trying to be a good scientist and eliminate variables starting with the easiest first! Thanks everyone appreciate if anyone has any leads!

[eeling]

Attempting to salvage this Jakplugg Monsoon build.

Everything is tidy except for the lack of solder pads on the STM32. Do these pins actually connect to anything? I may have to follow the trace and connect with wires if possible.

It is not connecting to STM_Utility via ST-Link V2 (Windows11, using adafruit 2548).

I've looked at the schematic and there is no indication that they connect to anything. Any help appreciated!

[Altitude909]

that STM looks blacktopped (fake), codec is fake and blown. Dont buy semiconductors on Aliexpress

[eeling]

My photo does look that way! however, it appears to be a genuine ARM STM32. Was purchased from a supplier in the UK.

Any ideas on the pins?

Edit: I think I'm looking at pins 30 & 31. According to schematic:
30: I2C_SDA
31: VCAP_1 - connects to C24

I can wire pic 31. Not sure about 30? Either way, not sure these would effect connection to ST-Link. I'll reflow some solder...

[Altitude909]

Maybe. Was it purchased through and authorized source? I'd need to see a better picture. The bulge on the codec, the sharp edges and the shallow mold mark are a red flag, how much current is the device drawing? Fake part there will prevent it from doing anything

Those pads are not connected to anything, doesnt matter if the pads get lifted there

[eeling]

Thanks for your help Altitude. I can't say for sure of course... It's was an ebay vendor. That doesn't sound promising eh.

I guess I'll go back on the lookout for another source.