STLink v2 JTAG upload problem with Yarns

Hi,

I was able to compile the most current code on GitHub for Yarns and create the necessary files. However, now that I have gotten to the actual upload portion of the instructions I am having an issue.

I was wondering if anyone has had a similar error message and/or has recommendations on what I need to do to remedy this error so I can complete the upload?

Here’s the error:
vagrant@vagrant-ubuntu-trusty-64:/vagrant/eurorack-modules$ make -f yarns/makef
ile upload
openocd -s /opt/local/share/openocd/scripts/ -f interface/stlink-v2.cfg -f targe
t/stm32f1x.cfg -c “init” -c “halt” -c “sleep 200”
-f stmlib/programming/jtag/erase_f10x.cfg
-c “flash write_image erase build/yarns/yarns_bo
otloader_combo.bin 0x08000000”
-c “verify_image build/yarns/yarns_bootloader_co
mbo.bin 0x08000000”
-c “sleep 200” -c “reset run” -c “shutdown”
Open On-Chip Debugger 0.9.0 (2020-05-09-06:15)
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 u
se 'transport select '.
Info : The selected transport took over low-level target control. The results mi
ght differ compared to plain JTAG/SWD
adapter speed: 1000 kHz
adapter_nsrst_delay: 100
none separate
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 v29 API v2 SWIM v7 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 3.217824
Info : stm32f1x.cpu: hardware has 6 breakpoints, 4 watchpoints
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x81000000 pc: 0x0800080a msp: 0x200001dc
Info : device id = 0x20036410
Info : flash size = 128kbytes
stm32x mass erase complete
target state: halted
target halted due to debug-request, current mode: Handler HardFault
xPSR: 0x01000003 pc: 0xfffffffe msp: 0xffffffdc
auto erase enabled
wrote 65536 bytes from file build/yarns/yarns_bootloader_combo.bin in 9.140900s
(7.001 KiB/s)
target state: halted
target halted due to breakpoint, current mode: Handler HardFault
xPSR: 0x61000003 pc: 0x2000002e msp: 0xffffffdc
verified 64556 bytes in 1.209170s (52.137 KiB/s)
shutdown command invoked
vagrant@vagrant-ubuntu-trusty-64:/vagrant/eurorack-modules$

Thanks in advance for any insight.

I cant see any errors in the report. Openocd believes it has flashed and virified it ok. Also, as you’ve erased the chip you will have lost the factory calibration.

Erasing the factory settings and not being able to upload the code was my biggest worry. Something didn’t go quite right as it’s not turning on.

I was curious about this line in the message:

Info : auto-selecting first available session transport “hla_swd”. To override u
se 'transport select '.
Info : The selected transport took over low-level target control. The results mi
ght differ compared to plain JTAG/SWD

So it looks like I can change the transport to JTAG/SWD? Do you know what the command would be to access the ‘transport select’ option? Wondering if trying the JTAG/SWD transport might fix it. Any ideas are welcomed. Thanks

It looks like it has flashed fine - no idea why it’s not turning on! Look in the makefile and stmlib/makefile.inc for the environment variables but I strongly suspect you have flashed it correctly.
Is it DIY or factory?

Thanks for the reply. So I have both. I have a factory module and a second module that is DIY for traveling. I am trying to flash the chip on the DIY first before flashing the factory module. I need for them to be identical in their programming and now that the DIY is erased and not turning on I could be in trouble.

I’m not sure what I’m looking for when you say to “check the environment variables.” Could you elaborate?
Thanks for the assistance.

You probably have a soldering issue. Thiis forum doesnt allow diy build support - there’s a big thread on muffwiggler for that - definitely worth posting over there.

I think you did flash the module correctly. I think at least the boot loader is there. If you are having trouble you can try updating the firmware using the Sysex method that is described in the manual and the hacking resources section.

I will say this - Emilie has done an amazing job with the calibration of the Yarns module at the factory and you will have a very difficult time trying to get your module to match hers. No run-of-the-mill multimeter will work for calibration.

You should direct all future DIY questions to Muff Wiggler. DIY hardware builds are not supported on this forum.

Thank you all for the info. I appreciate it. I figured that since I do own an official factory purchased Yarns and was trying to also hack the firmware for that device that it would be okay to ask about it here. I was just doing the DIY version first for testing (and to have for my traveling device) so I didn’t screw up the flash of the factory module when the time comes for that. I definitely want to respect the wishes of the forum.

So, if I put my DIY aside for now and just go ahead and try flashing my factory module can I ask for help on this forum if I run into the same or similar issue that I did with my DIY module?

Thanks.

See my comment above. I had similar issues flashing via ST-link/jtag (that i would love to revisit eventually) but after flashing with sysex, everything worked fine.

There will be no problem talking about flashing a factory module here (with your diy module the reason it is not working may be due ti it being diy, given that I suspect it is flashed successfully). Whether you should flash a factory module is another question. You can flash it and not erase the calibration but you need to know what you are doing. You can also dump the contents of the flash area that contains the calibration… it’s much safer to use sysex though unless you know what you are doing (you can generate your own sysex from your repository)
Ps it’s not hard to recalibrate but you do need precise and accurate (ie expensive) test gear

2 Likes