MUFF WIGGLER Forum Index
 FAQ & Terms of UseFAQ & Terms Of Use   Wiggler RadioMW Radio   Muff Wiggler TwitterTwitter   Support the site @ PatreonPatreon 
 SearchSearch   RegisterSign up   Log inLog in 
WIGGLING 'LITE' IN GUEST MODE

DIY Mutable Unsuccessful Builds
MUFF WIGGLER Forum Index -> Music Tech DIY  
Author DIY Mutable Unsuccessful Builds
dropmotif
I've built two streams from the group buy and both have serious problems with the audio from channel 1. At least one other person I've heard from is having the same issues with boards from another source, so I'm wondering if maybe there's an error in the eagle project files.

Has anyone had similar issues with streams?

Has anyone been able to build a working streams from the files?

Thanks
adam
i've contacted everyone who's bought streams from me, seems theres a problem with the linear/expo response on channel one - not sure if this is software or hardware, may be fixable

edit: it is software, and it's fixable, gbiz has found that changing one line of code sorts it out.
bennelong.bicyclist
Did you build them using the parts list (BOM) extracted directly from the Eagle files, or the pre-production BOM in the Google Doc spreadsheet that Olivier Gillet published? If the latter, check it against the canonical Eagle BOM. Olivier clearly stated that there were discrepancies between the pre-production BOMs and the final released version.

The audio pathway through Streams is all analogue, thus if you have distortion in one channel, it seems more likely to be a hardware issue. The fact that you get a signal at all in channel 1 suggests wrong component values rather than a PCB problem, but a missing trace could be the problem.

Of course, the usual practice for people selling PCBs for DIY is to successfully build at least one instance themselves first, as a basic quality assurance step, before selling them to others.
dropmotif
I built straight from the Eagle BOM, so I don't think there's a problem with the component selection. While troubleshooting the first one a multimeter probe slipped and sent 12v to the mcu so I built up a second only to have the same symptom. It could've been a coincidence but after hearing that someone else is having a similar problem I suspect it's with the boards or software.

I've checked the gerbers used to make them against Olivier's eagle layout and can't find any differences in the traces.

Adam says the drill holes are a bit larger but I don't think that's the problem.

In some modes my second build does produce audio in ch1 but in the compressor mode it doesn't pass anything.
bennelong.bicyclist
A manual continuity test using a multimeter on a bare PCB from the same batch might be worth doing. Rather tedious to do, but at least the audio pathway for channel 1 could be checked.

Also check that all the traces that run along the long edges of the actual boards are as they should be. I had one set of boards come back from PCB fab in which they had shifted the entire layout about 2mm to the right, which meant that traces running along the edge of the board were actually in thin air. I didn't discover that until after I built up the board. Fixed with several jumper wires to substitute for the missing traces.
makers
One DOA Grits for me here Dead Banana

I've successfully built many of the ARM based mutables so I was surprised I couldn't get this one going.

My AVRISP can not see the MPU.

I was able to reprogram a production Grids with the same set-up so it's not my programmer.

I have a new MPU on order- we'll see what happens.
Sandrine
This is a depressing thread, but could it be static electricity related?
BTW: I've heard of Arduino's getting fried by someone taking a picture or their new creation. Seems pride can come at a cost. EM pulses can fool even the best designers (welder cables, large current to an inverter, lightning, nuclear airbursts)
bennelong.bicyclist
makers wrote:
One DOA Grits for me here Dead Banana

I've successfully built many of the ARM based mutables so I was surprised I couldn't get this one going.

My AVRISP can not see the MPU.

I was able to reprogram a production Grids with the same set-up so it's not my programmer.

I have a new MPU on order- we'll see what happens.


I recently repaired a factory-built Grids which probably had its MPU fried by a spike on the 5V power line in the rack it was in. After replacing the MPU (and the op-amps and the 74HC595), I had the same problem - my AVRISP mkII wouldn't recognise the MPU. I had previously successfully flashed two DIY Grids using the same programmer. Changing -B 1 to -B 4 in the makefile solved the problem.
makers
bennelong.bicyclist wrote:
Changing -B 1 to -B 4 in the makefile solved the problem.


That worked! Thanks so much. Now... Strangely everything seems to work correctly but running very slowly. For example- it takes about 10 seconds of holding the switch down before it will enter the config mode.

I'll look into the fuse settings tomorrow.

Anyway, thanks again Tim.
bennelong.bicyclist
makers wrote:
bennelong.bicyclist wrote:
Changing -B 1 to -B 4 in the makefile solved the problem.


That worked! Thanks so much. Now... Strangely everything's seems to work correctly but running very slowly. For example- it takes about 10 seconds of holding the switch down before it will enter the config mode.

I'll look into the fuse settings tomorrow.

Anyway, thanks again Tim.


Now that you've flashed the code once at the slower speed, you need to set the fuses. Just run "make -f grids/makefile bake" - the bake target in the makefile (or in makefile.inc) will set all the fuses correctly, including the clock speed fuse. I (re-)discovered these tricks recently - see http://mutable-instruments.net/forum/discussion/7258/repairing-a-grids
adam
dropmotif wrote:

Adam says the drill holes are a bit larger but I don't think that's the problem.

the holes are the same size - oshpark bumped up the size of a bit to ensure plated slots worked correctly
koerby
Back to MI Stream:

i've also problem with channel one.
I built two units and both shows exactly the same behaviour.
In the compressor mode channel on is much more quieter than channel two.
I triple checked all connections and the eagle schematics. Also the calibration is fine.
I cannot imagine that Oliver published wrong files or a wron code. so I have no Idea waht can be the reason. On the other hand it is strange that several persons running into the same problem.

Maybe the v2164 is wrong, i've got mine from small bear.

Boards are from OSH Park.
adam
it's more than several people - it's everyone that's built one so far

i don't think it's due to osh park bumping up the size of the bit to their 40 mil minimum - i've checked the files they made me and they seem identical to the ones from github, i haven't been able to check the drillfile they made that exhaustively, but i can paste it in here if anyone wants to look

they said that if a bit to mill a slot is less than 40 mills the fab might bump it up or might not - they changed it on mine and sent me the files to order with, i don't think they do this unless they're asked about slots etc

the other possibility i thought of is that some of the holes that should be plated are not, but once again strange that this has happened in every case over about 5 board orders from them

github file


oshpark edit


and the backs





when i flipped between the images the only change i can see is the size of the hole on the jacks - thats to denote a larger drill bit

one channel being ok suggests that it's not a batch of dodgy 2164's
setsun8
Same exact issue here with boards from Oshpark. I've been probing around and haven't found any bad traces yet. I'm still getting audio in the other modes on channel one, the responses just aren't as predicted. Compressor mode isn't working on channel one at all though.

I noticed the Voltages output on test point 1 do not match up with test point 2, so I've been searching around the circuit to find the issue with no luck yet.
adam
i wonder if it isn't working because it only works in exponential mode and it's too linear or something?

did you say you'd looked at all the component values on both channels and found they were the same?

Quote:
Compressor: works only properly in exponential VCA mode and when level-mod is in it's minimum position. The excite input works as a sidechain for the Input signal and the excite level determines gain reduction. If only IN is used, the module works as a normal compressor. Attack time is fixed to 0.2ms and decay to 150ms. MOD: in 12h-position no compression happens; counterclockwise signals are tamed and clockwise low signals are boosted.


the linear vca looks like that classic design - http://www.sdiy.org/philgallo/mgbvca.html

i remember someone saying there were issues when you use 2 2164s in a circuit - but i can't remember what those were

you'll have to excuse me pasting random bits from datasheets - this is building a mixer from multiple ic's so may not be relevant
Quote:
If additional SSM2164s are added, the 100 pF capacitor may
need to be increased to ensure stability of the output amplifier.
Most op amps are sensitive to capacitance on their inverting
inputs. The capacitance forms a pole with the feedback resistor,
which reduces the high frequency phase margin. As more
SSM2164’s are added to the mixer circuit, their output capaci-
tance and the parasitic trace capacitance add, increasing the
overall input capacitance. Increasing the feedback capacitor will
maintain the stability of the output amplifier
bennelong.bicyclist
Before speculating about Olivier's hardware design being flawed, which seems very unlikely since he tests his designs very thoroughly, and the module is in successful production, the obvious thing to do is to sit down with a bare OSH Park PCB, a multimeter and the schematic and do a complete manual continuity test on every trace that is relevant to or associated with channel 1, in order to eliminate a systematic fabrication problem, possibly with the way the OSH Park fab plant is interpreting the Eagle files. I would have thought, in these circumstances, it is the responsibility of the person selling these PCBs to undertake such tests. As I mentioned earlier, usual practice for anyone selling DIY PCBs is to build up at least one example themselves to make sure the PCB is sound and that everything works as expected, before selling them to others on a commercial basis.
jdkee
I built an Anushri which slowly died over time. I checked the solder joints, all components and even asked Olivier to send me a replacement MCU (which he did free of charge) to no avail. After spending about 16 hours or so troubleshooting and re-soldering I gave up on that build. I built 20 odd Euro and other kits before, so it may just be bad luck with a particular component. That said I have another Anushri kit with Mouser components on my docket to build this fall. Given that I had built an Ambika 6-voice and several Shruthi, I know it's not the design but the builder in my case.

I will really take my time with the next Anushri build and check everything step-by-step, no assembly when I am tired at night. After that I will do the Klee euro sequencer and heaven forbid I screw that one up.
forbin
Was actually looking at Streams as another through hole 5U giant so was interested to read these comments...

I can't really see why there should be any difference between the channels though as they are identical -- certainly shouldn't have anything to do with the liner Vs log response of the VCA. I assume that channel 2 works fine? Can you check the DAC outputs if you have the same settings?
adam
forbin wrote:
Was actually looking at Streams as another through hole 5U giant so was interested to read these comments...

I can't really see why there should be any difference between the channels though as they are identical -- certainly shouldn't have anything to do with the liner Vs log response of the VCA. I assume that channel 2 works fine? Can you check the DAC outputs if you have the same settings?


it seems that compressor mode needs exponential whatsit to work at all - other modes seem to work on that side, and setsun8 has mentioned to me that there's something up with the exp/linear response on his unit

and different voltages on test points one and two - by the looks these points sit after vca control section on each channel - which from a quick uneducated glance looks like a mix of the vca that makes the cv linear, the output of a dac, a -10 voltage and a cv input or +10v depending on if anythings plugged into that socket
pld
It looks like there are signal traces under a lot of the pots, and the oshpark solder mask is probably less robust than what Olivier specs. I'd start checking with R14 where there's a via for the MOD setting from that pot to the mcu, and R36 where the via carries the lin/exp setting for channel 1 from R27.

Given the symmetrical nature of the channels, using an identical source signal and settings should make localizing the difference fairly simple? But admitedly still not easy wink
bennelong.bicyclist
pld wrote:
It looks like there are signal traces under a lot of the pots, and the oshpark solder mask is probably less robust than what Olivier specs. I'd start checking with R14 where there's a via for the MOD setting from that pot to the mcu, and R36 where the via carries the lin/exp setting for channel 1 from R27.


Yes, absolutely - the OSH Park solder mask is quite thin and can easily be scraped off by even slight mechanical friction. For my MI module builds on OSH Park PCBs, I fold up the little tabs under the pots so they don't sit on the PCB over any traces. You do need to marry all your pots and jacks up to the panel before soldering them if you do this, otherwise they are unlikely to be exactly perpendicular to the PCB (which is what the little tabs that sit against the PCB are for - to keep them nice and square to the PCB). The same issue applies to the jack sockets. The Ripples I built had the traces re-routed so they didn't lie under the jack socket skirts, but now I just apply two layers of Kapton polyimide tape (which is highly heat-resistant as well as being an insulator) to the PCB under the jacks, and poke holes in it for the jack socket legs and connection lugs to poke through. That ensures that mechanical friction won't wear through the solder mask to cause shorts. Of course, if the sockets and pots are rigidly mounted to a stiff front panel, then there shouldn't be much ongoing friction, but it pays to be careful, I feel, if you want the module to have a long life.
adam
i don't know - oshpark is really high spec generally, even solder mask in the vias i think.
gbiz
But the tabs bennelong.bicyclist mentions have a sharp edge, & could very possibly wear through solder mask over time. His advice to bend these back is good.

But if this were the cause of this issue, i could understand one or maybe two modules being affected by it, it can't see all of them suffering it.
adam
yes, that seems like good advice
gbiz
Another thought on this, relevent to Streams here. With PJ301B's, the jacks are taller than the Alpha pot body. Some people trim the tabs off on these jacks so the pots sit flush on the PCB and mount flush to the panel. If you leave the tabs on the jacks & mount the pots flush to the panel, these tabs on the pots won't be in contact with the PCB, so this is a non-issue for the pots. It'll still apply to the jacks though.
bennelong.bicyclist
adam wrote:
i don't know - oshpark is really high spec generally, even solder mask in the vias i think.


There is a trade-off between thickness of the solder mask and the narrowness of the gaps which the mask can successfully be applied to, and the OSH Park boards have solder mask perfectly applied between the 0.5mm pitch pads of the MPU etc - which is extremely helpful when trying to solder the damn things. But the downside is that the solder mask is quite thin where it overlies traces - just try scraping it lightly with a knife, or rubbing your soldering iron against it repeatedly.

I'm not suggesting that shorts through the solder mask is the cause of your problem with your Streams PCBs, just that anyone building on OSH Park boards should think about what happens if the pot or jack socket skirts short out the traces running underneath them, and whether a bit of prevention along the lines I described above is a good idea given the overall effort that goes into a DIY build of these modules.
adam
yes, seems like a good idea
Conjure
...
gbiz
So here's how i got on with my Streams build ...

After reading all the reports here of suspected problem with the PCB from OSHPark/Adam, i expected mine would be the same. Having never used a factory Streams, I presumed both channels were identical. I was expecting identical behaviour when provided with the same signal inputs. That wasn't the case with mine. The action of chan 2 mod pot was inverted from that on chan 1 - ie to get no modulation on chan 1 the pot needed to be fully CCW, but on chan 2 it needed to be fully CW. Both modulation waveforms looked exactly like those in the User Guide, just chan 2 was inverted compared to chan 1. I couldn't find anywhere that documented this behaviour so i assumed it was part of the "chan 1 sounds different to chan 2" that others were reporting. I spent hours debugging this as an assumed h/w problem, before realising that it's how the PWM output on channel 2 is configured to work in the code. So, with a single line change in streams/drivers/pwm.cc so both PWM outputs are configured the same, both channels on mine now work exactly the same. Change line 62 to match line 55 so both lines now read
output_compare_init.TIM_OutputNState = TIM_OutputState_Enable;

Once i got that out of the way, everything else appears to be working as i'd expect, though as i say, i don't have a factory module to compare against.

As this one is now working, I doubt there's an issue with the PCBs from Adam. Or at least certyainly not with the one i have here.

For any of you chasing differences between the two channels & who are seeing the same behaviour between the two mod pots in VCA mode, i'd suggest you give that code change a try. Assuming you have the build environment setup, it's trivial to implement & test.


I'm kicking myself for only buying one panel from Greyscale now. This is really great sounding module. I'd happily build a couple more. The one addition i'd really like is CV control for shape & mod. Maybe something to hack up on another one hihi
adam
another mystery solved smile
gbiz
Well, it's one down anyway hihi
mckenic
applause
Thank you!
pld
Are you sure that's right? It should probably be either:
output_compare_init.TIM_OutputState = TIM_OutputState_Enable;
or
output_compare_init.TIM_OutputNState = TIM_OutputNState_Enable;
which are subtly different bits in the registers.
gbiz
Very possibly. I've done no Arm programming, i was assuming that the existing code was correct. If you look at the existing code on github, line 55 has the same initialisation that i just copied
https://github.com/pichenettes/eurorack/blob/master/streams/drivers/pw m.cc

As i said, it does achieve what i was looking for, the same PWM behaviour on channel 2 as channel 1.

From what you've said it sounds like i need to look at this a bit more.
sixty_n
If you make a DIY braids the encoder works backwards, maybe it's a similar thing to that but it's weird it's just one not both. The code in pwm.cc explicitly sets up one channel as different to the other. This must have been done for a reason but I can't think what it would be. I thought the pwm.h file might shed some light on this but it doesn't
Altitude909
sixty_n wrote:
If you make a DIY braids the encoder works backwards, maybe it's a similar thing to that but it's weird it's just one not both. The code in pwm.cc explicitly sets up one channel as different to the other. This must have been done for a reason but I can't think what it would be. I thought the pwm.h file might shed some light on this but it doesn't


Simple. The production encoders have a different pinout
sixty_n
yes but this is suggesting that on the production versions the channel 1 pot has a different pinout to the channel 2 one
Altitude909
Well, I dont know what the issue with streams is, I'm only referring to the Braids encoder.

Has anyone successfully built one? If they are all bad then there might be a fab problem where the boards on the git are spec'd higher than the fab can make
gbiz
Altitude909 wrote:
Well, I dont know what the issue with streams is, I'm only referring to the Braids encoder.

Has anyone successfully built one? If they are all bad then there might be a fab problem where the boards on the git are spec'd higher than the fab can make


See Adams post on page 1. Nobody had built a successful build. Everyone was reporting differences in behaviour between the two channels. As everyone had experienced it, the finger of blame was being pointed at the boards, especially as OSHPark had had to increase the drill size. I went into debugging my build assuming it had the same issue with the board.

We're talking about a 10K pot here, one side at 0V, the other 3.3V, & the wiper going straight into the MCU. Simple as it can get. I can't see the two outer pins being swapped.

There are some vias that i have to say do look dodgy, but they all buzz out fine. The only issue on my build is the inverted behaviour of one PWM output. Now thats resolved (correctly or not), my board appears to be functioning 100%. Putting identical signals into both channels, monitoring the output with headphones, there no discernable difference between them.
pichenettes
The factory made modules work as expected (no channel swap) and do not require fancy pots.

I'm surprised that you found it necessary to fix PWM channel 4 (second channel of Streams), while the problem is obviously with channel 3 (first channel of the module). With the module in envelope mode, shape set to linear, LEVEL set to maximum, and a sawtooth wave in the input, the MOD knob should do a filter sweep from 12 o'clock to 5 o'clock.

The code for initializing OC3 in pwm.cc is indeed fishy BUT if you look at the actual implementation of TIM_OC3Init from ST, both TIM_OutputNState and TIM_OutputState are both shifted left by 8 and OR'ed to CCER, so my incorrect code still puts the right value in the right register, and worked well so far on hundreds of modules. Weird!

It could be that different compiler versions lay out the code differently in memory and output_compare_init isn't filled with the same garbage on the version you are using? Or that the parameter checking assert is enabled and that the function fails to initialize the channel because of the wrong bitmask being used.

Anyway I've pushed a fix in which all the necessary fields of the struct are initialized with sane values.
adam
thats very kind of you olivier, thanks smile
gbiz
Oh cool. Thanks pichenettes. I'll give it a try.

I picked Streams channel 2 as to me the behaviour of the Streams channel 1 modulation pot was "right" - move the pot clockwise & the filter opens up. (I did all my testing in green LED #1 VCA mode).

I did wonder if it was something odd with the compiler. I used the same toolchain as i've used for a number of modules - gcc-arm-none-eabi-4_8-2013q4. I then tried arm-none-eabi-gcc-cs-4.9.2-3 which is the latest available for the Fedora 20 system i'm running this on. Both exhibited the same.

I still have the older 4.8.3 toolchain tree here, maybe i should have tried that ?.
gbiz
New code built & installed & both mod pots are working as expected.

Again, many many thanks for your help pichenettes.
pichenettes
The firmware for the STM32F1 modules are built with 4.5.2. It's what was "current" at the time I developed Braids, and Braids' code has become so touchy regarding flash size that I never moved to a newer version. The F4 projects are built with 4.8.3
gbiz
I was aware of that issue for Braids & i've done that for Braids. I didn't realise it applied to all your F1 modules. Noted for future builds.

"make size" with both compilers suggested there was plenty of room free, so i assumed it'd be OK using the later compiler.
pichenettes
There shouldn't be any problem using a more recent toolchain for the other projects... except when there's a strange corner case like that!
koerby
Thanks pichenettes, now it works in a perfect way
pichenettes
Once I'm back from vacations I'll make a vagrant environment with all the right tools to make it easier to build the code.
adam
thanks, i think that'd really help people, seems like setting up the toolchain in the first place can be a huge barrier, especially if people are new to the command line
dropmotif
Thanks pichenettes and thanks gbiz for your help!
It's working fine now.
setsun8
Yep working fine for me as well now. One of my favorite modules, it is so incredibly useful and the vactrol mode sounds fantastic.
zarro
modules go out, I unplugged my braids to see if it came from the consumption although I'm surprised
https://www.modulargrid.net/e/racks/view/105824
I tried two buses and several power port but nothing
I must have short circuit
if someone could help me
thank
zarro
problem solved I reversed the direction ic 9 and 10 applause
the LED lights
more than to wait for my friends ftdi
to flash my STM32
zarro
Hi everybody
I finished my clouds and install the bootloader
but I have concerns about the dry / wet
there not seem to be 100% on my own
knowing that this is the DIY there may be a concern somewhere, as happened to 85% of the race he seems to be the most of the wet and 15% following redecend it to dry
I am surprised because I do not like to hear the sound without necessarily entering froze its
or if someone would come to this failure
crc
just finished building a Tides, but as i'm trying to flash the module with ST-Link, it can't connect to the module. i actually tried to connect to my braids and clouuds that i succesfully built but i can't connect to those either.

thin is that i have upgraded from windows vista to windows 7 after i have build braids and clouds. i have tried to install the latest drivers for st-link ect, but no bonus confused

help
zarro
@crc

I can not help you because I used a ftdi
try this software
http://www.st.com/web/en/catalog/tools/PF257525
but otherwise you can turn the knob "blend" to the max on the "dry / wet" so that we hear not the original sound
crc
oh, and one more thing.. when i power up Tides (non-flashed), the first led is lit red (dim). normal?
zarro
sorry i don't build tides

my problem is hardware
because when I use my shades in off-set in "cv blend in" to the maximum
   I can not hear the original sound
someone would have an idea of where come from the breakdown
limpmeat
crc wrote:
oh, and one more thing.. when i power up Tides (non-flashed), the first led is lit red (dim). normal?


Not sure, but I can say that on the second clouds I built the LEDS lit up before flashing where the first one didn't. Both work fine.
BARE BONES
so....
I decided to calibrate my Braids, followed the instructions in the manual, at first the pitch was just way too high and now after a few attempts im getting just random noises.
I'm going to reinstall the firmware, but does anyone have any idea what might be amiss to cause an issue like this?
It must be related to the inability to update via audio file but the inputs all worked fine for actually playing the module so it's very confusing.
BARE BONES
crc wrote:
just finished building a Tides, but as i'm trying to flash the module with ST-Link, it can't connect to the module. i actually tried to connect to my braids and clouuds that i succesfully built but i can't connect to those either.

thin is that i have upgraded from windows vista to windows 7 after i have build braids and clouds. i have tried to install the latest drivers for st-link ect, but no bonus confused

help


can you update the firmware on the st-link?
crc
BARE BONES wrote:
crc wrote:
just finished building a Tides, but as i'm trying to flash the module with ST-Link, it can't connect to the module. i actually tried to connect to my braids and clouuds that i succesfully built but i can't connect to those either.

thin is that i have upgraded from windows vista to windows 7 after i have build braids and clouds. i have tried to install the latest drivers for st-link ect, but no bonus confused

help


can you update the firmware on the st-link?


yes. i have to plug out the usb cable once to get the update procedure to work.
crc
Ok, build another Braids, and can't connect with that one either. Clearly a problem with my computer, as I have tried it now with two sets of programmers, and four MI modules (two programmed, two blank). Running out of ideas :(
BARE BONES
how did you program the first two modules?

Maybe there's an issue with your jtag cable
BARE BONES
I've got one totally non working Elements and one that has taken the firmware and seems operational but outputs no sound.
If anyone has any advice it'd be appreciated, i've had a look at the schematics and it seems like it's probably an issue with IC14 or the surroundings but i'm not sure what to test to verify that.
I've tried updating the firmware via the external input and got no response so i'm guessing that's not functioning either.

The first time I powered it up I had IC11 upside down so maybe that's caused some problem, I don't really understand how the different parts of the schematic fit together
Puzzler
pictures?
BARE BONES
-deleted
Puzzler
Did you replace IC11 with a whole new 4051PW after you corrected the "upside"?

And pictures taken directly from top would be most helpful to correctly see the dimensions.
BARE BONES
yes a brand new chip, it's supposed to be exactly the same part as the other 3 but has a different code marking.
I was taking the pics through my magnifier so it was a bit difficult to do them directly above. I'll try again, thanks.
bennelong.bicyclist
Not directly relevant to your issue, but it is worthwhile cleaning all the flux off the PCB thoroughly, even if you use no-clean flux, with isopropanol or similar, although best done before you mount the pots and switches etc. A clean PCB is much easier to inspect. Especially important when looking for tiny solder bridges between the MPU pins and other fine-pitch chips.
BARE BONES
will do, I normally clean my boards but was a bit too keen to get this one into action.
I've been probing around with an oscilloscope looking at the ICs, from what I can see on the schematic I should be able to see the audio coming out of IC14 on pins 1 & 7
BARE BONES
I got a new magnifier today and was able to see a couple of tiny solder bridges on IC12, reflowed the solder and we're good to go!
cool

Now it's just the totally non working one to solve very frustrating
jackmattson
I've built 2 ripples (at the same time)... one the cutoff doesn't work and the other no sound. Totally my fault I 100% sure. First SMT job.

I fried my module tester a few times, the last probing the power in and making a heavy short (oops). It sits in my pile of todo's but I've lost interest a bit.

Building two tides and soldering on the very first STM32 I bent 2 legs meh ... but I'm learning.

0 for 3.5 record. But a pile of more boards to learn from. Still having fun (mostly).

Balancing these projects with a few easy through holes keeps my esteem at a normal level.

Edit: actually I'm happy to have some issues to learn from. Just don't know where to start learning about debugging these suckers (Ripples)
dadacore
bennelong.bicyclist wrote:
makers wrote:
bennelong.bicyclist wrote:
Changing -B 1 to -B 4 in the makefile solved the problem.


That worked! Thanks so much. Now... Strangely everything's seems to work correctly but running very slowly. For example- it takes about 10 seconds of holding the switch down before it will enter the config mode.

I'll look into the fuse settings tomorrow.

Anyway, thanks again Tim.


Now that you've flashed the code once at the slower speed, you need to set the fuses. Just run "make -f grids/makefile bake" - the bake target in the makefile (or in makefile.inc) will set all the fuses correctly, including the clock speed fuse. I (re-)discovered these tricks recently - see http://mutable-instruments.net/forum/discussion/7258/repairing-a-grids



Already tried one pass with make and one with bake, but still the clock speed fuse it isn't working properly.
Got this report while flashing it:
avrdude: set SCK frequency to 93750 Hz
avrdude: warning: cannot set sck period. please check for usbasp firmware update.

could this be the issue?
bennelong.bicyclist
dadacore wrote:
bennelong.bicyclist wrote:
makers wrote:
bennelong.bicyclist wrote:
Changing -B 1 to -B 4 in the makefile solved the problem.


That worked! Thanks so much. Now... Strangely everything's seems to work correctly but running very slowly. For example- it takes about 10 seconds of holding the switch down before it will enter the config mode.

I'll look into the fuse settings tomorrow.

Anyway, thanks again Tim.


Now that you've flashed the code once at the slower speed, you need to set the fuses. Just run "make -f grids/makefile bake" - the bake target in the makefile (or in makefile.inc) will set all the fuses correctly, including the clock speed fuse. I (re-)discovered these tricks recently - see http://mutable-instruments.net/forum/discussion/7258/repairing-a-grids



Already tried one pass with make and one with bake, but still the clock speed fuse it isn't working properly.
Got this report while flashing it:
avrdude: set SCK frequency to 93750 Hz
avrdude: warning: cannot set sck period. please check for usbasp firmware update.

could this be the issue?


Sorry, I don't know. Are you using the official Atmel AVR ISP mk2 programmer? I tried three different third party Atmel programmers to program my Shruthi synths, without success, before buying the official Atmel product. But there are some third party programmers that are good, but also a lot that are complete garbage, I understand. For $30-odd bucks, I though it best to just get the official programmer.
makers
USBTinyISP worked fine for me:

http://www.adafruit.com/products/46
dadacore
bennelong.bicyclist wrote:
dadacore wrote:
bennelong.bicyclist wrote:
makers wrote:
bennelong.bicyclist wrote:
Changing -B 1 to -B 4 in the makefile solved the problem.


That worked! Thanks so much. Now... Strangely everything's seems to work correctly but running very slowly. For example- it takes about 10 seconds of holding the switch down before it will enter the config mode.

I'll look into the fuse settings tomorrow.

Anyway, thanks again Tim.


Now that you've flashed the code once at the slower speed, you need to set the fuses. Just run "make -f grids/makefile bake" - the bake target in the makefile (or in makefile.inc) will set all the fuses correctly, including the clock speed fuse. I (re-)discovered these tricks recently - see http://mutable-instruments.net/forum/discussion/7258/repairing-a-grids



Already tried one pass with make and one with bake, but still the clock speed fuse it isn't working properly.
Got this report while flashing it:
avrdude: set SCK frequency to 93750 Hz
avrdude: warning: cannot set sck period. please check for usbasp firmware update.

could this be the issue?


Sorry, I don't know. Are you using the official Atmel AVR ISP mk2 programmer? I tried three different third party Atmel programmers to program my Shruthi synths, without success, before buying the official Atmel product. But there are some third party programmers that are good, but also a lot that are complete garbage, I understand. For $30-odd bucks, I though it best to just get the official programmer.


yep, it's a cheap Usb-ASP avr programmer indeed, it's on avrdude supported devices list but I think i'll go for the easy route and buy an usb tiny too before giving up
Altitude909
Just because the programmer is supported on avrdude doesnt mean that it supports that chip in particular. I ditched my old usbtiny since it wouldnt work with newer and bigger chips
markfrancombe
Hi
Still cant get STM32-ST-LINK Utility to work (this for either Braids OR Clouds)
I have tried to udate the STLINK firmware, that seemed to happen ok.

Somewhere else on this list an alternative software was suggested
http://www.st.com/web/en/catalog/tools/PF257525#
I tried this, but it crashes the second I launch it.

It may be build issues of course. So to that end, even though my crappy iPhone photos probably don´t help AT ALL, certainly not in regard in spotting solder bridges or whatever... but maybe some super clever person can see that Ibe put a resister on a caps place, or mounted an IC the wrong way round...

Heres Clouds in 2 halves, to try to eek out a tiny bit of extra resolution...




As said before, any hints leading to success will result in a free CD!!

Regards

MArk
Altitude909
check the uC soldering around C24, looks suspect
Puzzler
C19 is tricky, there might be a bridge to the stm32.

And what happended to C23? lol
markfrancombe
While continuing to search via magnifier for errors, I thought Id get a FTDI Friend and see if using that method works. One is now on the way.

Researching it now, I see drivers to be installed, but what actual "program" do I need to run on the computer to upload bootloader and code etc?
BARE BONES
bottom left of the arm chip looks like a solder bridge
markfrancombe
BARE BONES wrote:
bottom left of the arm chip looks like a solder bridge


I had a bash at that spot earlier actually, went in close with magnifier, and I think the arm chip as all ok... checked orientaion of diodes and chips and heated up with flux a few of the more "wonky" caps and res...

Im convinced its my St Link stuff... just not working withe StLink Utility on my Window XP SP3 PC at the studio...

So... SEE NEXT POST:::
bennelong.bicyclist
Why don't you use the correct build environment as provided by Olivier in a VM, instead of mucking around in ancient versions of Windows? https://github.com/pichenettes/mutable-dev-environment
markfrancombe
OK so, I thought .. whats this VM with vagrant crap all about... I had already down-zoned the MI repository in its entirety, so (after a little command line recap courtesy of CodeAcademy) I follow THIS:
https://github.com/pichenettes/mutable-dev-environment

All goes well, and I actually manage to get a Oracle VM running with the mutable-dev-environment loaded... (Whatever THAT means..)

So step 2... half way down the page he writes:
Quote:
To write the firmware to the module with an Olimex ARM-USB-OCD-H JTAG adapter, use:

make -f clouds/makefile upload


Now that sounds like just the ticket, but before that step I must:

Quote:
Then, you can log onto the virtual machine by running:

vagrant ssh


And heres my current problem... After doing that, The VM window displays
PASSWORD: and an almost evil underscore _ almost willing me to try..
So I try.. but actually nothing types... and when I hit ENTER
LOGIN INCORECT
Vagrant-ubuntu-trusty-64 login: pops up.

So how do I get past this password thing?

Mark
markfrancombe
bennelong.bicyclist wrote:
Why don't you use the correct build environment as provided by Olivier in a VM, instead of mucking around in ancient versions of Windows? https://github.com/pichenettes/mutable-dev-environment


Yeah... see??? The answer to your question is that I havent got a clue what Im doing, so loading a pre built combo in file and shoving it on the chip via a cable SEEMS simpler before you try anything...

I am someone who has never used the command line before...

I should say, that if I jump straight in with:
Quote:
make -f clouds/makefile upload

then the password prompt pops up anyway...

Peeking into settings under General/Encryption/ there is a password registering box, but mines greyed out, I don't think thats anything to do with this anyhow...
bennelong.bicyclist
The vagrant script uses a key pair to log in, you shouldn't have to type a password, and typing passwords won't work. If you issue the commend "vagrant ssh" it should just log you in automatically, at the terminal prompt. Maybe something else is needed on Windows? Sorry, I don't have access to a Windows box, so I can't help.
sixty_n
the default root password for vagrant is 'vagrant' (just the word, no quotes). Maybe that will work
markfrancombe
forgot to mention... this VM stuff Im doing on a mac...

OK if it logs me in automatically... what should I see?

WAIT.. ok I got a clue from what you said... AM I writing vagrant ssh in Terminal or in the Black VM window... I have been doing it there.

But now I tried in terminal, and I got a lot of stuff about installing locales...
and final line says:

vagrant@vagrant-ubuntu-trusty-64:/vagrant/eurorack-modules (then the dollar sign, which I cant manage to find on my keyboard layout right now... Swedish keyboard on a Norwegian key layout, dont ask.. its a nightmare...)
markfrancombe
sixty_n wrote:
the default root password for vagrant is 'vagrant' (just the word, no quotes). Maybe that will work


Unfortunately not, as I mentioned, typing at the password prompt, doesnt actually allow me to type... so I cant type that password.. but thanks for the tip, maybe it will crop up later?
bennelong.bicyclist
Ah, OK, it seems like you are looking at the Virtualbox console. No need to do that. You interact with the VM via ssh from the terminal prompt (command line) where you issue the commend "vagrant ssh". Presumably you need PuTTY of similar installed as an SSH client on Windows XP? Not sure.
bennelong.bicyclist
markfrancombe wrote:
forgot to mention... this VM stuff Im doing on a mac...

OK if it logs me in automatically... what should I see?

WAIT.. ok I got a clue from what you said... AM I writing vagrant ssh in Terminal or in the Black VM window... I have been doing it there.

But now I tried in terminal, and I got a lot of stuff about installing locales...
and final line says:

vagrant@vagrant-ubuntu-trusty-64:/vagrant/eurorack-modules (then the dollar sign, which I cant manage to find on my keyboard layout right now... Swedish keyboard on a Norwegian key layout, dont ask.. its a nightmare...)


Yeah, that's exactly as it should be, so it worked fine! Now edit stmlib/makefile.inc to specify ST-Link v2 - this bit:

Quote:
# Supported: arm-usb-ocd, arm-usb-ocd-h, arm-usb-tiny-h, stlink-v2
PGM_INTERFACE ?= arm-usb-ocd-h
# hla for stlink-v2 ; jtag otherwise
PGM_INTERFACE_TYPE ?= tag


and then try to upload.
markfrancombe
Quote:
and then try to upload.


OK Did that... entered make -f clouds/makefile upload
in the terminal, not the VM window. Stlinl conected to Clouds, which was powered on. All 4 lights were on, 3 orange 1 red as before---

Something happened... a stream of junk in the Terminal window ending in

make: *** No rule to make target ´build/clouds_bootloader.hex, needed by build/clouds/clouds_bootloader_combo.bin . Stop

So... If I understand that correctly... it means that... no.. I dont understand that correctly... I dont understand...

Please Bennelong.bicycist, dont give up on me now!! You are closest so far...

PS: No change on clouds, all lights on... unless I turn bottom right knob, then it goes off, this was normal operation before the above fun...
Altitude909
you have to make the clouds_bootloader.hex first

This is all in the instructions: http://mutable-instruments.net/modules/clouds/open
bennelong.bicyclist
Try:

make -f clouds/makefile upload_combo_tag

Edit: if the upload_combo_tag target doesn't automatically compile the bootloader, do what Raph says above and compile it. Or just compile it anyway. As he says it's all in the instructions provided by Olivier Gillet. It's worth reading them and attempting to understand them. The magic of the module you have built is 90% firmware, after all. All your soldering was just to construct the relatively trivial hardware aspects.
markfrancombe
Jesus, how the hell do you guys know all this...

OK so I write this :
make -f clouds/bootloader/makefile hex

Lots of junk in Terminal window, ending with

make: warning: Clock skew detected. Your build may be incomplete.

So... theres that...
but also... Where IS IT? doesnt this make a file somewhere..

AND...
I do have those folders of all sorts of pre compiled stuff, hex files wav files bin files.. etc... cant I just put them some where and say DONE, and upload?
markfrancombe
bennelong.bicyclist wrote:
Try:

make -f clouds/makefile upload_combo_tag

Edit: if the upload_combo_tag target doesn't automatically compile the bootloader, do what Raph says above and compile it. Or just compile it anyway. As he says it's all in the instructions provided by Olivier Gillet. It's worth reading them and attempting to understand them. The magic of the module you have built is 90% firmware, after all. All your soldering was just to construct the relatively trivial hardware aspects.


Im trying... smile
nothing goes as smoothly here as with others it seems, every step has another hurdle...

So I ahve this "Clock Skew message"

and heres something on the Oliver Gillet page that I aint done... almost teh first thing actually...
Quote:
To build Clouds’ code, an ARM EABI toolchain must be installed. Because of tight CPU and code size limits, we recommend you to use the same compiler version as we do: 4.8-2013-q4-major. Various pre-compiled binaries and source packages are available here.


I spose I have to do that too..??




OT: You know what this reminds me of? when I used to play World of Warcraft a few years back.. Quest.. Get the Sword of Asaroth... travel many miles, its garded by a troll, that must be drugged by a special potion, flowers for potin only available in a far distant land, the field in which they grow are guarded by a horde of orcs... kill the orcs, pick flowers, potion must be made by a wizard in a far long distant land... and.. wait...
Hmm.. forgotton what I was doing now... lets play GTA instead..[/quote]
bennelong.bicyclist
No, the whole point of the vagrant VM is that the toolchain is installed in it - didn't you read that? So don't install anything.

Ignore the clock skew warnings, they don't matter.

So, with your ST-Link V2 connected to the mini-JTAG connector on your DIY Clouds, and connected to a USB port on your computer, and with the Clouds powered up, at the terminal prompt, issue:

make -f clouds/bootloader/makefile clean

make -f clouds/makefile clean

make -f clouds/bootloader/makefile hex

make -f clouds/makefile hex

make -f clouds/makefile upload_combo_jtag

If it doesn't work, cut and paste the output into a post here. Just saying "it spews out gibberish that I don't understand and I'd rather be playing a computer game" isn't very helpful.
markfrancombe
bennelong.bicyclist wrote:
No, the whole point of the vagrant VM is that the toolchain is installed in it - didn't you read that? So don't install anything.

I read:
Quote:
To build Clouds’ code, an ARM EABI toolchain must be installed. Because of tight CPU and code size limits, we recommend you to use the same compiler version as we do: 4.8-2013-q4-major. Various pre-compiled binaries and source packages are available here.


I dont know how you translate that into knowing that means that a tool chain is installed in Vagrant VM, I read it, and what I saw was...

We recommend you use the same compiler... available here...

That means to me "Install something" Not "So dont install anything"


bennelong.bicyclist wrote:

If it doesn't work, cut and paste the output into a post here. Just saying "it spews out gibberish that I don't understand and I'd rather be playing a computer game" isn't very helpful.


Thanks for the precise recipe, gonna run thru that right now..
Sorry you didn't like my attempt at humour... just trying to keep it light, certainly not suggesting I would rather by playing games, just commenting that, IF you don't know this stuff, learning it, is not really possible in a sensible and coherent way, one must try al sorts of things that you don't really understand, many of them, turn out to be wrong. Please don't let my flippancy or English grumbling be taken as not respecting or (massively) appreciating the fantastic help Im getting here, I cannot stress enough how thankful I am!
markfrancombe
ok ran through that whole procedure, and I have pages of output, rather than take up too much space here, you can go view the whole thing here:
https://docs.google.com/document/d/10Nxq3SE-tbR2wdGs94iyH6OAUSnNAQgfSZ n8gWsvcUo/edit?usp=sharing

but the pertinent line is probably... the last one.
make: *** No rule to make target `upload_combo_tag'. Stop.


But one thing here--- How do I know if its working?
What lights should I see on either the StLink or Clouds.
Currently the StLinks LED is constantly RED.
and Clouds LEDSs are all ON (although they go off if I wiggle, a re-pwer will bring them back)
When I was attempting to do this via ancient windows machine I did occasionally get it to connect, (now it never connects, but at the start I did have intermittent success) it would at least turn GREEN sometimes... this I took as " a good sign!"

not getting that now...
Remember Ive switched machines, and apart from the MI VM environment Vagrant stuff, have NOT installed anything St Link specific... Are there mac-ish drivers or something? Ive checked the ST web, and thats very PC-centric, that why I went and bought a cheapy PC.
bennelong.bicyclist
markfrancombe wrote:
bennelong.bicyclist wrote:
No, the whole point of the vagrant VM is that the toolchain is installed in it - didn't you read that? So don't install anything.

I read:
Quote:
To build Clouds’ code, an ARM EABI toolchain must be installed. Because of tight CPU and code size limits, we recommend you to use the same compiler version as we do: 4.8-2013-q4-major. Various pre-compiled binaries and source packages are available here.


I dont know how you translate that into knowing that means that a tool chain is installed in Vagrant VM, I read it, and what I saw was...


But the very first sentence on the page that tells you how to install the Vagrant environment says:

Quote:
Vagrant environment for Mutable Instruments modules hacking

This configuration file and this shellscript create a Linux (ubuntu) virtual machine configured with all the right tools for compiling and installing the firmware of Mutable Instruments' modules.


Never mind...
bennelong.bicyclist
markfrancombe wrote:

but the pertinent line is probably... the last one.
make: *** No rule to make target `upload_combo_tag'. Stop.


Sorry, that was a typo on my part (now fixed), the last command should be:

make -f clouds/makefile upload_combo_jtag

Try that.
markfrancombe
OK Tried that:

How can I confirm that its even connecting to the module, I dont like this RED LED on the StLink.

Ill post whole message here.. not so huge.

vagrant@vagrant-ubuntu-trusty-64:/vagrant/eurorack-modules$ make -f clouds/makefile upload_combo_jtag
cat build/clouds/clouds.hex build/clouds_bootloader/clouds_bootloader.hex | \
awk -f stmlib/programming/merge_hex.awk > build/clouds/clouds_bootloader_combo.hex
/usr/local/arm-4.8.3/bin/arm-none-eabi-objcopy -I ihex -O binary build/clouds/clouds_bootloader_combo.hex build/clouds/clouds_bootloader_combo.bin
openocd -f stmlib/programming/jtag/interface_stlink-v2.cfg -f stmlib/programming/jtag/stm32f4xx_stlink-v2.cfg -f stmlib/programming/jtag/prelude_f4xx.cfg -f stmlib/programming/jtag/erase_f4xx.cfg -c "flash write_bank 0 build/clouds/clouds_bootloader_combo.bin 0x0" -c "verify_image build/clouds/clouds_bootloader_combo.bin" -f stmlib/programming/jtag/postlude.cfg || openocd -f stmlib/programming/jtag/interface_stlink-v2.cfg -f stmlib/programming/jtag/stm32f4xx_stlink-v2.cfg -f stmlib/programming/jtag/prelude_f4xx.cfg -f stmlib/programming/jtag/erase_f4xx.cfg -c "flash write_bank 0 build/clouds/clouds_bootloader_combo.bin 0x0" -c "verify_image build/clouds/clouds_bootloader_combo.bin" -f stmlib/programming/jtag/postlude.cfg
Open On-Chip Debugger 0.9.0 (2015-10-08-17:56)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
hla_jtag
embedded:startup.tcl:60: Error: Can't find stmlib/programming/jtag/stm32f4xx_stlink-v2.cfg
in procedure 'script'
at file "embedded:startup.tcl", line 60
Open On-Chip Debugger 0.9.0 (2015-10-08-17:56)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
hla_jtag
embedded:startup.tcl:60: Error: Can't find stmlib/programming/jtag/stm32f4xx_stlink-v2.cfg
in procedure 'script'
at file "embedded:startup.tcl", line 60
make: *** [upload_combo_jtag] Error 1
vagrant@vagrant-ubuntu-trusty-64:/vagrant/eurorack-modules$
bennelong.bicyclist
markfrancombe wrote:
OK Tried that:

How can I confirm that its even connecting to the module, I dont like this RED LED on the StLink.

Ill post whole message here.. not so huge.

vagrant@vagrant-ubuntu-trusty-64:/vagrant/eurorack-modules$ make -f clouds/makefile upload_combo_jtag
cat build/clouds/clouds.hex build/clouds_bootloader/clouds_bootloader.hex | \
awk -f stmlib/programming/merge_hex.awk > build/clouds/clouds_bootloader_combo.hex
/usr/local/arm-4.8.3/bin/arm-none-eabi-objcopy -I ihex -O binary build/clouds/clouds_bootloader_combo.hex build/clouds/clouds_bootloader_combo.bin
openocd -f stmlib/programming/jtag/interface_stlink-v2.cfg -f stmlib/programming/jtag/stm32f4xx_stlink-v2.cfg -f stmlib/programming/jtag/prelude_f4xx.cfg -f stmlib/programming/jtag/erase_f4xx.cfg -c "flash write_bank 0 build/clouds/clouds_bootloader_combo.bin 0x0" -c "verify_image build/clouds/clouds_bootloader_combo.bin" -f stmlib/programming/jtag/postlude.cfg || openocd -f stmlib/programming/jtag/interface_stlink-v2.cfg -f stmlib/programming/jtag/stm32f4xx_stlink-v2.cfg -f stmlib/programming/jtag/prelude_f4xx.cfg -f stmlib/programming/jtag/erase_f4xx.cfg -c "flash write_bank 0 build/clouds/clouds_bootloader_combo.bin 0x0" -c "verify_image build/clouds/clouds_bootloader_combo.bin" -f stmlib/programming/jtag/postlude.cfg
Open On-Chip Debugger 0.9.0 (2015-10-08-17:56)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
hla_jtag
embedded:startup.tcl:60: Error: Can't find stmlib/programming/jtag/stm32f4xx_stlink-v2.cfg
in procedure 'script'
at file "embedded:startup.tcl", line 60
Open On-Chip Debugger 0.9.0 (2015-10-08-17:56)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
hla_jtag
embedded:startup.tcl:60: Error: Can't find stmlib/programming/jtag/stm32f4xx_stlink-v2.cfg
in procedure 'script'
at file "embedded:startup.tcl", line 60
make: *** [upload_combo_jtag] Error 1
vagrant@vagrant-ubuntu-trusty-64:/vagrant/eurorack-modules$


I just fired up the vagrant VM and tried it - it works perfectly for me. Did you edit stmlib/makefile.inc as instructed? The relevant lines should look like this (ignore those starting with #, they are just comments):

# Supported: arm-usb-ocd, arm-usb-ocd-h, arm-usb-tiny-h, stlink-v2
# PGM_INTERFACE ?= arm-usb-ocd-h
PGM_INTERFACE = stlink-v2
# hla for stlink-v2 ; jtag otherwise
# PGM_INTERFACE_TYPE ?= jtag
PGM_INTERFACE_TYPE = hla
markfrancombe
bennelong.bicyclist wrote:

I just fired up the vagrant VM and tried it - it works perfectly for me. Did you edit stmlib/makefile.inc as instructed? The relevant lines should look like this (ignore those starting with #, they are just comments):

# Supported: arm-usb-ocd, arm-usb-ocd-h, arm-usb-tiny-h, stlink-v2
# PGM_INTERFACE ?= arm-usb-ocd-h
PGM_INTERFACE = stlink-v2
# hla for stlink-v2 ; jtag otherwise
# PGM_INTERFACE_TYPE ?= jtag
PGM_INTERFACE_TYPE = hla


Yes I did follow your instructions, but not, did not end up with an identical result.. I had:

# Supported: arm-usb-ocd, arm-usb-ocd-h, arm-usb-tiny-h, stlink-v2
PGM_INTERFACE ?= stlink-v2
# hla for stlink-v2 ; jtag otherwise
PGM_INTERFACE_TYPE ?= stlink-v2

I see where I went wrong. I used the jtag, when it should be hla. (The stLink is finnally plugged into the jtag connector so you can see my confusion here...
Making these changes and seeing what happens.

Should I run through ALL the make commands again, or just the upload?
bennelong.bicyclist
Just the upload command.
markfrancombe
This was in the previous bunch of errors too...

embedded:startup.tcl:60: Error: Can't find stmlib/programming/jtag/interface_stlink-v2
in procedure 'script'
at file "embedded:startup.tcl", line 60
Open On-Chip Debugger 0.9.0 (2015-10-08-17:56)

Although I do seem to have that file at that location.
markfrancombe
Can we double check the whole chunk in makefile.inc
Im concerned that in your example, when specifiy your needs you removed the ? from the # lines... Is my Tool chain path correct?

# Files and directories
# ---------------------------------------------------------------------- --------

TOOLCHAIN_PATH ?= /usr/local/arm/

# Supported: arm-usb-ocd, arm-usb-ocd-h, arm-usb-tiny-h, stlink-v2
# PGM_INTERFACE ?= arm-usb-ocd-h
PGM_INTERFACE = stlink-v2
# hla for stlink-v2 ; jtag otherwise
# PGM_INTERFACE_TYPE ?= jtag
PGM_INTERFACE_TYPE = hla


PGM_SERIAL_PORT ?= /dev/ftdi-usbserial
PGM_SERIAL_BAUD_RATE ?= 115200
PGM_SERIAL_VERIFY ?= -v


The other thing Im wondering is, did I make clear what my hardware even is? Maybe you are assuming Im using the same as you?
Lets clear that up too?
bennelong.bicyclist
The paths are relative, so you need to run the make commands from the root of the distribution, i.e., from /vagrant/eurorack-modules

If that doesn't work, I'm out of suggestions.
markfrancombe
Snagged from above, doesnt this show my whole path that Im firing that command from.. (New to Command line so what do I know?)

vagrant@vagrant-ubuntu-trusty-64:/vagrant/eurorack-modules$ make -f clouds/makefile upload_combo_jtag
bennelong.bicyclist
markfrancombe wrote:
Can we double check the whole chunk in makefile.inc
Im concerned that in your example, when specifiy your needs you removed the ? from the # lines... Is my Tool chain path correct?

# Files and directories
# ---------------------------------------------------------------------- --------

TOOLCHAIN_PATH ?= /usr/local/arm/

# Supported: arm-usb-ocd, arm-usb-ocd-h, arm-usb-tiny-h, stlink-v2
# PGM_INTERFACE ?= arm-usb-ocd-h
PGM_INTERFACE = stlink-v2
# hla for stlink-v2 ; jtag otherwise
# PGM_INTERFACE_TYPE ?= jtag
PGM_INTERFACE_TYPE = hla


PGM_SERIAL_PORT ?= /dev/ftdi-usbserial
PGM_SERIAL_BAUD_RATE ?= 115200
PGM_SERIAL_VERIFY ?= -v


The other thing Im wondering is, did I make clear what my hardware even is? Maybe you are assuming Im using the same as you?
Lets clear that up too?


The ?= just means conditional assignment. Using ?= or just = in this context shouldn't matter.

The problem, at this stage, isn't your hardware, it's that the makefile is crapping out.
bennelong.bicyclist
markfrancombe wrote:
Snagged from above, doesnt this show my whole path that Im firing that command from.. (New to Command line so what do I know?)

vagrant@vagrant-ubuntu-trusty-64:/vagrant/eurorack-modules$ make -f clouds/makefile upload_combo_jtag


Yes, that's correct. Sorry, I'm out of ideas.
markfrancombe
Then this remains my biggest clue.

Error: Can't find stmlib/programming/jtag/interface_stlink-v2
gbiz
markfrancombe wrote:
Then this remains my biggest clue.

Error: Can't find stmlib/programming/jtag/interface_stlink-v2


Do you really get exactly that message or does it complain about not finding "stmlib/programming/jtag/interface_stlink-v2.cfg" ?
markfrancombe
Ive had both, with and without the .cfg

The last complete error was: This came after BB posted his edit of the makefile, and I had one slight difference, so i changed mine.

vagrant@vagrant-ubuntu-trusty-64:/vagrant/eurorack-modules$ make -f clouds/makefile upload_combo_jtag
cat build/clouds/clouds.d build/clouds/cv_scaler.d build/clouds/resources.d build/clouds/settings.d build/clouds/ui.d build/clouds/adc.d build/clouds/codec.d build/clouds/debug_port.d build/clouds/gate_input.d build/clouds/leds.d build/clouds/switches.d build/clouds/system.d build/clouds/correlator.d build/clouds/granular_processor.d build/clouds/mu_law.d build/clouds/frame_transformation.d build/clouds/phase_vocoder.d build/clouds/stft.d build/clouds/atan.d build/clouds/units.d build/clouds/random.d build/clouds/bootloader_utils.d build/clouds/system_clock.d build/clouds/core_cm3.d build/clouds/system_stm32f4xx.d build/clouds/misc.d build/clouds/stm32f4xx_adc.d build/clouds/stm32f4xx_can.d build/clouds/stm32f4xx_crc.d build/clouds/stm32f4xx_cryp_aes.d build/clouds/stm32f4xx_cryp.d build/clouds/stm32f4xx_cryp_des.d build/clouds/stm32f4xx_cryp_tdes.d build/clouds/stm32f4xx_dac.d build/clouds/stm32f4xx_dbgmcu.d build/clouds/stm32f4xx_dcmi.d build/clouds/stm32f4xx_dma.d build/clouds/stm32f4xx_exti.d build/clouds/stm32f4xx_flash.d build/clouds/stm32f4xx_fsmc.d build/clouds/stm32f4xx_gpio.d build/clouds/stm32f4xx_hash.d build/clouds/stm32f4xx_hash_md5.d build/clouds/stm32f4xx_hash_sha1.d build/clouds/stm32f4xx_i2c.d build/clouds/stm32f4xx_iwdg.d build/clouds/stm32f4xx_pwr.d build/clouds/stm32f4xx_rcc.d build/clouds/stm32f4xx_rng.d build/clouds/stm32f4xx_rtc.d build/clouds/stm32f4xx_sdio.d build/clouds/stm32f4xx_spi.d build/clouds/stm32f4xx_syscfg.d build/clouds/stm32f4xx_tim.d build/clouds/stm32f4xx_usart.d build/clouds/stm32f4xx_wwdg.d build/clouds/startup_stm32f4xx.d > build/clouds/depends.mk
openocd -f stmlib/programming/jtag/interface_stlink-v2 .cfg -f stmlib/programming/jtag/stm32f4xx_hla.cfg -f stmlib/programming/jtag/prelude_f4xx.cfg -f stmlib/programming/jtag/erase_f4xx.cfg -c "flash write_bank 0 build/clouds/clouds_bootloader_combo.bin 0x0" -c "verify_image build/clouds/clouds_bootloader_combo.bin" -f stmlib/programming/jtag/postlude.cfg || openocd -f stmlib/programming/jtag/interface_stlink-v2 .cfg -f stmlib/programming/jtag/stm32f4xx_hla.cfg -f stmlib/programming/jtag/prelude_f4xx.cfg -f stmlib/programming/jtag/erase_f4xx.cfg -c "flash write_bank 0 build/clouds/clouds_bootloader_combo.bin 0x0" -c "verify_image build/clouds/clouds_bootloader_combo.bin" -f stmlib/programming/jtag/postlude.cfg
Open On-Chip Debugger 0.9.0 (2015-10-08-17:56)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
embedded:startup.tcl:60: Error: Can't find stmlib/programming/jtag/interface_stlink-v2
in procedure 'script'
at file "embedded:startup.tcl", line 60
Open On-Chip Debugger 0.9.0 (2015-10-08-17:56)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
embedded:startup.tcl:60: Error: Can't find stmlib/programming/jtag/interface_stlink-v2
in procedure 'script'
at file "embedded:startup.tcl", line 60
make: *** [upload_combo_jtag] Error 1
vagrant@vagrant-ubuntu-trusty-64:/vagrant/eurorack-modules$
gbiz
That output is telling you what's wrong. If you look closely you'll see
"openocd -f stmlib/programming/jtag/interface_stlink-v2 .cfg ....."

You have a space at the end of the stlink-v2
"PGM_INTERFACE = stlink-v2 "
.........................................^

You need (without the quote marks)
"PGM_INTERFACE = stlink-v2"

Interesting. Your cut & paste from the makefile preserves the space.
markfrancombe
gbiz wrote:
That output is telling you what's wrong. If you look closely you'll see
"openocd -f stmlib/programming/jtag/interface_stlink-v2 .cfg ....."

You have a space at the end of the stlink-v2
"PGM_INTERFACE = stlink-v2 "
.........................................^

You need (without the quote marks)
"PGM_INTERFACE = stlink-v2"

Interesting. Your cut & paste from the makefile preserves the space.


this
"PGM_INTERFACE = stlink-v2

Is what i edited in the makefile right?

In a doctors waiting room right now, but will try to correct when i Get back home...
Thanks...
bennelong.bicyclist
gbiz wrote:
That output is telling you what's wrong. If you look closely you'll see
"openocd -f stmlib/programming/jtag/interface_stlink-v2 .cfg ....."

You have a space at the end of the stlink-v2
"PGM_INTERFACE = stlink-v2 "
.........................................^

You need (without the quote marks)
"PGM_INTERFACE = stlink-v2"

Interesting. Your cut & paste from the makefile preserves the space.


Well spotted. And yes, seeing the full error message helps, rather than some selective output judged to be relevant...
gbiz
markfrancombe wrote:
gbiz wrote:
That output is telling you what's wrong. If you look closely you'll see
"openocd -f stmlib/programming/jtag/interface_stlink-v2 .cfg ....."

You have a space at the end of the stlink-v2
"PGM_INTERFACE = stlink-v2 "
.........................................^

You need (without the quote marks)
"PGM_INTERFACE = stlink-v2"

Interesting. Your cut & paste from the makefile preserves the space.


this
"PGM_INTERFACE = stlink-v2

Is what i edited in the makefile right?

In a doctors waiting room right now, but will try to correct when i Get back home...
Thanks...


Correct. What you edited in the makefile.
gbiz
bennelong.bicyclist wrote:
gbiz wrote:
That output is telling you what's wrong. If you look closely you'll see
"openocd -f stmlib/programming/jtag/interface_stlink-v2 .cfg ....."

You have a space at the end of the stlink-v2
"PGM_INTERFACE = stlink-v2 "
.........................................^

You need (without the quote marks)
"PGM_INTERFACE = stlink-v2"

Interesting. Your cut & paste from the makefile preserves the space.


Well spotted. And yes, seeing the full error message helps, rather than some selective output judged to be relevant...


hihi

To be fair to Mark though, he's far from the first to have ever done that.
Puzzler
Now you guys let him compile the code on a Linux VM?!
He didnt even manage to upload the binaries via Windows.
You crazy? Miley Cyrus

I suggest to get another computer with windows 7 installed and try it. Some of your friend will have a laptop i guess.
adam
i thought this vm supported stlink2?
Altitude909
If the Stlink software cant connect to the chip, it's a hardware problem. If that check doesnt work, nothing else will either. Either the chip is bad (which I doubt, I've desoldered and resoldered one more than once) or there is a bad connection or bridge on one of the pins. Trying some other programming approach isnt going to fix it
gbiz
It does when you put "stlink-v2" & not "stlink-v2 " in the makefile hihi
Altitude909
adam wrote:
i thought this vm supported stlink2?


You have to call it out in the .inc, it's the olimex by default
markfrancombe
guys.. calm down!

I am gonna try the StLink Utility on Windows Modern, but as I routinely use mac, and the VM method is approved by MI, I see no harm in trying.
I cannot believe that this worked totally out of the box for everyone, and Im making detailed notes of what IM doing. For a newb like me it aint easy, especially when the complete instructions are bite and pieces spread over 3 or 4 site/pages, or posts in this thread. IF I ever get this shit working, Ill publish a newbs guide,
As Altitude said,It might easily be a build problem, and Im checking/working with that too, but Ive had no response regarding best practice way to check it the module is functional, but im checking resistor values, and continuity checking. I admit Im a little nervouse about doing a "plugged in" voltage check with this its-bitsy legs, a slip of the probe can blow shit up... but Im heading there...

About to remove a space, and try again...
Puzzler
Better, closer and higher resolution pictires woukld be helpful.
Your first pics were totally useless. hihi
markfrancombe
Well of course I didnt totally expect it to work: But got rid of the previous error...

Ill wait with this method for a bit I think, and Follow Altitudes advice, At least TRY with a modern PC,and StLink Utility... wanna just rule out that...

Would be nice to get the VM working, both for mac support for me, and.. well Im a bit of a completionist... call it a leaning experience...

Anyway, for thise interested, heres the output from the previous NO SPACE IN MAKEFILE version..

vagrant@vagrant-ubuntu-trusty-64:/vagrant/eurorack-modules$ make -f clouds/makefile upload_combo_jtag
openocd -f stmlib/programming/jtag/interface_stlink-v2.cfg -f stmlib/programming/jtag/stm32f4xx_hla.cfg -f stmlib/programming/jtag/prelude_f4xx.cfg -f stmlib/programming/jtag/erase_f4xx.cfg -c "flash write_bank 0 build/clouds/clouds_bootloader_combo.bin 0x0" -c "verify_image build/clouds/clouds_bootloader_combo.bin" -f stmlib/programming/jtag/postlude.cfg || openocd -f stmlib/programming/jtag/interface_stlink-v2.cfg -f stmlib/programming/jtag/stm32f4xx_hla.cfg -f stmlib/programming/jtag/prelude_f4xx.cfg -f stmlib/programming/jtag/erase_f4xx.cfg -c "flash write_bank 0 build/clouds/clouds_bootloader_combo.bin 0x0" -c "verify_image build/clouds/clouds_bootloader_combo.bin" -f stmlib/programming/jtag/postlude.cfg
Open On-Chip Debugger 0.9.0 (2015-10-08-17:56)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
hla_jtag
adapter speed: 2000 kHz
adapter_nsrst_delay: 100
trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain connect_deassert_srst
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
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 v24 API v2 SWIM v4 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 3.206311
Error: init mode failed (unable to connect to the target)
in procedure 'init' called at file "stmlib/programming/jtag/prelude_f4xx.cfg", line 23
in procedure 'ocd_bouncer'

Open On-Chip Debugger 0.9.0 (2015-10-08-17:56)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
hla_jtag
adapter speed: 2000 kHz
adapter_nsrst_delay: 100
trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain connect_deassert_srst
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
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 v24 API v2 SWIM v4 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 3.204734
Error: init mode failed (unable to connect to the target)
in procedure 'init' called at file "stmlib/programming/jtag/prelude_f4xx.cfg", line 23
in procedure 'ocd_bouncer'

make: *** [upload_combo_jtag] Error 1
vagrant@vagrant-ubuntu-trusty-64:/vagrant/eurorack-modules$
Puzzler
Error: init mode failed (unable to connect to the target)

Same error...So?

Pictures!!!
markfrancombe
Puzzler wrote:


Pictures!!!


Yeah.. Im on to it... need better than an iPhone...
The neighbour is a pro photographer, maybe I can get some pics that are so big Ill jam up Imgur...

Mark
Altitude909
Puzzler wrote:
Error: init mode failed (unable to connect to the target)



This. The uC isnt responding to anything. You need to get a good magnifier and take a crazy close look at those pins, I had some initial problems where the legs were not down all the way so it looked ok from the top but when you turned the part sideways, you could see that they were not making contact
aristote
Hi there ! I'm trying to setup the VM toolchain, on a stlink-v2 STM32F4 discovery board. I know it's not gonna be really useful but it's just to be sure that any fail is not hardware related.

i managed to compile the hex and bin version or the Braids firmware but the upload part fails. (Using the windows tool to push the firmware is ok).
i've double check that there's no space at the end of lines.

I've got the same error. see bellow :
Quote:

vagrant@vagrant-ubuntu-trusty-64:/vagrant/eurorack-modules$ make -f braids/makefile upload_combo_jtag
openocd -f stmlib/programming/jtag/interface_stlink-v2.cfg -f stmlib/programming/jtag/stm32f10x_hla.cfg -f stmlib/programming/jtag/prelude_f10x.cfg -f stmlib/programming/jtag/erase_f10x.cfg -c "flash write_bank 0 build/braids/braids_bootloader_combo.bin 0x0" -c "verify_image build/braids/braids_bootloader_combo.bin" -f stmlib/programming/jtag/postlude.cfg || openocd -f stmlib/programming/jtag/interface_stlink-v2.cfg -f stmlib/programming/jtag/stm32f10x_hla.cfg -f stmlib/programming/jtag/prelude_f10x.cfg -f stmlib/programming/jtag/erase_f10x.cfg -c "flash write_bank 0 build/braids/braids_bootloader_combo.bin 0x0" -c "verify_image build/braids/braids_bootloader_combo.bin" -f stmlib/programming/jtag/postlude.cfg
Open On-Chip Debugger 0.9.0 (2015-10-05-09:24)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
hla_jtag
adapter speed: 1000 kHz
adapter_nsrst_delay: 200
trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain connect_deassert_srst
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
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 v14 API v2 SWIM v0 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 2.909911
Error: init mode failed (unable to connect to the target)
in procedure 'init' called at file "stmlib/programming/jtag/prelude_f10x.cfg", line 23
in procedure 'ocd_bouncer'


i also tried using "make -f braids/makefile upload" with the same error output.
Quote:

vagrant@vagrant-ubuntu-trusty-64:/vagrant/eurorack-modules$ make -f braids/makefile upload
openocd -f stmlib/programming/jtag/interface_stlink-v2.cfg -f stmlib/programming/jtag/stm32f10x_hla.cfg -f stmlib/programming/jtag/prelude_f10x.cfg -f stmlib/programming/jtag/erase_f10x.cfg -c "flash write_bank 0 build/braids/braids_bootloader_combo.bin 0x0" -c "verify_image build/braids/braids_bootloader_combo.bin" -f stmlib/programming/jtag/postlude.cfg || openocd -f stmlib/programming/jtag/interface_stlink-v2.cfg -f stmlib/programming/jtag/stm32f10x_hla.cfg -f stmlib/programming/jtag/prelude_f10x.cfg -f stmlib/programming/jtag/erase_f10x.cfg -c "flash write_bank 0 build/braids/braids_bootloader_combo.bin 0x0" -c "verify_image build/braids/braids_bootloader_combo.bin" -f stmlib/programming/jtag/postlude.cfg
Open On-Chip Debugger 0.9.0 (2015-10-05-09:24)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
hla_jtag
adapter speed: 1000 kHz
adapter_nsrst_delay: 200
trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain connect_deassert_srst
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
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 v14 API v2 SWIM v0 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 2.909911
Error: init mode failed (unable to connect to the target)
in procedure 'init' called at file "stmlib/programming/jtag/prelude_f10x.cfg", line 23
in procedure 'ocd_bouncer'


here is the content of the ./stmlib/makefile.inc

Quote:
# ---------------------------------------------------------------------- --------
# Files and directories
# ---------------------------------------------------------------------- --------

TOOLCHAIN_PATH ?= /usr/local/arm/

# Supported: arm-usb-ocd, arm-usb-ocd-h, arm-usb-tiny-h, stlink-v2
PGM_INTERFACE ?= stlink-v2
# hla for stlink-v2 ; jtag otherwise
PGM_INTERFACE_TYPE ?= hla

PGM_SERIAL_PORT ?= /dev/ftdi-usbserial
PGM_SERIAL_BAUD_RATE ?= 115200
PGM_SERIAL_VERIFY ?= -v


Moreover on the discovery board the two jumpers are setup to be on the discovery mode (internal chip) and not the stink (external chip). I've checked this with the windows ST tool. When the jumpers are ON, i can upload the firmware, when the jumper are OFF, i can't upload because i didn't plug any external chip.

Any help would be appreciated smile
markfrancombe
One thing I just noticed when I picked it up to disconnect everything, the Voltage Reg LM1117DT-3.3/NOPB is SERIOUSLY hot... as in OUCH!
Surely THAT not normal. Having never used one of them before Im assuming that the tiny "cut-off"pin in the middle shuld NOT connect anywhere? theres no pad for it,and it would need a wire anyway, It just an alternative mount right?

So, why might that be super hot... Its should be puttin out what? 3.3?? which pins... oh never mind Im off to find Data sheet,
...but.. why hot?
adam
hot probably means a short circuit
gbiz
The tab is the output.
markfrancombe
gbiz wrote:
The tab is the output.


Yeah the big tab, but on the other side, there are 3 pins, 2 long ones on either side, they conect with the pcb ok, but in between them there is a shorter leg, that doesnt marry up wit6h anything... i dont think there anything weird there---
Altitude909
short leg is connected to the big tab
markfrancombe
Altitude909 wrote:
short leg is connected to the big tab


OK, this may be a very serious error. Lets just confirm this.
See image

FYI, I took super high quality pics with my neighbour today. didnt get them off his camera just yet, but DID see 3 suspect pins on the arm. One which, although appears not to be touching, IS a bit blobby.1 that maybe not be soldered at all, and another that was hard to tell, but again, may be a weak link.
ill re-do them. His macro lens was better than all magnifiers I have tried so far, including a microscope, due to being able take a pc at an oblique angle...

A few things to try tomorrow
Altitude909
big tab must be soldered securely, center pad doesn't get soldered to anything. I cant even tell you what the purpose of that is, it is connected to the big tab internally though.

If you're regulator is getting super hot, that usually means a short on that power rail. Check resistance of the output of the vReg to ground
bennelong.bicyclist
Yup, you almost certainly have a short. Some of those 100 nF 0603 decoupling caps on the 3V3 rail coming out of that regulator look very wonky. A solder bridge across the pads, which can be hidden under the cap, on any of those will cause a short. Check the DC resistance across each one of those, using the schematic as a guide. But be careful when checking - it is possible to zap your processor if you poke the wrong pins on the MPU chip with your multimeter in ohmmeter (or continuity testing) mode. And obviously, disconnect from power before doing any of this.
markfrancombe
Altitude909 wrote:
big tab must be soldered securely, centre pad doesn't get soldered to anything. I cant even tell you what the purpose of that is, it is connected to the big tab internally though.

OK Well that seems ok then.
Altitude909 wrote:

If you're regulator is getting super hot, that usually means a short on that power rail. Check resistance of the output of the vReg to ground

What sort of resistance am I looking for?

bennelong.bicyclist wrote:
Some of those 100 nF 0603 decoupling caps on the 3V3 rail coming out of that regulator look very wonky. A solder bridge across the pads, which can be hidden under the cap, on any of those will cause a short.


Im afraid I would'nt know which caps were specifically "decoupling" caps, but certainly theres a very skew-if one right in the middle of the pic above, C23 i think. IM GONNA DEF PULL THAT ONE OF AND RE-DO!
bennelong.bicyclist wrote:


Check the DC resistance across each one of those, using the schematic as a guide.

again, what sort of reading can I expect, or do I want to see? I know that reading a resister "in place" will not ness give the correct ohm-age, things in parallel etc, but what of caps...?
bennelong.bicyclist wrote:

But be careful when checking - it is possible to zap your processor if you poke the wrong pins on the MPU chip with your multimeter in ohmmeter (or continuity testing) mode. And obviously, disconnect from power before doing any of this.


thanks for your help guys, seriously appreciated..
Altitude909
The resistance should be a couple hundred ohm- 1 or 2k. It varies on a lot of things but what you are looking for is continuity (the beep) or very low resistance.

That will only confirm what is obvious though, you have a power rail short somewhere on the 3.3 line which is sagging the voltage and preventing the uC from powering up. In eagle, take the eyeball tool and select the output of the offending vReg, it will highlight the 3.3V line, your problem is most likely along that trace somewhere
gbiz
I just checked back through the Clouds thread where someone else had this issue. I'd measured 600 ohms between 3v3 & 0V on one of mine.
markfrancombe
Altitude909 wrote:
The resistance should be a couple hundred ohm- 1 or 2k. It varies on a lot of things but what you are looking for is continuity (the beep) or very low resistance.

That will only confirm what is obvious though, you have a power rail short somewhere on the 3.3 line which is sagging the voltage and preventing the uC from powering up. In eagle, take the eyeball tool and select the output of the offending vReg, it will highlight the 3.3V line, your problem is most likely along that trace somewhere


Im getting about 500, checking the line now.
gbiz
Whats the impedance between the top of the big tab on the regulator & a 3v3 pad somewhere else on the board ?.
markfrancombe
gbiz wrote:
Whats the impedance between the top of the big tab on the regulator & a 3v3 pad somewhere else on the board ?.


You would have to give me a suggestion Im afriad, Im not sure what would be a 3.3 pad. are the chips all 3.3 power?

Not fully understanding Eagle, would it be anywhere here? (This would needa reading with power ON right? Not something I really feel safe about)



By the way, super happy you are helping gbiz... one might call you Mr Cloud hihi
markfrancombe
HOWEVER, I did dare to read the output from the reg (big pad) and it was 3.3 (or 3.28 to be precise).. at least thats something...
adam
impedance sort of = resistance - you can measure the same way as you did just now
gbiz
So is the regulator still getting hot now it's supplying 3.3V ?.
markfrancombe
adam wrote:
impedance sort of = resistance - you can measure the same way as you did just now


My question was really, where else on the board should it be showing 3.3

Quote:
So is the regulator still getting hot now it's supplying 3.3V ?.

checking now...
actually not... I have now replaced C23 and one other wonky cap...
gbiz
markfrancombe wrote:

My question was really, where else on the board should it be showing 3.3


You had it in that Eagle export image. Anything that shows red (component side) or blue (solder side). The pads on the pushbutton next to the right hand edge of the PCB would be a good start.

Quote:
So is the regulator still getting hot now it's supplying 3.3V ?.

markfrancombe wrote:

checking now...
actually not... I have now replaced C23 and one other wonky cap...


Now you have a working 3.3V try uploading the firmware again.
markfrancombe
gbiz wrote:
Whats the impedance between the top of the big tab on the regulator & a 3v3 pad somewhere else on the board ?.


Well "impedance" is 0 between that pad and any of those points shown in red on the Eagle. I check for voltage on those same places. (One probe on gnd and the other on those points) and got 3.3v at ALL of them, even each corner cap of the processor.

bennelong.bicyclist wrote:


But be careful when checking - it is possible to zap your processor if you poke the wrong pins on the MPU chip with your multimeter in ohmmeter (or continuity testing) mode. And obviously, disconnect from power before doing any of this.


See Im very frightened about this, in fact, can anyone lay down a process whereby I can check the vital signs of the Processor? Have I killed it already? I have got a spare (I was considering making a second clouds, but re-evaluating THAT idea right now) So I could swap it, but of course it would be NICE to KNOW it was dead, before hacking those legs and fiddling with putting on a new one, especially that the board is now populated with knobs and shit...

THE FEAR
First time I tried to connect via StLink Utility, I DID GET occasional connection, or so it said... now never happens... something has changed, and change.. is not always a good thing...

gbiz wrote:

Now you have a working 3.3V try uploading the firmware again.


YEah, gave it a bash... no luck, I must say Im STILL not convinced of my set up re the flashing. I have 2 methdologies set up right now, and neither am I 100% certain is functional.
1. I have the STLink Utility set up on an old XP PC, so there might be a problem right there... (Yes yes I will get my wifes PC some time, but she refuses to re-start it right now due to coming very close to the end of her PhD and having 70 tabs open on her browser.. yeah.. I know.. Ive told her.. but)
2. I have set up the VM on a mac (actually trying on my laptop today as well) and that hasnt been a walk in the park due to newb-ness and old person issues... Im not sure I even managed to build the bootloader.

Here a thing though. I DO HAVE the bootloader and the software AND THE COMBO files from that other source, so I dont really NEED to build them do I? Just upload them? SO IF I was building them, where would those files build to, can I not just copy my pre-compiled bins to that directory and try to use the VM for uploading only?
(Again I realise this might be an obvious face palm moment for you guys... but If you dont ask you dont learn)

I have a FDTI friend on the way, but now I realise thats just using the VM again, so I cant see changing connections would have an effect really...
gbiz
markfrancombe wrote:
gbiz wrote:
Whats the impedance between the top of the big tab on the regulator & a 3v3 pad somewhere else on the board ?.


Well "impedance" is 0 between that pad and any of those points shown in red on the Eagle. I check for voltage on those same places. (One probe on gnd and the other on those points) and got 3.3v at ALL of them, even each corner cap of the processor.


OK, so the regulator is working fine & you have 3.3V.

markfrancombe wrote:

bennelong.bicyclist wrote:

But be careful when checking - it is possible to zap your processor if you poke the wrong pins on the MPU chip with your multimeter in ohmmeter (or continuity testing) mode. And obviously, disconnect from power before doing any of this.


See Im very frightened about this, in fact, can anyone lay down a process whereby I can check the vital signs of the Processor? Have I killed it already? I have got a spare (I was considering making a second clouds, but re-evaluating THAT idea right now) So I could swap it, but of course it would be NICE to KNOW it was dead, before hacking those legs and fiddling with putting on a new one, especially that the board is now populated with knobs and shit...


Uploading the firmware is how you check the MCU.

Before you swap it, give the MCU pins a decent visual check with something like a jewllers loupe. If you can, upload some decent hi-res pics.

Also, check the soldering around the JTAG header for shorts.

markfrancombe wrote:

gbiz wrote:

Now you have a working 3.3V try uploading the firmware again.


YEah, gave it a bash... no luck, I must say Im STILL not convinced of my set up re the flashing. I have 2 methdologies set up right now, and neither am I 100% certain is functional.
1. I have the STLink Utility set up on an old XP PC, so there might be a problem right there... (Yes yes I will get my wifes PC some time, but she refuses to re-start it right now due to coming very close to the end of her PhD and having 70 tabs open on her browser.. yeah.. I know.. Ive told her.. but)
2. I have set up the VM on a mac (actually trying on my laptop today as well) and that hasnt been a walk in the park due to newb-ness and old person issues... Im not sure I even managed to build the bootloader.


IMO, you're better off sticking with the VM. It's a known working environment. openocd gives a good amount of debugging detail.

markfrancombe wrote:

Here a thing though. I DO HAVE the bootloader and the software AND THE COMBO files from that other source, so I dont really NEED to build them do I? Just upload them? SO IF I was building them, where would those files build to, can I not just copy my pre-compiled bins to that directory and try to use the VM for uploading only?
(Again I realise this might be an obvious face palm moment for you guys... but If you dont ask you dont learn)


You can. The binary that make builds & subsequently uploads with openocd is "build/clouds/clouds_bootloader_combo.bin". You could copy another pre-built binary to the VM & instruct openocd to use that instead. It doesn't have to reside in build/clouds, you could copy it to a directory like /tmp for example. Then you'd run openocd using that new path.

But really, if you have an existing binary built on that VM, i'd suggest you stick with that & using "make -f clouds/makefile upload_combo_jtag".
Puzzler
ST-Link, ST-Link/V2, ST-Link/V2-1 USB driver signed for XP, Windows7, Windows8

http://www.st.com/web/en/catalog/tools/PF260219
bennelong.bicyclist
Randomly swapping tools without any good reason and without understanding what you are doing is unlikely to succeed and will just annoy those trying to assist. Use the vagrant environment. As far as I can see from the bits of output you have posted, it has successfully built the binaries. Why do you think it hasn't? Unless you have randomly edited or deleted files in the vagrant VM, it will work.

Stop looking for shorts between the 3v3 rail and ground - it seems you have fixed that. As instructed by others, concentrate on the MCU soldering, and the JTAG connector. Oh, and the crystal and its timing caps. Where are the high resolution photos you said that you took?

Of course, you can also ask the person who sold you the PCBs for support. I mean, it would be unconscionable to sell PCBs without having built one or two of each design oneself in order to understand properly what is involved.
markfrancombe
Unfortunately I KNOW I should have cleaned off the flux before taking these pics, so many of them look messier than they are.
Rather than post here, Im posting links to google photos, hopefully so you can zoom in. The res should be pretty good.

Now SINCE I have taken these, I have done some work on the arm. and sure enough I did spot a few pins that seemed suspect as you can see from these pics, have to say, still hard to say.
I have also cleaned up is the 4 really wonky caps, (one seen in these pics)

Bare in mind it still doesn't work even after a bit of a fix up.

Heres one of the whole thing.
https://drive.google.com/file/d/1KDCi2ye23g871Zu-7lzQEJX0VEoJBlYVDQ/vi ew?usp=sharing

And heres a link to a gallery of various shots of the MCU
https://goo.gl/photos/bCjeULQVHbsHyiRNA


@puzzler Im 99.9999recuring% certain thast what I using... Ill double check, but I think Im ok.

@bennelong.bicyclist. Dont worry I am aware that you think doing VM is the best plan, but as I have the other thing lying on the desk, it takes but 5 seconds to try that way too. I certainly would prefer to go the MI approved way. It just didnt seem too newb friendly from the outside. Most modular musicians (as opposed to module designers) are pretty clever at updating various firmwares of things once in a while. but its only really devs who need to know this stuff backwards, the rest of us are just following recipes.

So.. Il check the JTAG and the Crystal next, but Im sure Ive been over them...
Altitude909
what type of solder was used? That's an unbelievable mess it left
bennelong.bicyclist
markfrancombe wrote:

@bennelong.bicyclist. Dont worry I am aware that you think doing VM is the best plan, but as I have the other thing lying on the desk, it takes but 5 seconds to try that way too. I certainly would prefer to go the MI approved way. It just didnt seem too newb friendly from the outside. Most modular musicians (as opposed to module designers) are pretty clever at updating various firmwares of things once in a while. but its only really devs who need to know this stuff backwards, the rest of us are just following recipes.


So follow the recipe as provided by the designer of the module! If that recipe is beyond you, then so is the module - something which the vendor of the PCBs should have made clear to you.
bennelong.bicyclist
Altitude909 wrote:
what type of solder was used? That's an unbelievable mess it left


Unbelievable mess is an understatement! You did use no-clean solder and no-clean flux, right? If so, you still need to clean it off, using isopropyl alcohol (isopropanol), and a toothbrush (don't let anyone use the toothbrush afterwards). It is impossible to adequately inspect the MPU soldering without cleaning off the flux residue. If you used resin core (or colophony) flux, then oh dear. Get some proper flux cleaning solution and scrub away. Be careful of the pots and switches when you do that. It is best to clean the PCB before mounting the hardware.

That said, from what I can see from the photos, about 30 to 40% of the pins of the MPU aren't adequately soldered, and a few look like they aren't soldered at all. That's why it isn't working.

So, clean the PCB, buy a 10x jeweller's loupe, or an old stereo dissecting microscope, or even just a good 5x hand magnifier if your near vision is good, inspect your soldering of the MPU pins, and fix it up. Each pin (leg) should have a nice shiny joint with the pad, with clearly visible (with magnification) rounded fillets of solder between the leg and the pad. Spend 40 minutes watching the following video and do what he says, for drag soldering: https://www.youtube.com/watch?v=b9FC9fAlfQE
markfrancombe
OK, if you read my post I DID say that it was a mistake taking photos before I had cleaned the board. I only posted them to be honest because someone said "Wheres those pics you said you took"

Look Im having a go at this, I posted many questions on the other, buy thread, about good videos to watch and what solder, what tips, etc.. some of my questions were answered some were not. But everyone said, "Have go, its not too bad". Now, no doubt I made some mistakes, but Im learning, and its fun! 3 years ago I had never done any soldering now I have a pretty ok modular, 80% self built.

I DONT have good solder, but I have the proper flux, I have a couple of ok magnifiers to work with, but not a microscope for really great close up inspection. It al costs money, and the reason I do it this way is because I can maybe get a few MI modules that I COULD NEVER AFFORD!

Much as I am totally appreciative of your help and experience, and want COMPLETE NO HOLDS BARRED critisism of what IM doing, telling me I shuldnt have bothered is like saying, "if you cant do sweep picking, you cant do Heavy Metal"

Love all your help, but please, dont feel you have to if it pisses you off so much!
bennelong.bicyclist
markfrancombe wrote:
Love all your help, but please, dont feel you have to if it pisses you off so much!


You're right. Good luck!
livefreela
mark, based upon my own experiences in the course of my own mi building, a couple of thoughts… to do these projects properly, some specialized tools/supplies are probably in order. if soldering iron/cutter/braid/meter/etc. are considered “cost for entry” in the through-hole diy world, there are a few specialized items that can make life A LOT easier with these smt projects. having formerly been once been in the same spot as you - trust me i’ve mangled more braids boards than i’d care to admit - i finally got around to picking up an optivisor and a cheap hot air station (50 bucks, amazon)m and i couldn’t imagine building these things now without that tandem (along with good flux intended for smd work - lots of it - i use the chip quick gel). without the magnification, you are essentially working blind, and without the hot air, removing ics for trouble shooting whilst leaving traces intact is a dodgy affair at best. here’s what i would do in your situation once i had those tools, though keep in my this is just one rank amateur’s opinion:

- given that your power rails are now in order, use the hot air to desolder the micro controller - apply gel flux to all the pins and apply heat, it will lift right away. re apply flux and clean up the pads with wick. then clean with iso.
-check continuity from the programmer pins to the appropriate mcu pads with your meter to confirm none have been damaged which may be the cause of your difficulty with the programming - probe carefully, you don’t want to bork any of the other 3.3v chips in the circuit. also apply flux to & wick the jtag solder points as well if you’ve used that header - i’ve had lots of shorts with those, the mask can be quite stingy there. if you’re intending to use a serial programmer, it may be worthwhile to leave the jtag header off the board altogether for just that reason.
-if all that checks out, i would swap the micro controller - those stm32s can be pretty hardy, but based on the looks of this thing, yours has sustained quite the beating. you can of course have a whack at re soldering the old one, but with each solder/desolder cycle you’re potentially stressing those pads, so be forewarned.
- the technique i’ve found to work best for the mcu is to first flux & then LIGHTLY tin the mcu pads. clean with iso, then re apply gel flux to the mcu footprint (in case you haven’t yet noticed - flux is KEY). under magnification i then position the chip best i can, this is the most critical step
-i then use the hot air to reflow the chip, just enough to seat the chip properly using the surface tension of the melting solder. this is not our final joint, just a fixative for positioning. i do this in lieu of the “corner anchor” with iron technique others use prior to drag soldering. my vision is shit, my hand steadiness only slightly better, so the less poking about with the iron, the better.
-this should be enough to mechanically fix the chip to the board. now, clean the mcu up a bit with iso and once again re-apply flux before drag soldering - i usually use, washable here, but as you already have pots installed, low residue is probably fine - easy on the solder mate, there’s already some on there from the reflow.
-even if the chip now looks good under magnification, i usually still dab around a bit with fresh flux and wick to draw out any errant solder that may have accumulated underneath the pins, if there are any goblins, they’ll be drawn right out! once again, clean with iso and have a go at flashing the monster…. .

-in the future, i would also reccomend you have the board flashed and running and working before installing pots/jacks/etc - makes troubleshooting a lot easier. i usually leave the mcu/dacs/etc until the passives/regulators are installed so i can power up the board and verify voltages. saves a little coin on burnt up ics for when you invariably have that errant short somewhere wink

hopefully this may be of some help! good luck to you man….
markfrancombe
Hi @livefreela!
EDIT: Jeeezus, sorry for long post...

Quote:
hopefully this may be of some help! good luck to you man….


Thanks for all that advice, I wish Id know some of that before I started, however most of it have have picked up or found out the hard way.

Just to clear some things up, I do have magnification, x5 PLUS Im wearing very close up reading glasses, the combination is just perfect for me.
I have tried with closer, but it didnt help, infact, being able to ONLY see the solder joint out of context from the local area was useless.
Plus I do have a small 10x magnifier that I can use close to eye and get a good close up view. Trouble with that is that i cant get it in there now that I have added the hardware components, whereas my friends camera with macro managed. (Yes was mistake to add the hardware, but i didnt realise I could have flashed the chips without, got wrong advice there)

Im probably not using the perfect solder and flux, but Im happy to get your suggestion, I asked and asked for links a few weeks ago, but no one came thru. But I do have flux, and of course it works wonderfully.

Technique-wise, Im actually do exactly as you describe, basically tinning the pads first, clean, flux add component and reheat one end then another... or dragging on the chips. It works most of the time, sometimes the solder is too much and I have to take some off. It was a technique I saw on a YouTube, but is not apparently the purists way, who would rather feed in solder, from a micro thread of solder. As stated, I don't have the right solder, (too thick, its on order) but this tinning technique fixes that problem and I can control exactly how much to use on each item.
Now how much I need to care that the item is a bit wobbly, I don't know, Ive seen worse on others build shots, but sometimes I have pulled off a perfectly good cap mount, because its a not perfectly aligned.. other time, where Im convinced its actually a good mount, even though it looks a mess, Ive said "fuck it...!"

I don't have a air station, but the guy in the next studio space from me, does micro electronics, and he has one, so if I need to remove the arm, we'll do it there, he also has a microscope, and has checked my work, he is professional and said that the chip was ok, so I believed him, From the photos (Yes that were horribly gunky with flux, almost no point in posting) I did notice 2 places where the legs may not have been touching, but when cleaned up, you can see that every joint IS shiny and nice and the "fillets" of solder are one every single leg (apart from one). If you look at the top photo (and zoom in) you can pretty much see that, if you can try to see past the flux gunk.

https://goo.gl/photos/c9cnrVPG5GYCzTfe9

If you see photo, the area next to C19 and 18 needs some attention and the very first leg on the top left hand side, was not touching. All other legs were fine, and shiny.
Im interested to know from pros though... I tried to keep the amount of solder to a minimum, to not get big blobs, but maybe Ive been a bit TOO careful? would ab it more solder be better?


HOWEVER!!!!
Im afraid I agree with you that the next step is to remove the chip and re-do.

Despite this detour into board fixing, I STILL do not believe the computer side is working as it should. I really would like to verify that this is AOK before trashing the chip. Im in no hurry!

I had to re install the whole VM process onto another machine yesterday, but this time understood a little of what I was doing. Reading a list of instructions on the MI git site, is fine as long as it works as described, but the second something does not go as expected, you cant troubleshoot cos you have not been explained what that step actually was!

So bennelong.bicyclist is correct when he/she said that I had successfully built the code and bootloader, this time I watched as they appeared in the build directory, and this time I knew where to look!
However, its just not connecting to the STLInk to push it to teh chip.

This was the FIRST questions I was coming to this thread about actually, when I was trying to install via the StLink Utility.
Puzzler has confirmed for me that the software should be OK with my ancient laptop, but of courses I cant confirm that the usb ports are all ok, or something else that is as a result of old crap.
Anyway, it gave me clear information that the hardware was not connected. We still suspect that the if the chip aint properly soldered of course I cant connect to it, but, as with all troubleshooting you need to do one thing at a time, and confirm that!
AND NOW, after all that, but this time having build a Vagrent/VM and taught myself command line, and edited makefiles, built binary files myself, even though I already had them from Adams repository, the last part of the terminal message, is exactly the same... cannot connect.
However, the good thing about VM is it gives a little more info, some thing about voltages not being enough. I can see earlier in this thread that was the solution for someone els (different module) but cant find an explanation of it so cant make a comparison.

So heres the whole damn output...
(EDIT, Here I tried to conect to my computer in teh studio to grab the output of the terminal window that I know is sitting there, but surprise surprise, couldnt connect... *sigh*)... later then...

today I cant get to my studio, my cat is sick and must be hand fed every 3 hours, but Ill be having a look at the JTAG socket and caps around the crystal as suggested by Bicycle, and see if I can get some time on the neighbours microscope... If I can get rid of error messages (apart from ones connected to not having a properly connected chip) Ill pull i off and start again... I see that happening actually.
livefreela
ok, didn't see earlier that you were unsure of whether or not the compiling was successful or not - i had a bear of a time getting that toolchain right myself - fortunately olivier's virtual machine has worked a treat thus far. before you mess with the hardware further, lets get that straghtened out. i'm use macs, so symlink is unfamiliar. i was in a similar boat (dubious hardware/dubious toolchain) so to divide and conquer i went the cavalier route and used a factory mi module as the guinea pig figuring that a properly connected programmer couldn't kill anything on the hardware side and knowing i have friends who could bail me out if i bricked the software wink do you have a module you might be able to test your programming environment with for the betterment of science? should you fuck something up, your tech buddy should be able to help you with a restore...
markfrancombe
livefreela wrote:
ok, didn't see earlier that you were unsure of whether or not the compiling was successful or not - i had a bear of a time getting that toolchain right myself - fortunately olivier's virtual machine has worked a treat thus far. before you mess with the hardware further, lets get that straghtened out. i'm use macs, so symlink is unfamiliar. i was in a similar boat (dubious hardware/dubious toolchain) so to divide and conquer i went the cavalier route and used a factory mi module as the guinea pig figuring that a properly connected programmer couldn't kill anything on the hardware side and knowing i have friends who could bail me out if i bricked the software wink do you have a module you might be able to test your programming environment with for the betterment of science? should you fuck something up, your tech buddy should be able to help you with a restore...


The compiling IS SUCCESSFULL, I have built the firmware/bootloader.. its teh upload to chip thats the problem now...

Er... I have a Grids and Anushri... that were not built by me.. but Im a little nervous to plug them into anything to be honest...

Im also on a mac, I just got a super cheap PC for this StLink process (I wasnt totally for that cos I have a few other module that require firmware upgrades,and the wife is sick of me borrowing her PC)

When I next get to the studio Ill post this final error message, Its all about getting a valid connection to the StLink, that seems to be the problem both on VM and STLink Utilities on PC. Maybe I should check the cables... ofter the simplest answer is right (and often the most complicated.. )

It might be that I cant confirm the connection UNTILL I get a working module however... its that World of Warcraft Multi part quest again...
gbiz
There's a suspicious blob of what looks like solder half way along the track from pin 5 of the JTAG to the MCU. I can't see what it is clearly as it's in the shade cast by the adjacent pot, but it looks like it's across the track & onto the adjacent fill.

I'm not sure what flux/solder combination you're using, but i can't see a single solder joint that doesn't look dry to me. It doesn't look like the flux is doing it's job at all. As bennelong.bicyclist says, you really need a nice shiny solder connection. One of the worst is the big tab on the 3.3V regulator. That really needs cleaning out & reflowing with a liberal application of flux first.

There's quite a few of the 0603 components not associated with the MCU that are skew to the point where they might be shorting to the adjacent ground fill. Whilst you're looking at the MCU you probably want to rework those too. (Eg C5, C10, R1, R11, R15, R27, R29 to pick a few).
markfrancombe
gbiz wrote:
There's a suspicious blob of what looks like solder half way along the track from pin 5 of the JTAG to the MCU. I can't see what it is clearly as it's in the shade cast by the adjacent pot, but it looks like it's across the track & onto the adjacent fill.

I'm not sure what flux/solder combination you're using, but i can't see a single solder joint that doesn't look dry to me. It doesn't look like the flux is doing it's job at all. As bennelong.bicyclist says, you really need a nice shiny solder connection. One of the worst is the big tab on the 3.3V regulator. That really needs cleaning out & reflowing with a liberal application of flux first.

There's quite a few of the 0603 components not associated with the MCU that are skew to the point where they might be shorting to the adjacent ground fill. Whilst you're looking at the MCU you probably want to rework those too. (Eg C5, C10, R1, R11, R15, R27, R29 to pick a few).


Ill take a look at all those places... Ill also take new pics after the work I have done (and cleaned properly )and see what you guys think then, maybe it looks Worse in the photos than it really is, It really does look duller ... Or maybe is that bad... Ill let you guys experience be the judge.
Puzzler
There is a bridge from C19 to the leg of the STM32.
And the reason is too much solder on the leg. You have to use flux on that leg and heat it up for a second.
bennelong.bicyclist
There is further, possibly relevant troubleshooting information at https://www.muffwiggler.com/forum/viewtopic.php?p=2012467#2012467
gbiz
Puzzler wrote:
There is a bridge from C19 to the leg of the STM32.


Assuming you mean to the last but one pin on that side of the MCU, that's a track. C19 is connected to pin 47 (VCAP_2).
markfrancombe
Puzzler wrote:
There is a bridge from C19 to the leg of the STM32.
And the reason is too much solder on the leg. You have to use flux on that leg and heat it up for a second.


I was concerned about that one, but I think its actually mean to be there, Eagle confirmed it.
livefreela
another point for the hot air wink when both pads are heated up, the surface tension of the molten solder will usually pull the component properly into place...

oh yeah, and @bannelongbicyclist - i never properly thanked you for helping me get my own issues squared away way back when. so please consider my gratitude hereby extended wink couldn't have gotten these made with out you sir....

markfrancombe wrote:
gbiz wrote:
There's a suspicious blob of what looks like solder half way along the track from pin 5 of the JTAG to the MCU. I can't see what it is clearly as it's in the shade cast by the adjacent pot, but it looks like it's across the track & onto the adjacent fill.

I'm not sure what flux/solder combination you're using, but i can't see a single solder joint that doesn't look dry to me. It doesn't look like the flux is doing it's job at all. As bennelong.bicyclist says, you really need a nice shiny solder connection. One of the worst is the big tab on the 3.3V regulator. That really needs cleaning out & reflowing with a liberal application of flux first.

There's quite a few of the 0603 components not associated with the MCU that are skew to the point where they might be shorting to the adjacent ground fill. Whilst you're looking at the MCU you probably want to rework those too. (Eg C5, C10, R1, R11, R15, R27, R29 to pick a few).


Ill take a look at all those places... Ill also take new pics after the work I have done (and cleaned properly )and see what you guys think then, maybe it looks Worse in the photos than it really is, It really does look duller ... Or maybe is that bad... Ill let you guys experience be the judge.
adam
i don't understand why more people don't use reflow - not having to be as accurate with placement seems like a major plus to me
Altitude909
adam wrote:
i don't understand why more people don't use reflow - not having to be as accurate with placement seems like a major plus to me


huh? Have you tried reflow? Placement is 10x more critical when you do all parts at once, there is 0 room for error. That's what PNP machine are for
adam
but the surface tension pulls the parts into position

Altitude909
try it and let us know how that goes on the fine pitch boards you sell
adam
My friend does bga's in a toaster oven
markfrancombe
Jesus fucking Christ...

er... something happened...
Dont THINK Im quite there but.. not sure.

I cleaned up points suggested by @puzzler
and tried VM upload again...

and this...

vagrant@vagrant-ubuntu-trusty-64:/vagrant/eurorack-modules$ make -f clouds/makefile upload_combo_jtag
cat build/clouds/clouds.d build/clouds/cv_scaler.d build/clouds/resources.d build/clouds/settings.d build/clouds/ui.d build/clouds/adc.d build/clouds/codec.d build/clouds/debug_port.d build/clouds/gate_input.d build/clouds/leds.d build/clouds/switches.d build/clouds/system.d build/clouds/correlator.d build/clouds/granular_processor.d build/clouds/mu_law.d build/clouds/frame_transformation.d build/clouds/phase_vocoder.d build/clouds/stft.d build/clouds/atan.d build/clouds/units.d build/clouds/random.d build/clouds/bootloader_utils.d build/clouds/system_clock.d build/clouds/core_cm3.d build/clouds/system_stm32f4xx.d build/clouds/misc.d build/clouds/stm32f4xx_adc.d build/clouds/stm32f4xx_can.d build/clouds/stm32f4xx_crc.d build/clouds/stm32f4xx_cryp_aes.d build/clouds/stm32f4xx_cryp.d build/clouds/stm32f4xx_cryp_des.d build/clouds/stm32f4xx_cryp_tdes.d build/clouds/stm32f4xx_dac.d build/clouds/stm32f4xx_dbgmcu.d build/clouds/stm32f4xx_dcmi.d build/clouds/stm32f4xx_dma.d build/clouds/stm32f4xx_exti.d build/clouds/stm32f4xx_flash.d build/clouds/stm32f4xx_fsmc.d build/clouds/stm32f4xx_gpio.d build/clouds/stm32f4xx_hash.d build/clouds/stm32f4xx_hash_md5.d build/clouds/stm32f4xx_hash_sha1.d build/clouds/stm32f4xx_i2c.d build/clouds/stm32f4xx_iwdg.d build/clouds/stm32f4xx_pwr.d build/clouds/stm32f4xx_rcc.d build/clouds/stm32f4xx_rng.d build/clouds/stm32f4xx_rtc.d build/clouds/stm32f4xx_sdio.d build/clouds/stm32f4xx_spi.d build/clouds/stm32f4xx_syscfg.d build/clouds/stm32f4xx_tim.d build/clouds/stm32f4xx_usart.d build/clouds/stm32f4xx_wwdg.d build/clouds/startup_stm32f4xx.d > build/clouds/depends.mk
openocd -f stmlib/programming/jtag/interface_stlink-v2.cfg -f stmlib/programming/jtag/stm32f4xx_hla.cfg -f stmlib/programming/jtag/prelude_f4xx.cfg -f stmlib/programming/jtag/erase_f4xx.cfg -c "flash write_bank 0 build/clouds/clouds_bootloader_combo.bin 0x0" -c "verify_image build/clouds/clouds_bootloader_combo.bin" -f stmlib/programming/jtag/postlude.cfg || openocd -f stmlib/programming/jtag/interface_stlink-v2.cfg -f stmlib/programming/jtag/stm32f4xx_hla.cfg -f stmlib/programming/jtag/prelude_f4xx.cfg -f stmlib/programming/jtag/erase_f4xx.cfg -c "flash write_bank 0 build/clouds/clouds_bootloader_combo.bin 0x0" -c "verify_image build/clouds/clouds_bootloader_combo.bin" -f stmlib/programming/jtag/postlude.cfg
Open On-Chip Debugger 0.9.0 (2015-10-12-19:43)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
hla_jtag
adapter speed: 2000 kHz
adapter_nsrst_delay: 100
trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain connect_deassert_srst
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
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 v24 API v2 SWIM v4 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 3.220013
Info : stm32f4xxx.cpu: hardware has 6 breakpoints, 4 watchpoints
target state: halted
target halted due to debug-request, current mode: Handler HardFault
xPSR: 0x00000003 pc: 0x6d746820 msp: 0x3c0a09e8
Info : device id = 0x10076413
Info : flash size = 1024kbytes
stm32x mass erase complete
target state: halted
target halted due to debug-request, current mode: Handler HardFault
xPSR: 0x01000003 pc: 0xfffffffe msp: 0xffffffd8
target state: halted
target halted due to breakpoint, current mode: Handler HardFault
xPSR: 0x61000003 pc: 0x20000042 msp: 0xffffffd8
wrote 168464 bytes from file build/clouds/clouds_bootloader_combo.bin to flash bank 0 at offset 0x00000000 in 5.234300s (31.430 KiB/s)
target state: halted
target halted due to breakpoint, current mode: Handler HardFault
xPSR: 0x61000003 pc: 0x2000002e msp: 0xffffffd8
verified 168464 bytes in 2.362888s (69.625 KiB/s)
shutdown command invoked
vagrant@vagrant-ubuntu-trusty-64:/vagrant/eurorack-modules$


... happened...

was looking good, but then...

target state: halted
target halted due to breakpoint, current mode: Handler HardFault
xPSR: 0x61000003 pc: 0x2000002e msp: 0xffffffd8
verified 168464 bytes in 2.362888s (69.625 KiB/s)
shutdown command invoked

WTF is that?

Mark
gbiz
That just looks like the processor is being halted after the flash write. What happens if you hit the reset button now ?.
markfrancombe
So.. not having any idea how this module should work...
Now I have a red flashing freeze button... if I press mode/time button the LEDS cycle thru one at a time, green... er just the first 3
If I press Load/cycle the LEDS cycle thru 1 to 3 flashing...
No lights on LED 4..

Maybe its time to RTFM?

or.. yikes..

plug it in?

M
markfrancombe
gbiz wrote:
That just looks like the processor is being halted after the flash write. What happens if you hit the reset button now ?.

What are you trying to tell me? That its flashed the chip?
gbiz
Yes w00t
That it's now cycling through the LEDs would also suggest that.
Puzzler
Cant you just restart the Clouds and put some audio input in and hear if something comes out now?

Dont let "Density" in center position for that though. MY ASS IS BLEEDING
markfrancombe
Puzzler wrote:

Dont let "Density" in center position for that though. MY ASS IS BLEEDING


I dont know what THAT means (yet) but yep.. Ill give it a go... Maybe wait to put the panel on tho... that would be just jumping the gun...
markfrancombe
OK, well I guess I should be happy about this step, but not working JUST yet...

Theres no sound if I plug something thru it. I guess the blend knob should be useful here (really must go and RTM) but no sound at all. I tried both inputs both outputs and 1 input going to both outputs.

Also theres obviously something wrong with LED 4, the clicks thru the modes get to 4 but the LED doesnt light.

One weird thing I noticed is that AS I plug in the audio out (with an audio in already plugged in) the thru sound (from the sound source) pops in WHEN THE CENTER of the jack PLUG hits the sleeve of the jack SOCKET in the way in, in other words, when the output touches ground... Im guessing thats not normal right?

Looking like theres something happening with ground?

Mark
bennelong.bicyclist
adam wrote:
i don't understand why more people don't use reflow - not having to be as accurate with placement seems like a major plus to me


Show us some photos of some of the Mutable boards which you sell which you have soldered using a reflow oven and paste applied by hand.

Or do you sell paste stencils as well?
gbiz
markfrancombe wrote:
OK, well I guess I should be happy about this step, but not working JUST yet...

Theres no sound if I plug something thru it. I guess the blend knob should be useful here (really must go and RTM) but no sound at all. I tried both inputs both outputs and 1 input going to both outputs.

Also theres obviously something wrong with LED 4, the clicks thru the modes get to 4 but the LED doesnt light.

One weird thing I noticed is that AS I plug in the audio out (with an audio in already plugged in) the thru sound (from the sound source) pops in WHEN THE CENTER of the jack PLUG hits the sleeve of the jack SOCKET in the way in, in other words, when the output touches ground... Im guessing thats not normal right?

Looking like theres something happening with ground?

Mark


LED4 not working should be easy enough to diagnose. That's only 2 resistors, 2 pins of the 595 & the LED itself. Does it light red if you cycle through the audio quality settings ?.

With an audio signal being fed into Clouds, with the gain pot up, do the other LEDs show the signal level meter ?. That at least will give you an idea if the signal is getting through to the codec & the codec is working.

When you adjust the blend pot, does the LED associated with the current blend parameter change colour ?.

You're right, a quick read through the manual is a good idea now to get an idea of what does what.
magneticstripper
i am having an issue with a Clouds module. the wet/dry blend seems
to be going back up towards dry at the end of its rotation. anybody seen this, or have an idea where i should look for problems? on a
side note, this Clouds, was working fine. is there any way a shot cap
could produce this behavior?
aristote
aristote wrote:
Hi there ! I'm trying to setup the VM toolchain, on a stlink-v2 STM32F4 discovery board. I know it's not gonna be really useful but it's just to be sure that any fail is not hardware related.

i managed to compile the hex and bin version or the Braids firmware but the upload part fails. (Using the windows tool to push the firmware is ok).
i've double check that there's no space at the end of lines.

I've got the same error. see bellow :
Quote:

vagrant@vagrant-ubuntu-trusty-64:/vagrant/eurorack-modules$ make -f braids/makefile upload_combo_jtag
openocd -f stmlib/programming/jtag/interface_stlink-v2.cfg -f stmlib/programming/jtag/stm32f10x_hla.cfg -f stmlib/programming/jtag/prelude_f10x.cfg -f stmlib/programming/jtag/erase_f10x.cfg -c "flash write_bank 0 build/braids/braids_bootloader_combo.bin 0x0" -c "verify_image build/braids/braids_bootloader_combo.bin" -f stmlib/programming/jtag/postlude.cfg || openocd -f stmlib/programming/jtag/interface_stlink-v2.cfg -f stmlib/programming/jtag/stm32f10x_hla.cfg -f stmlib/programming/jtag/prelude_f10x.cfg -f stmlib/programming/jtag/erase_f10x.cfg -c "flash write_bank 0 build/braids/braids_bootloader_combo.bin 0x0" -c "verify_image build/braids/braids_bootloader_combo.bin" -f stmlib/programming/jtag/postlude.cfg
Open On-Chip Debugger 0.9.0 (2015-10-05-09:24)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
hla_jtag
adapter speed: 1000 kHz
adapter_nsrst_delay: 200
trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain connect_deassert_srst
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
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 v14 API v2 SWIM v0 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 2.909911
Error: init mode failed (unable to connect to the target)
in procedure 'init' called at file "stmlib/programming/jtag/prelude_f10x.cfg", line 23
in procedure 'ocd_bouncer'


i also tried using "make -f braids/makefile upload" with the same error output.
Quote:

vagrant@vagrant-ubuntu-trusty-64:/vagrant/eurorack-modules$ make -f braids/makefile upload
openocd -f stmlib/programming/jtag/interface_stlink-v2.cfg -f stmlib/programming/jtag/stm32f10x_hla.cfg -f stmlib/programming/jtag/prelude_f10x.cfg -f stmlib/programming/jtag/erase_f10x.cfg -c "flash write_bank 0 build/braids/braids_bootloader_combo.bin 0x0" -c "verify_image build/braids/braids_bootloader_combo.bin" -f stmlib/programming/jtag/postlude.cfg || openocd -f stmlib/programming/jtag/interface_stlink-v2.cfg -f stmlib/programming/jtag/stm32f10x_hla.cfg -f stmlib/programming/jtag/prelude_f10x.cfg -f stmlib/programming/jtag/erase_f10x.cfg -c "flash write_bank 0 build/braids/braids_bootloader_combo.bin 0x0" -c "verify_image build/braids/braids_bootloader_combo.bin" -f stmlib/programming/jtag/postlude.cfg
Open On-Chip Debugger 0.9.0 (2015-10-05-09:24)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
hla_jtag
adapter speed: 1000 kHz
adapter_nsrst_delay: 200
trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain connect_deassert_srst
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
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 v14 API v2 SWIM v0 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 2.909911
Error: init mode failed (unable to connect to the target)
in procedure 'init' called at file "stmlib/programming/jtag/prelude_f10x.cfg", line 23
in procedure 'ocd_bouncer'


here is the content of the ./stmlib/makefile.inc

Quote:
# ---------------------------------------------------------------------- --------
# Files and directories
# ---------------------------------------------------------------------- --------

TOOLCHAIN_PATH ?= /usr/local/arm/

# Supported: arm-usb-ocd, arm-usb-ocd-h, arm-usb-tiny-h, stlink-v2
PGM_INTERFACE ?= stlink-v2
# hla for stlink-v2 ; jtag otherwise
PGM_INTERFACE_TYPE ?= hla

PGM_SERIAL_PORT ?= /dev/ftdi-usbserial
PGM_SERIAL_BAUD_RATE ?= 115200
PGM_SERIAL_VERIFY ?= -v


Moreover on the discovery board the two jumpers are setup to be on the discovery mode (internal chip) and not the stink (external chip). I've checked this with the windows ST tool. When the jumpers are ON, i can upload the firmware, when the jumper are OFF, i can't upload because i didn't plug any external chip.

Any help would be appreciated smile


Fixed my problem when working on the real hardware with stink v2 smile 2 DIY braids born today !
mxmxmx
aristote wrote:


Fixed my problem when working on the real hardware with stink v2 :) 2 DIY braids born today !


unsurprising ... your discovery board is STMF4xx, braids is STMF103. you can't just download the braids stuff to anything, using the same commands.
markfrancombe
gbiz wrote:

LED4 not working should be easy enough to diagnose. That's only 2 resistors, 2 pins of the 595 & the LED itself.


Ill check them in a minute
gbiz wrote:

Does it light red if you cycle through the audio quality settings ?.

No, on boot up first all LEDS light, the first 3 are orange, but the suspicious number 4 is red, then after 2 seconds it too turns red. Then they all turn off. I assume this is the booting routine.
Then I long press the MODE button, to enter quality mode, a quick press on the same button, DOES cycle thru all 4, BUT when it gets to 4 the LED is off... but there is a gap where 4 should be, then it cycles back to 1.


gbiz wrote:

With an audio signal being fed into Clouds, with the gain pot up, do the other LEDs show the signal level meter ?. That at least will give you an idea if the signal is getting through to the codec & the codec is working.

The manual doesnt say how to get back to normal mode after being in audio quality select mode... long press doesnt seem to work, and just waiting doesnt either.
I re-booted instead, and no, audio level does NOT light up any LEDs, even if GAIN level is up. :(

gbiz wrote:

When you adjust the blend pot, does the LED associated with the current blend parameter change colour ?.

Again.. no :( :(

gbiz wrote:

You're right, a quick read through the manual is a good idea now to get an idea of what does what.


Yep, as you can see I am... it helps...
Ill check those places you suggest and the codec chip, and I guess... around the pots, it would be just like me to fuck up the big and easy soldering...

cheers for your continued help gbiz, appreciated!
markfrancombe
markfrancombe wrote:
gbiz wrote:

LED4 not working should be easy enough to diagnose. That's only 2 resistors, 2 pins of the 595 & the LED itself.


Ill check them in a minute


OK I checked all those... and tried again. There is a change, Now, after boot routine (no change number 4 is red the others are orange) the 4th LED is VERY faintly ON (When it should be off) When I long press MODE, and cycle thru, Number 4 DOES now light up when it should but IT FLICKERS, faintly...

Re-do again I guess, Im surprised about the intermitant operation however, I would expect a short/bad joint to cause ON or OFF behavior, what can cause a flicker...? Very LOW voltage at that LED?

Mark
gbiz
markfrancombe wrote:
markfrancombe wrote:
gbiz wrote:

LED4 not working should be easy enough to diagnose. That's only 2 resistors, 2 pins of the 595 & the LED itself.


Ill check them in a minute


OK I checked all those... and tried again. There is a change, Now, after boot routine (no change number 4 is red the others are orange) the 4th LED is VERY faintly ON (When it should be off) When I long press MODE, and cycle thru, Number 4 DOES now light up when it should but IT FLICKERS, faintly...

Re-do again I guess, Im surprised about the intermitant operation however, I would expect a short/bad joint to cause ON or OFF behavior, what can cause a flicker...? Very LOW voltage at that LED?

Mark


The LEDs are driven using PWM. The width of the pulse sets the intensity of the green & red elements, which allows them to transition from green through yellow & orange to red. So they're actually flickering all the time they're lit, just the flickering is too fast for the eye to register.

Faint LED could be a very short pulse driving the LED, or low voltage. Could be a bad solder joint, damaged 595, wrong resistor value. Hard to say without putting a scope on there & seeing whats going on.

Does it do that for both the red & green elements in that LED ?.

What you should be seeing ...
If you hit reset, the LEDs should cycle through from 1 to 4 three times. Then they'll go out.
If you then repeatedly briefly tap the mode button to go through the blend modes, they should cycle through from 1 through 4 with each tap, lit green. Stop tapping the mode button & the last LED will stay green for about 5 secs, then all are blanked. If you then turn the blend knob, the mode that's currently selected should transistion from blank, through green then yellow, orange to red.
Hold the mode button down for a couple of secs, that will enter quality mode. The current quality mode LED will light red. Tap the mode button will cycle through the quality modes. The LED will be red. Leave the mode button off for a few seconds & the LED will blank.
Hold the mode button down for a bit longer than quality mode, it'll briefly light the current quality mode LED as red, keep the button down & it'll change to select the effect mode, the LED will be yellow. Tap the mode button will cycle through the LEDs in yellow. Again, leave the mode button off for a few seconds & the LED will blank.

In normal operation, with audio going into the unit, the LEDs will act as a level indicator.
markfrancombe
gbiz wrote:
damaged 595, wrong resistor value. Hard to say without putting a scope on there & seeing whats going on.


Serious question, is it possible that ONE bit of the 595 may be faulty, if the other LEDS are using other parts of the package?
Of course the damage mght be .. a leg, but normally if a chip is broken, its broken.. or am I wrong?
Any way I could test?

<rambling>
Resister values I can roughly probe... I know I know may be wrong due to parallel other resisters.. but maybe I get an idea... LEDS I would normally check with a continuity tester (beepy thing on multi) but this LED has 3 legs... not sure which to probe.. never mind Ill look for data sheet...
</rambling>

gbiz wrote:

Does it do that for both the red & green elements in that LED ?.


What do you mean? I HAVE seen both colours from that LED. During boot up its RED (when the others are a kind of orange colour) and when I step thru the quality settings its this flickering green colour...

Thanks so much for the detailed explanation of what the colour schemes SHOULD be, that really helpful.

After checking the items around that LED, it did improve as I said, can it be that some fault in the other LED circuits can contribute to that.

And Incidentally, I thought I had a "aha" moment yesterday when I discovered that one side of C13 was loose. Those electro caps have very little pad space. So I fixed that but nothing changed... Im just following the tracks in eagle from audio in.-.. that allI know how to do, you also mentioned the codec chip and I checked around that... theres one wonky cap Ill fix up today, but the chip looked ok to me. But then again what do I know, Ive already been ripped to shreds here for my drunken soldering...

<rambling>
Anyway, It wouldnt be fun if it worked first time, and at least Im making progress and learning new things every day! I mean yesterday I went out for a beer with a friend, flew his drone down the river in Oslo, got my Google Cardboard game to build successfully from XCode, bought my first ever OKish digital camera, and ... made some lights work a bit on Clouds... all in all a pretty good day!
</rambling>

Thanks

MArk
gbiz
markfrancombe wrote:
gbiz wrote:
damaged 595, wrong resistor value. Hard to say without putting a scope on there & seeing whats going on.


Serious question, is it possible that ONE bit of the 595 may be faulty, if the other LEDS are using other parts of the package?
Of course the damage mght be .. a leg, but normally if a chip is broken, its broken.. or am I wrong?


Yes it could be just one part of the chip.

markfrancombe wrote:

Any way I could test?


Nothing that doesn't involve using a scope.

markfrancombe wrote:

Resister values I can roughly probe... I know I know may be wrong due to parallel other resisters.. but maybe I get an idea... LEDS I would normally check with a continuity tester (beepy thing on multi) but this LED has 3 legs... not sure which to probe.. never mind Ill look for data sheet...


Those LEDs are just 2 individual LEDs back to back with their cathodes connected to a common pin (the middle one). So you can test them in exactly the same way as you would for a single LED. The negative side of your tester on the centre leg & the positive side of your tester on either of the outer pins.

markfrancombe wrote:

gbiz wrote:

Does it do that for both the red & green elements in that LED ?.


What do you mean? I HAVE seen both colours from that LED. During boot up its RED (when the others are a kind of orange colour) and when I step thru the quality settings its this flickering green colour...


Thats what i was after. So it's the green that's faulty. That narrows it down to p1 of the 595, R8 or the LED.
markfrancombe
gbiz wrote:
That narrows it down to p1 of the 595, R8 or the LED.


Dont you mean R10? R8 is conected to LED3 no LED4 Its LED4 I have the problem with.

GRRRR!!!
Backwards step!!!
Turned it on now to check your LED sequence after reset. and now its not working again...
All I did since was reconnect the electro that was loose and reflow the resisters around that LED...
Its like the arm never got written! Can it somehow get UN-written, should I try to upload once more?

EDIT: Wait.. it did boot up once now, all lights on... but then stopped and I cannot step thru the modes like I used to..

AND NOW; It wont boot again... What happens is that the second I apply power, all LEDS light briefly and then go off... happening everytime now...

M
BARE BONES
so, I was given this advice on one thread or another about my mostly working Braids (the module plays but I can't update the firmware via the fm input and some of the knobs only work up to 12 o'clock

All the CV & pots share 2 IC's, IC7 & IC8. As none of the pot/CVs inputs are are working it's likely to be something common to all.

Check you have +12V on pin 4 and -12V on pin 11 of both. If you don't, check the orientation of the 2 diodes D1 & D3 (IIRC you asked about those a couple of weeks ago). The line on the diode should point downwards on both.

Turn the colour pot, R37, & check you have a swing between +12V & -12V.
Turn R37 again & check the output of pin 8 of IC8 changes, though note it'll be inverted & attenuated.
Turn R37 again & check the output of pin 8 IC 7 changes in the same direction as the pot.





Fine tune is part of the same circuitry as FM, so if the FM pot & input are working then the only things it can be are either the the pot itself or R50.

Check you have +12V & -12V on the outer 2 pins of the pot & the middle pin swings between these as you adjust the pot. Check you get the same swing on R50 at it's terminal nearest the jacks. It's other terminal should be at virtual ground, 0V. R50 is 10M so you're unlikely to be able to reliably check it's value in-circuit with a meter.

My money's on the soldering on R50. I'd start by checking the soldering on that. (A fellow wiggler had an identical issue with his coarse pot & that was the soldering on that's equivalent resistor).




I used my mm to take readings form the outside legs of the pots
fine -12 +12
coarse 0 +12
fm 0 0
timbre 0 +12
mod 0 0
colour 0 +12

these readings make sense as to why the pots only work half way but the FM pot does have an effect yet I get no reading from it

r50 terminal nearest the jacks -12 no swing when adjusting the pot

ic7 voltage +3v pin 4 & -1v pin 11
ic8 voltages +12v pin 4 & -12v pin 11

so ic7 is not getting the right voltages and this is probably the cause of all the issues but I can't figure out why it's not getting the correct voltages. The diodes are all the correct orientation.
My knowledge has run its course can anyone advise me, thanks in advance smile
gbiz
markfrancombe wrote:
gbiz wrote:
That narrows it down to p1 of the 595, R8 or the LED.


Dont you mean R10? R8 is conected to LED3 no LED4 Its LED4 I have the problem with.

GRRRR!!!
Backwards step!!!
Turned it on now to check your LED sequence after reset. and now its not working again...
All I did since was reconnect the electro that was loose and reflow the resisters around that LED...
Its like the arm never got written! Can it somehow get UN-written, should I try to upload once more?

EDIT: Wait.. it did boot up once now, all lights on... but then stopped and I cannot step thru the modes like I used to..

AND NOW; It wont boot again... What happens is that the second I apply power, all LEDS light briefly and then go off... happening everytime now...


Actually, it's R9 for the green side of LED4. Sorry. (R10 is the red side).

It shouldn't need reflashing. All that would do is indicate that the MCU & associated components are OK.
Puzzler
Strange issue with a clouds.
Its working all fine.
But as soon as you access the "Reverberation amount" mode, a periodically and quiet noise starts.
Then ( still in "Reverberation amount" mode ) if you turn the "Blend-Knob" full CW the volume of the noise increases drastically, supposedly cause of the reverberation.

After this noise started, you can hear it in every mode as well..

Whats the issue?

Broken chip?
Broken op amps?
Broken crystal?
Broken codec?

zombie
adam
are you using the same firmware revision you've used before?
Puzzler
yes, everything is identical to the other builds i made. i installed the firmware new several times on this module, but no difference. i suspect a component to be broken. all the soldering parts look good to very good.
adam
change the cheapest one first then i guess wink

i wonder if it's something like too large (or too small) a feedback resistor on an op amp making noise that gets amplified by the reverb?

i guess a scope might show if it's there all the time
jackmattson
I built a shelves and first time I plugged it in D2 blew. I was using through hole 150ks if that matters. I could not tell if D2 was in backwards because it was so fried.
I replaced D2 and the 150ks (with SMDs) but now I get no sound and no LED light.

Built a few sucessful MI boards. This is my first issue. Any help appreciated. (It's not the power chord or wrong way)



Would you know if a (electrolytic cap) blew?
Puzzler
I forgot to mention something:

The noise sound occurs even if only an output cable is connected.
So no input or cv at all.
adam
The cap would either have white stuff leaking from it or the top would have blown off
adam
Puzzler wrote:
I forgot to mention something:

The noise sound occurs even if only an output cable is connected.
So no input or cv at all.

I wondered if it was op amp noise?
jackmattson
adam wrote:
The cap would either have white stuff leaking from it or the top would have blown off


And the smaller guys?

... to the point, how do I go about doing my first probing expedition? It's a new skill I need to learn. Have Multimeter can get oscilloscope. (Don't have bench power supply.)
adam
First up is equip yourself with some bratwurst and bribe an engineer wink

You can use a module tester as bench supply - as long as the power side is OK you can plug modules into it

D2 blowing sounds like too much power going the wrong way - that's the part you need to solve, have you looked at the schematic?

Edit ,or it may be too much current in the forward direction
Altitude909
jackmattson wrote:
adam wrote:
The cap would either have white stuff leaking from it or the top would have blown off


And the smaller guys?

... to the point, how do I go about doing my first probing expedition? It's a new skill I need to learn. Have Multimeter can get oscilloscope. (Don't have bench power supply.)


hate to be the bearer of bad news but all your ICs are upside down. All the 2164s are toast. They should be like this

jackmattson
Altitude. that's actually good news. Much easier to fix than finding one bad cap somewhere (for me at least). I bought surplus so no waiting.

I do always get confused by orientation though... the brb has the text facing the way I did it. I see the line on the left ... just confusing that the eagle file has different markings than the physical IC chips. Wish they both had a dot.

Bad news is I think I have two tides and a braids ready to flash that I probably did the same.

Any tips on how to figure out how to orient a chip... eg. on the brb with a line which is Pin 1? That I can maybe look up on a data sheet.

...
Come to think of it, I thought I checked the opamps orientation against the way I oriented them according to the line in my clouds though.
Altitude909
The rule is that where ever marking is, whether it be a dot, line, taper whatever, pin 1 is the upper left corner to that marking so if its a line on the short side, that's the top of the chip, if its a taper on the long side, that is the left side of the chip. Dont ever go by text direction, think about it: How is someone in asia suppose to figure out what the right direction is when they read top to bottom and right to left. Always go by the marking, that's what its there for.
jackmattson
Altitude909 wrote:
The rule is that where ever marking is, whether it be a dot, line, taper whatever, pin 1 is the upper left corner to that marking so if its a line on the short side, that's the top of the chip, if its a taper on the long side, that is the left side of the chip. Dont ever go by text direction, think about it: How is someone in asia suppose to figure out what the right direction is when they read top to bottom and right to left. Always go by the marking, that's what its there for.


I don't get it. If the stripe on Eagle is on the left then the pin 1 is on the top left? If the stripe is on the left of the chip (sometimes it's on the short side sometimes it's on a long side?! cry ) then?

On my board and on the brb both the texts are written so that the top of the characters are on the jack heavy side.


Sorry I washed most writing beyond readability away with my poor cleaning.
Altitude909
jackmattson wrote:


I don't get it. If the stripe on Eagle is on the left then the pin 1 is on the top left?


Yes. Always without exception.

Quote:
If the stripe is on the left of the chip (sometimes it's on the short side sometimes it's on a long side?! cry ) then?
if it is on the the side with pins that is the left side of the chip, if it is on the side without pins that is the top of the chip. Based on either of those cases, you can located the upper left pin. Also, keep in mind that the stripe can be a taper on the chip housing as well, when in doubt, there will always be a note about it in the spec sheet

Quote:
On my board and on the brb both the texts are written so that the top of the characters are on the jack heavy side.


I'm not sure what you mean by this, the text on the board is in no way associated with the orientation of the chip. It can go in any direction the designer sees fit and never is an indication of how the chip should be placed, that is always determined by the dot or line
Puzzler
Scope says its there all the time, but quiet if not reverberated.

So its not about the mode, theres a noise in my module cry
The noise has the full spectre and cannot be manipulated with the knobs. If you akso want to enjoy the sound:

https://soundcloud.com/antischocken/cloudsnoize MY ASS IS BLEEDING
(sorry forgot to mono it)

Changed one of the LME49720 dual op-amp. No difference.
adam
i wondered if it was hanging around in the buffer if you can hear it after you leave reverb mode, i guess it's pulsing quality might give a clue - something oscillating?
markfrancombe
Im just gonna bump this last sentence from my previous post.

Quote:
AND NOW; It wont boot again... What happens is that the second I apply power, all LEDS light briefly and then go off... happening everytime now...


So even tho I had it nearly working, at least I could confirm that some software was happening on the MCU, now it aint...

So what does this mean, when a power on, briefly flashes all the LEDs then off again?
Puzzler
adam wrote:
i guess it's pulsing quality might give a clue - something oscillating?


i thin reverberation just makes it very loud.

maybe the crystal is broken?!
adam
i have no idea

if it was the crystal the mcu would be running in a strange way too i think?
markfrancombe
Gave up on clouds for a bit, till I can get hold od a friends heater thingy to start the process of removing things... but had a go at flashing Braids,

Got this error (After it spewed alot of hopefull looking stuff)
make: *** No rule to make target `build/braids_bootloader/braids_bootloader.hex', needed by `build/braids/braids_bootloader_combo.bin'. Stop.

Incidentely, no green light on the StLink this time, when I flashed Clouds, the process ended with a happy green light, now I just get a sad red...

Looking up No rule to make target on google seems to suggest that it cant find the target, and that its normally an error in the makefile, well as this is the same as when it DID work, Im not sure thats the solution...
gbiz
Mark, that error string is no help at all. As with Clouds, we need you tell us what you typed to get it, & what else you'd typed beforehand. Any files you'd edited etc.
BARE BONES
Mark have you tried uploading the prebuilt firmwares via the st link?
jackmattson
screaming goo yo SlayerBadger!
Thanks Altitude for your help! Guinness ftw!
Shelves is on the successful build list now. smile

And I learned something about IC orientation.

Hot air pen at work saved the day!
bennelong.bicyclist
markfrancombe wrote:
Gave up on clouds for a bit, till I can get hold od a friends heater thingy to start the process of removing things... but had a go at flashing Braids,

Got this error (After it spewed alot of hopefull looking stuff)
make: *** No rule to make target `build/braids_bootloader/braids_bootloader.hex', needed by `build/braids/braids_bootloader_combo.bin'. Stop.

Incidentely, no green light on the StLink this time, when I flashed Clouds, the process ended with a happy green light, now I just get a sad red...

Looking up No rule to make target on google seems to suggest that it cant find the target, and that its normally an error in the makefile, well as this is the same as when it DID work, Im not sure thats the solution...


If you don't tell us what you did, then it is a bit hard to tell you what you did wrong...

Show us exactly what commands you issued.
markfrancombe
Ok Sorry, i was just wondering if that specific error message was a regular occurance. Not at My machine right now so cant post the whole shebang, but all i can say is that i followed the exact same routine as I did for Clouds, except for replacing clouds with braids In the make commands.
As far as I know there is no need for me to edit the makefile again as that is a one time thing, not quite sure what it does but im assuming setting the output as a stlink ... Sure it seems relevant but i checked it and it was the same as before. As bicycle posted kindly for me above.
Ill post the whole thing tomorrow.
Thanks for your time.
bennelong.bicyclist
markfrancombe wrote:
Ok Sorry, i was just wondering if that specific error message was a regular occurrence.


Whether such error messages occur regularly depends a lot on who is between the chair and the keyboard...

markfrancombe wrote:

Not at My machine right now so cant post the whole shebang, but all i can say is that i followed the exact same routine as I did for Clouds, except for replacing clouds with braids In the make commands.


Did you, by any chance, omit this command?

make -f braids/bootloader/makefile hex
markfrancombe
bennelong.bicyclist wrote:

Whether such error messages occur regularly depends a lot on who is between the chair and the keyboard...

Hilarious!
bennelong.bicyclist wrote:

Did you, by any chance, omit this command?

make -f braids/bootloader/makefile hex


Yes, I think I missed out the word hex.
I do remember doing it last time, so I'll check my notes, see if I forgot it there.

Thanks!!!

So, You did have all the info needed from my post!
markfrancombe
OK After doing:
make -f braids/bootloader/makefile hex
I cant say if it really worked, but certainly a directory /braids_bootloader appeared in the builds directory. Which included (among many other .o files a .hex file an .elf file and a map file. I did the same with:
-f braids/makefile hex and got the same result.
Im concerned (with out hopfully being reamed out for not posting the whole damn thing) that the first line in the terminal was
stmlib/makefile.inc:313: build/clouds_bootloader/depends.mk: No such file or directory

But IM assuming that it then created that directory as its there now.. er... right?

Anyway, on to the main show.
Then I tried to upload, using:
make -f braids/makefile upload_combo_jtag

This happened: (Im sorry about this but... well you asked)
smile
So especially check out the bottom of this.. lots of JTAG error stuff...
I have to say that when I did clouds (I thnk successfully) I was getting some green light feedback on the StLink, this time nothing till right the end, as it spewed out those errors did it flicker a bit green...

Quote:
vagrant@vagrant-ubuntu-trusty-64:/vagrant/eurorack-modules$ make -f braids/makefile upload_combo_jtag
stmlib/makefile.inc:313: build/braids/depends.mk: No such file or directory
/usr/local/arm-4.8.3/bin/arm-none-eabi-g++ -MM -g -O2 -Wall -Werror -Wno-unused-local-typedefs -fasm -finline -finline-functions-called-once -fdata-sections -ffunction-sections -fshort-enums -fno-move-loop-invariants -I. -DGCC_ARMCM3 -DSTM32F10X_MD -DAPPLICATION -DF_CPU=72000000L -DF_CRYSTAL=8000000L -DUSE_STDPERIPH_DRIVER -DSYSCLK_FREQ_72MHz=72000000L -Istmlib/third_party/STM -Istmlib/third_party/STM/CMSIS/CM3_f10x -Istmlib/third_party/STM/CMSIS/CM3_f10x/startup/gcc -Istmlib/third_party/STM/STM32F10x_StdPeriph_Driver/inc -mcpu=cortex-m3 -mthumb -fno-unroll-loops -fno-exceptions -fno-rtti braids/analog_oscillator.cc -MF build/braids/analog_oscillator.d -MT build/braids/analog_oscillator.o
/usr/local/arm-4.8.3/bin/arm-none-eabi-g++ -MM -g -O2 -Wall -Werror -Wno-unused-local-typedefs -fasm -finline -finline-functions-called-once -fdata-sections -ffunction-sections -fshort-enums -fno-move-loop-invariants -I. -DGCC_ARMCM3 -DSTM32F10X_MD -DAPPLICATION -DF_CPU=72000000L -DF_CRYSTAL=8000000L -DUSE_STDPERIPH_DRIVER -DSYSCLK_FREQ_72MHz=72000000L -Istmlib/third_party/STM -Istmlib/third_party/STM/CMSIS/CM3_f10x -Istmlib/third_party/STM/CMSIS/CM3_f10x/startup/gcc -Istmlib/third_party/STM/STM32F10x_StdPeriph_Driver/inc -mcpu=cortex-m3 -mthumb -fno-unroll-loops -fno-exceptions -fno-rtti braids/braids.cc -MF build/braids/braids.d -MT build/braids/braids.o
/usr/local/arm-4.8.3/bin/arm-none-eabi-g++ -MM -g -O2 -Wall -Werror -Wno-unused-local-typedefs -fasm -finline -finline-functions-called-once -fdata-sections -ffunction-sections -fshort-enums -fno-move-loop-invariants -I. -DGCC_ARMCM3 -DSTM32F10X_MD -DAPPLICATION -DF_CPU=72000000L -DF_CRYSTAL=8000000L -DUSE_STDPERIPH_DRIVER -DSYSCLK_FREQ_72MHz=72000000L -Istmlib/third_party/STM -Istmlib/third_party/STM/CMSIS/CM3_f10x -Istmlib/third_party/STM/CMSIS/CM3_f10x/startup/gcc -Istmlib/third_party/STM/STM32F10x_StdPeriph_Driver/inc -mcpu=cortex-m3 -mthumb -fno-unroll-loops -fno-exceptions -fno-rtti braids/digital_oscillator.cc -MF build/braids/digital_oscillator.d -MT build/braids/digital_oscillator.o
/usr/local/arm-4.8.3/bin/arm-none-eabi-g++ -MM -g -O2 -Wall -Werror -Wno-unused-local-typedefs -fasm -finline -finline-functions-called-once -fdata-sections -ffunction-sections -fshort-enums -fno-move-loop-invariants -I. -DGCC_ARMCM3 -DSTM32F10X_MD -DAPPLICATION -DF_CPU=72000000L -DF_CRYSTAL=8000000L -DUSE_STDPERIPH_DRIVER -DSYSCLK_FREQ_72MHz=72000000L -Istmlib/third_party/STM -Istmlib/third_party/STM/CMSIS/CM3_f10x -Istmlib/third_party/STM/CMSIS/CM3_f10x/startup/gcc -Istmlib/third_party/STM/STM32F10x_StdPeriph_Driver/inc -mcpu=cortex-m3 -mthumb -fno-unroll-loops -fno-exceptions -fno-rtti braids/macro_oscillator.cc -MF build/braids/macro_oscillator.d -MT build/braids/macro_oscillator.o
/usr/local/arm-4.8.3/bin/arm-none-eabi-g++ -MM -g -O2 -Wall -Werror -Wno-unused-local-typedefs -fasm -finline -finline-functions-called-once -fdata-sections -ffunction-sections -fshort-enums -fno-move-loop-invariants -I. -DGCC_ARMCM3 -DSTM32F10X_MD -DAPPLICATION -DF_CPU=72000000L -DF_CRYSTAL=8000000L -DUSE_STDPERIPH_DRIVER -DSYSCLK_FREQ_72MHz=72000000L -Istmlib/third_party/STM -Istmlib/third_party/STM/CMSIS/CM3_f10x -Istmlib/third_party/STM/CMSIS/CM3_f10x/startup/gcc -Istmlib/third_party/STM/STM32F10x_StdPeriph_Driver/inc -mcpu=cortex-m3 -mthumb -fno-unroll-loops -fno-exceptions -fno-rtti braids/quantizer.cc -MF build/braids/quantizer.d -MT build/braids/quantizer.o
/usr/local/arm-4.8.3/bin/arm-none-eabi-g++ -MM -g -O2 -Wall -Werror -Wno-unused-local-typedefs -fasm -finline -finline-functions-called-once -fdata-sections -ffunction-sections -fshort-enums -fno-move-loop-invariants -I. -DGCC_ARMCM3 -DSTM32F10X_MD -DAPPLICATION -DF_CPU=72000000L -DF_CRYSTAL=8000000L -DUSE_STDPERIPH_DRIVER -DSYSCLK_FREQ_72MHz=72000000L -Istmlib/third_party/STM -Istmlib/third_party/STM/CMSIS/CM3_f10x -Istmlib/third_party/STM/CMSIS/CM3_f10x/startup/gcc -Istmlib/third_party/STM/STM32F10x_StdPeriph_Driver/inc -mcpu=cortex-m3 -mthumb -fno-unroll-loops -fno-exceptions -fno-rtti braids/resources.cc -MF build/braids/resources.d -MT build/braids/resources.o
/usr/local/arm-4.8.3/bin/arm-none-eabi-g++ -MM -g -O2 -Wall -Werror -Wno-unused-local-typedefs -fasm -finline -finline-functions-called-once -fdata-sections -ffunction-sections -fshort-enums -fno-move-loop-invariants -I. -DGCC_ARMCM3 -DSTM32F10X_MD -DAPPLICATION -DF_CPU=72000000L -DF_CRYSTAL=8000000L -DUSE_STDPERIPH_DRIVER -DSYSCLK_FREQ_72MHz=72000000L -Istmlib/third_party/STM -Istmlib/third_party/STM/CMSIS/CM3_f10x -Istmlib/third_party/STM/CMSIS/CM3_f10x/startup/gcc -Istmlib/third_party/STM/STM32F10x_StdPeriph_Driver/inc -mcpu=cortex-m3 -mthumb -fno-unroll-loops -fno-exceptions -fno-rtti braids/settings.cc -MF build/braids/settings.d -MT build/braids/settings.o
/usr/local/arm-4.8.3/bin/arm-none-eabi-g++ -MM -g -O2 -Wall -Werror -Wno-unused-local-typedefs -fasm -finline -finline-functions-called-once -fdata-sections -ffunction-sections -fshort-enums -fno-move-loop-invariants -I. -DGCC_ARMCM3 -DSTM32F10X_MD -DAPPLICATION -DF_CPU=72000000L -DF_CRYSTAL=8000000L -DUSE_STDPERIPH_DRIVER -DSYSCLK_FREQ_72MHz=72000000L -Istmlib/third_party/STM -Istmlib/third_party/STM/CMSIS/CM3_f10x -Istmlib/third_party/STM/CMSIS/CM3_f10x/startup/gcc -Istmlib/third_party/STM/STM32F10x_StdPeriph_Driver/inc -mcpu=cortex-m3 -mthumb -fno-unroll-loops -fno-exceptions -fno-rtti braids/ui.cc -MF build/braids/ui.d -MT build/braids/ui.o
/usr/local/arm-4.8.3/bin/arm-none-eabi-g++ -MM -g -O2 -Wall -Werror -Wno-unused-local-typedefs -fasm -finline -finline-functions-called-once -fdata-sections -ffunction-sections -fshort-enums -fno-move-loop-invariants -I. -DGCC_ARMCM3 -DSTM32F10X_MD -DAPPLICATION -DF_CPU=72000000L -DF_CRYSTAL=8000000L -DUSE_STDPERIPH_DRIVER -DSYSCLK_FREQ_72MHz=72000000L -Istmlib/third_party/STM -Istmlib/third_party/STM/CMSIS/CM3_f10x -Istmlib/third_party/STM/CMSIS/CM3_f10x/startup/gcc -Istmlib/third_party/STM/STM32F10x_StdPeriph_Driver/inc -mcpu=cortex-m3 -mthumb -fno-unroll-loops -fno-exceptions -fno-rtti braids/drivers/adc.cc -MF build/braids/adc.d -MT build/braids/adc.o
/usr/local/arm-4.8.3/bin/arm-none-eabi-g++ -MM -g -O2 -Wall -Werror -Wno-unused-local-typedefs -fasm -finline -finline-functions-called-once -fdata-sections -ffunction-sections -fshort-enums -fno-move-loop-invariants -I. -DGCC_ARMCM3 -DSTM32F10X_MD -DAPPLICATION -DF_CPU=72000000L -DF_CRYSTAL=8000000L -DUSE_STDPERIPH_DRIVER -DSYSCLK_FREQ_72MHz=72000000L -Istmlib/third_party/STM -Istmlib/third_party/STM/CMSIS/CM3_f10x -Istmlib/third_party/STM/CMSIS/CM3_f10x/startup/gcc -Istmlib/third_party/STM/STM32F10x_StdPeriph_Driver/inc -mcpu=cortex-m3 -mthumb -fno-unroll-loops -fno-exceptions -fno-rtti braids/drivers/dac.cc -MF build/braids/dac.d -MT build/braids/dac.o
/usr/local/arm-4.8.3/bin/arm-none-eabi-g++ -MM -g -O2 -Wall -Werror -Wno-unused-local-typedefs -fasm -finline -finline-functions-called-once -fdata-sections -ffunction-sections -fshort-enums -fno-move-loop-invariants -I. -DGCC_ARMCM3 -DSTM32F10X_MD -DAPPLICATION -DF_CPU=72000000L -DF_CRYSTAL=8000000L -DUSE_STDPERIPH_DRIVER -DSYSCLK_FREQ_72MHz=72000000L -Istmlib/third_party/STM -Istmlib/third_party/STM/CMSIS/CM3_f10x -Istmlib/third_party/STM/CMSIS/CM3_f10x/startup/gcc -Istmlib/third_party/STM/STM32F10x_StdPeriph_Driver/inc -mcpu=cortex-m3 -mthumb -fno-unroll-loops -fno-exceptions -fno-rtti braids/drivers/debug_pin.cc -MF build/braids/debug_pin.d -MT build/braids/debug_pin.o
/usr/local/arm-4.8.3/bin/arm-none-eabi-g++ -MM -g -O2 -Wall -Werror -Wno-unused-local-typedefs -fasm -finline -finline-functions-called-once -fdata-sections -ffunction-sections -fshort-enums -fno-move-loop-invariants -I. -DGCC_ARMCM3 -DSTM32F10X_MD -DAPPLICATION -DF_CPU=72000000L -DF_CRYSTAL=8000000L -DUSE_STDPERIPH_DRIVER -DSYSCLK_FREQ_72MHz=72000000L -Istmlib/third_party/STM -Istmlib/third_party/STM/CMSIS/CM3_f10x -Istmlib/third_party/STM/CMSIS/CM3_f10x/startup/gcc -Istmlib/third_party/STM/STM32F10x_StdPeriph_Driver/inc -mcpu=cortex-m3 -mthumb -fno-unroll-loops -fno-exceptions -fno-rtti braids/drivers/display.cc -MF build/braids/display.d -MT build/braids/display.o
/usr/local/arm-4.8.3/bin/arm-none-eabi-g++ -MM -g -O2 -Wall -Werror -Wno-unused-local-typedefs -fasm -finline -finline-functions-called-once -fdata-sections -ffunction-sections -fshort-enums -fno-move-loop-invariants -I. -DGCC_ARMCM3 -DSTM32F10X_MD -DAPPLICATION -DF_CPU=72000000L -DF_CRYSTAL=8000000L -DUSE_STDPERIPH_DRIVER -DSYSCLK_FREQ_72MHz=72000000L -Istmlib/third_party/STM -Istmlib/third_party/STM/CMSIS/CM3_f10x -Istmlib/third_party/STM/CMSIS/CM3_f10x/startup/gcc -Istmlib/third_party/STM/STM32F10x_StdPeriph_Driver/inc -mcpu=cortex-m3 -mthumb -fno-unroll-loops -fno-exceptions -fno-rtti braids/drivers/encoder.cc -MF build/braids/encoder.d -MT build/braids/encoder.o
/usr/local/arm-4.8.3/bin/arm-none-eabi-g++ -MM -g -O2 -Wall -Werror -Wno-unused-local-typedefs -fasm -finline -finline-functions-called-once -fdata-sections -ffunction-sections -fshort-enums -fno-move-loop-invariants -I. -DGCC_ARMCM3 -DSTM32F10X_MD -DAPPLICATION -DF_CPU=72000000L -DF_CRYSTAL=8000000L -DUSE_STDPERIPH_DRIVER -DSYSCLK_FREQ_72MHz=72000000L -Istmlib/third_party/STM -Istmlib/third_party/STM/CMSIS/CM3_f10x -Istmlib/third_party/STM/CMSIS/CM3_f10x/startup/gcc -Istmlib/third_party/STM/STM32F10x_StdPeriph_Driver/inc -mcpu=cortex-m3 -mthumb -fno-unroll-loops -fno-exceptions -fno-rtti braids/drivers/gate_input.cc -MF build/braids/gate_input.d -MT build/braids/gate_input.o
/usr/local/arm-4.8.3/bin/arm-none-eabi-g++ -MM -g -O2 -Wall -Werror -Wno-unused-local-typedefs -fasm -finline -finline-functions-called-once -fdata-sections -ffunction-sections -fshort-enums -fno-move-loop-invariants -I. -DGCC_ARMCM3 -DSTM32F10X_MD -DAPPLICATION -DF_CPU=72000000L -DF_CRYSTAL=8000000L -DUSE_STDPERIPH_DRIVER -DSYSCLK_FREQ_72MHz=72000000L -Istmlib/third_party/STM -Istmlib/third_party/STM/CMSIS/CM3_f10x -Istmlib/third_party/STM/CMSIS/CM3_f10x/startup/gcc -Istmlib/third_party/STM/STM32F10x_StdPeriph_Driver/inc -mcpu=cortex-m3 -mthumb -fno-unroll-loops -fno-exceptions -fno-rtti braids/drivers/internal_adc.cc -MF build/braids/internal_adc.d -MT build/braids/internal_adc.o
/usr/local/arm-4.8.3/bin/arm-none-eabi-g++ -MM -g -O2 -Wall -Werror -Wno-unused-local-typedefs -fasm -finline -finline-functions-called-once -fdata-sections -ffunction-sections -fshort-enums -fno-move-loop-invariants -I. -DGCC_ARMCM3 -DSTM32F10X_MD -DAPPLICATION -DF_CPU=72000000L -DF_CRYSTAL=8000000L -DUSE_STDPERIPH_DRIVER -DSYSCLK_FREQ_72MHz=72000000L -Istmlib/third_party/STM -Istmlib/third_party/STM/CMSIS/CM3_f10x -Istmlib/third_party/STM/CMSIS/CM3_f10x/startup/gcc -Istmlib/third_party/STM/STM32F10x_StdPeriph_Driver/inc -mcpu=cortex-m3 -mthumb -fno-unroll-loops -fno-exceptions -fno-rtti braids/drivers/system.cc -MF build/braids/system.d -MT build/braids/system.o
/usr/local/arm-4.8.3/bin/arm-none-eabi-g++ -MM -g -O2 -Wall -Werror -Wno-unused-local-typedefs -fasm -finline -finline-functions-called-once -fdata-sections -ffunction-sections -fshort-enums -fno-move-loop-invariants -I. -DGCC_ARMCM3 -DSTM32F10X_MD -DAPPLICATION -DF_CPU=72000000L -DF_CRYSTAL=8000000L -DUSE_STDPERIPH_DRIVER -DSYSCLK_FREQ_72MHz=72000000L -Istmlib/third_party/STM -Istmlib/third_party/STM/CMSIS/CM3_f10x -Istmlib/third_party/STM/CMSIS/CM3_f10x/startup/gcc -Istmlib/third_party/STM/STM32F10x_StdPeriph_Driver/inc -mcpu=cortex-m3 -mthumb -fno-unroll-loops -fno-exceptions -fno-rtti braids/drivers/uart_logger.cc -MF build/braids/uart_logger.d -MT build/braids/uart_logger.o
/usr/local/arm-4.8.3/bin/arm-none-eabi-g++ -MM -g -O2 -Wall -Werror -Wno-unused-local-typedefs -fasm -finline -finline-functions-called-once -fdata-sections -ffunction-sections -fshort-enums -fno-move-loop-invariants -I. -DGCC_ARMCM3 -DSTM32F10X_MD -DAPPLICATION -DF_CPU=72000000L -DF_CRYSTAL=8000000L -DUSE_STDPERIPH_DRIVER -DSYSCLK_FREQ_72MHz=72000000L -Istmlib/third_party/STM -Istmlib/third_party/STM/CMSIS/CM3_f10x -Istmlib/third_party/STM/CMSIS/CM3_f10x/startup/gcc -Istmlib/third_party/STM/STM32F10x_StdPeriph_Driver/inc -mcpu=cortex-m3 -mthumb -fno-unroll-loops -fno-exceptions -fno-rtti stmlib/utils/random.cc -MF build/braids/random.d -MT build/braids/random.o
/usr/local/arm-4.8.3/bin/arm-none-eabi-g++ -MM -g -O2 -Wall -Werror -Wno-unused-local-typedefs -fasm -finline -finline-functions-called-once -fdata-sections -ffunction-sections -fshort-enums -fno-move-loop-invariants -I. -DGCC_ARMCM3 -DSTM32F10X_MD -DAPPLICATION -DF_CPU=72000000L -DF_CRYSTAL=8000000L -DUSE_STDPERIPH_DRIVER -DSYSCLK_FREQ_72MHz=72000000L -Istmlib/third_party/STM -Istmlib/third_party/STM/CMSIS/CM3_f10x -Istmlib/third_party/STM/CMSIS/CM3_f10x/startup/gcc -Istmlib/third_party/STM/STM32F10x_StdPeriph_Driver/inc -mcpu=cortex-m3 -mthumb -fno-unroll-loops -fno-exceptions -fno-rtti stmlib/system/bootloader_utils.cc -MF build/braids/bootloader_utils.d -MT build/braids/bootloader_utils.o
/usr/local/arm-4.8.3/bin/arm-none-eabi-g++ -MM -g -O2 -Wall -Werror -Wno-unused-local-typedefs -fasm -finline -finline-functions-called-once -fdata-sections -ffunction-sections -fshort-enums -fno-move-loop-invariants -I. -DGCC_ARMCM3 -DSTM32F10X_MD -DAPPLICATION -DF_CPU=72000000L -DF_CRYSTAL=8000000L -DUSE_STDPERIPH_DRIVER -DSYSCLK_FREQ_72MHz=72000000L -Istmlib/third_party/STM -Istmlib/third_party/STM/CMSIS/CM3_f10x -Istmlib/third_party/STM/CMSIS/CM3_f10x/startup/gcc -Istmlib/third_party/STM/STM32F10x_StdPeriph_Driver/inc -mcpu=cortex-m3 -mthumb -fno-unroll-loops -fno-exceptions -fno-rtti stmlib/system/system_clock.cc -MF build/braids/system_clock.d -MT build/braids/system_clock.o
/usr/local/arm-4.8.3/bin/arm-none-eabi-gcc -MM -g -O2 -Wall -Werror -Wno-unused-local-typedefs -fasm -finline -finline-functions-called-once -fdata-sections -ffunction-sections -fshort-enums -fno-move-loop-invariants -I. -DGCC_ARMCM3 -DSTM32F10X_MD -DAPPLICATION -DF_CPU=72000000L -DF_CRYSTAL=8000000L -DUSE_STDPERIPH_DRIVER -DSYSCLK_FREQ_72MHz=72000000L -Istmlib/third_party/STM -Istmlib/third_party/STM/CMSIS/CM3_f10x -Istmlib/third_party/STM/CMSIS/CM3_f10x/startup/gcc -Istmlib/third_party/STM/STM32F10x_StdPeriph_Driver/inc -mcpu=cortex-m3 -mthumb -fno-unroll-loops stmlib/third_party/STM/CMSIS/CM3_f10x/core_cm3.c -MF build/braids/core_cm3.d -MT build/braids/core_cm3.o
/usr/local/arm-4.8.3/bin/arm-none-eabi-gcc -MM -g -O2 -Wall -Werror -Wno-unused-local-typedefs -fasm -finline -finline-functions-called-once -fdata-sections -ffunction-sections -fshort-enums -fno-move-loop-invariants -I. -DGCC_ARMCM3 -DSTM32F10X_MD -DAPPLICATION -DF_CPU=72000000L -DF_CRYSTAL=8000000L -DUSE_STDPERIPH_DRIVER -DSYSCLK_FREQ_72MHz=72000000L -Istmlib/third_party/STM -Istmlib/third_party/STM/CMSIS/CM3_f10x -Istmlib/third_party/STM/CMSIS/CM3_f10x/startup/gcc -Istmlib/third_party/STM/STM32F10x_StdPeriph_Driver/inc -mcpu=cortex-m3 -mthumb -fno-unroll-loops stmlib/third_party/STM/CMSIS/CM3_f10x/system_stm32f10x.c -MF build/braids/system_stm32f10x.d -MT build/braids/system_stm32f10x.o
/usr/local/arm-4.8.3/bin/arm-none-eabi-gcc -MM -g -O2 -Wall -Werror -Wno-unused-local-typedefs -fasm -finline -finline-functions-called-once -fdata-sections -ffunction-sections -fshort-enums -fno-move-loop-invariants -I. -DGCC_ARMCM3 -DSTM32F10X_MD -DAPPLICATION -DF_CPU=72000000L -DF_CRYSTAL=8000000L -DUSE_STDPERIPH_DRIVER -DSYSCLK_FREQ_72MHz=72000000L -Istmlib/third_party/STM -Istmlib/third_party/STM/CMSIS/CM3_f10x -Istmlib/third_party/STM/CMSIS/CM3_f10x/startup/gcc -Istmlib/third_party/STM/STM32F10x_StdPeriph_Driver/inc -mcpu=cortex-m3 -mthumb -fno-unroll-loops stmlib/third_party/STM/STM32F10x_StdPeriph_Driver/src/misc.c -MF build/braids/misc.d -MT build/braids/misc.o
/usr/local/arm-4.8.3/bin/arm-none-eabi-gcc -MM -g -O2 -Wall -Werror -Wno-unused-local-typedefs -fasm -finline -finline-functions-called-once -fdata-sections -ffunction-sections -fshort-enums -fno-move-loop-invariants -I. -DGCC_ARMCM3 -DSTM32F10X_MD -DAPPLICATION -DF_CPU=72000000L -DF_CRYSTAL=8000000L -DUSE_STDPERIPH_DRIVER -DSYSCLK_FREQ_72MHz=72000000L -Istmlib/third_party/STM -Istmlib/third_party/STM/CMSIS/CM3_f10x -Istmlib/third_party/STM/CMSIS/CM3_f10x/startup/gcc -Istmlib/third_party/STM/STM32F10x_StdPeriph_Driver/inc -mcpu=cortex-m3 -mthumb -fno-unroll-loops stmlib/third_party/STM/STM32F10x_StdPeriph_Driver/src/stm32f10x_adc.c -MF build/braids/stm32f10x_adc.d -MT build/braids/stm32f10x_adc.o
/usr/local/arm-4.8.3/bin/arm-none-eabi-gcc -MM -g -O2 -Wall -Werror -Wno-unused-local-typedefs -fasm -finline -finline-functions-called-once -fdata-sections -ffunction-sections -fshort-enums -fno-move-loop-invariants -I. -DGCC_ARMCM3 -DSTM32F10X_MD -DAPPLICATION -DF_CPU=72000000L -DF_CRYSTAL=8000000L -DUSE_STDPERIPH_DRIVER -DSYSCLK_FREQ_72MHz=72000000L -Istmlib/third_party/STM -Istmlib/third_party/STM/CMSIS/CM3_f10x -Istmlib/third_party/STM/CMSIS/CM3_f10x/startup/gcc -Istmlib/third_party/STM/STM32F10x_StdPeriph_Driver/inc -mcpu=cortex-m3 -mthumb -fno-unroll-loops stmlib/third_party/STM/STM32F10x_StdPeriph_Driver/src/stm32f10x_bkp.c -MF build/braids/stm32f10x_bkp.d -MT build/braids/stm32f10x_bkp.o
/usr/local/arm-4.8.3/bin/arm-none-eabi-gcc -MM -g -O2 -Wall -Werror -Wno-unused-local-typedefs -fasm -finline -finline-functions-called-once -fdata-sections -ffunction-sections -fshort-enums -fno-move-loop-invariants -I. -DGCC_ARMCM3 -DSTM32F10X_MD -DAPPLICATION -DF_CPU=72000000L -DF_CRYSTAL=8000000L -DUSE_STDPERIPH_DRIVER -DSYSCLK_FREQ_72MHz=72000000L -Istmlib/third_party/STM -Istmlib/third_party/STM/CMSIS/CM3_f10x -Istmlib/third_party/STM/CMSIS/CM3_f10x/startup/gcc -Istmlib/third_party/STM/STM32F10x_StdPeriph_Driver/inc -mcpu=cortex-m3 -mthumb -fno-unroll-loops stmlib/third_party/STM/STM32F10x_StdPeriph_Driver/src/stm32f10x_can.c -MF build/braids/stm32f10x_can.d -MT build/braids/stm32f10x_can.o
/usr/local/arm-4.8.3/bin/arm-none-eabi-gcc -MM -g -O2 -Wall -Werror -Wno-unused-local-typedefs -fasm -finline -finline-functions-called-once -fdata-sections -ffunction-sections -fshort-enums -fno-move-loop-invariants -I. -DGCC_ARMCM3 -DSTM32F10X_MD -DAPPLICATION -DF_CPU=72000000L -DF_CRYSTAL=8000000L -DUSE_STDPERIPH_DRIVER -DSYSCLK_FREQ_72MHz=72000000L -Istmlib/third_party/STM -Istmlib/third_party/STM/CMSIS/CM3_f10x -Istmlib/third_party/STM/CMSIS/CM3_f10x/startup/gcc -Istmlib/third_party/STM/STM32F10x_StdPeriph_Driver/inc -mcpu=cortex-m3 -mthumb -fno-unroll-loops stmlib/third_party/STM/STM32F10x_StdPeriph_Driver/src/stm32f10x_crc.c -MF build/braids/stm32f10x_crc.d -MT build/braids/stm32f10x_crc.o
/usr/local/arm-4.8.3/bin/arm-none-eabi-gcc -MM -g -O2 -Wall -Werror -Wno-unused-local-typedefs -fasm -finline -finline-functions-called-once -fdata-sections -ffunction-sections -fshort-enums -fno-move-loop-invariants -I. -DGCC_ARMCM3 -DSTM32F10X_MD -DAPPLICATION -DF_CPU=72000000L -DF_CRYSTAL=8000000L -DUSE_STDPERIPH_DRIVER -DSYSCLK_FREQ_72MHz=72000000L -Istmlib/third_party/STM -Istmlib/third_party/STM/CMSIS/CM3_f10x -Istmlib/third_party/STM/CMSIS/CM3_f10x/startup/gcc -Istmlib/third_party/STM/STM32F10x_StdPeriph_Driver/inc -mcpu=cortex-m3 -mthumb -fno-unroll-loops stmlib/third_party/STM/STM32F10x_StdPeriph_Driver/src/stm32f10x_dac.c -MF build/braids/stm32f10x_dac.d -MT build/braids/stm32f10x_dac.o
/usr/local/arm-4.8.3/bin/arm-none-eabi-gcc -MM -g -O2 -Wall -Werror -Wno-unused-local-typedefs -fasm -finline -finline-functions-called-once -fdata-sections -ffunction-sections -fshort-enums -fno-move-loop-invariants -I. -DGCC_ARMCM3 -DSTM32F10X_MD -DAPPLICATION -DF_CPU=72000000L -DF_CRYSTAL=8000000L -DUSE_STDPERIPH_DRIVER -DSYSCLK_FREQ_72MHz=72000000L -Istmlib/third_party/STM -Istmlib/third_party/STM/CMSIS/CM3_f10x -Istmlib/third_party/STM/CMSIS/CM3_f10x/startup/gcc -Istmlib/third_party/STM/STM32F10x_StdPeriph_Driver/inc -mcpu=cortex-m3 -mthumb -fno-unroll-loops stmlib/third_party/STM/STM32F10x_StdPeriph_Driver/src/stm32f10x_dbgmcu .c -MF build/braids/stm32f10x_dbgmcu.d -MT build/braids/stm32f10x_dbgmcu.o
/usr/local/arm-4.8.3/bin/arm-none-eabi-gcc -MM -g -O2 -Wall -Werror -Wno-unused-local-typedefs -fasm -finline -finline-functions-called-once -fdata-sections -ffunction-sections -fshort-enums -fno-move-loop-invariants -I. -DGCC_ARMCM3 -DSTM32F10X_MD -DAPPLICATION -DF_CPU=72000000L -DF_CRYSTAL=8000000L -DUSE_STDPERIPH_DRIVER -DSYSCLK_FREQ_72MHz=72000000L -Istmlib/third_party/STM -Istmlib/third_party/STM/CMSIS/CM3_f10x -Istmlib/third_party/STM/CMSIS/CM3_f10x/startup/gcc -Istmlib/third_party/STM/STM32F10x_StdPeriph_Driver/inc -mcpu=cortex-m3 -mthumb -fno-unroll-loops stmlib/third_party/STM/STM32F10x_StdPeriph_Driver/src/stm32f10x_dma.c -MF build/braids/stm32f10x_dma.d -MT build/braids/stm32f10x_dma.o
/usr/local/arm-4.8.3/bin/arm-none-eabi-gcc -MM -g -O2 -Wall -Werror -Wno-unused-local-typedefs -fasm -finline -finline-functions-called-once -fdata-sections -ffunction-sections -fshort-enums -fno-move-loop-invariants -I. -DGCC_ARMCM3 -DSTM32F10X_MD -DAPPLICATION -DF_CPU=72000000L -DF_CRYSTAL=8000000L -DUSE_STDPERIPH_DRIVER -DSYSCLK_FREQ_72MHz=72000000L -Istmlib/third_party/STM -Istmlib/third_party/STM/CMSIS/CM3_f10x -Istmlib/third_party/STM/CMSIS/CM3_f10x/startup/gcc -Istmlib/third_party/STM/STM32F10x_StdPeriph_Driver/inc -mcpu=cortex-m3 -mthumb -fno-unroll-loops stmlib/third_party/STM/STM32F10x_StdPeriph_Driver/src/stm32f10x_exti.c -MF build/braids/stm32f10x_exti.d -MT build/braids/stm32f10x_exti.o
/usr/local/arm-4.8.3/bin/arm-none-eabi-gcc -MM -g -O2 -Wall -Werror -Wno-unused-local-typedefs -fasm -finline -finline-functions-called-once -fdata-sections -ffunction-sections -fshort-enums -fno-move-loop-invariants -I. -DGCC_ARMCM3 -DSTM32F10X_MD -DAPPLICATION -DF_CPU=72000000L -DF_CRYSTAL=8000000L -DUSE_STDPERIPH_DRIVER -DSYSCLK_FREQ_72MHz=72000000L -Istmlib/third_party/STM -Istmlib/third_party/STM/CMSIS/CM3_f10x -Istmlib/third_party/STM/CMSIS/CM3_f10x/startup/gcc -Istmlib/third_party/STM/STM32F10x_StdPeriph_Driver/inc -mcpu=cortex-m3 -mthumb -fno-unroll-loops stmlib/third_party/STM/STM32F10x_StdPeriph_Driver/src/stm32f10x_flash. c -MF build/braids/stm32f10x_flash.d -MT build/braids/stm32f10x_flash.o
/usr/local/arm-4.8.3/bin/arm-none-eabi-gcc -MM -g -O2 -Wall -Werror -Wno-unused-local-typedefs -fasm -finline -finline-functions-called-once -fdata-sections -ffunction-sections -fshort-enums -fno-move-loop-invariants -I. -DGCC_ARMCM3 -DSTM32F10X_MD -DAPPLICATION -DF_CPU=72000000L -DF_CRYSTAL=8000000L -DUSE_STDPERIPH_DRIVER -DSYSCLK_FREQ_72MHz=72000000L -Istmlib/third_party/STM -Istmlib/third_party/STM/CMSIS/CM3_f10x -Istmlib/third_party/STM/CMSIS/CM3_f10x/startup/gcc -Istmlib/third_party/STM/STM32F10x_StdPeriph_Driver/inc -mcpu=cortex-m3 -mthumb -fno-unroll-loops stmlib/third_party/STM/STM32F10x_StdPeriph_Driver/src/stm32f10x_fsmc.c -MF build/braids/stm32f10x_fsmc.d -MT build/braids/stm32f10x_fsmc.o
/usr/local/arm-4.8.3/bin/arm-none-eabi-gcc -MM -g -O2 -Wall -Werror -Wno-unused-local-typedefs -fasm -finline -finline-functions-called-once -fdata-sections -ffunction-sections -fshort-enums -fno-move-loop-invariants -I. -DGCC_ARMCM3 -DSTM32F10X_MD -DAPPLICATION -DF_CPU=72000000L -DF_CRYSTAL=8000000L -DUSE_STDPERIPH_DRIVER -DSYSCLK_FREQ_72MHz=72000000L -Istmlib/third_party/STM -Istmlib/third_party/STM/CMSIS/CM3_f10x -Istmlib/third_party/STM/CMSIS/CM3_f10x/startup/gcc -Istmlib/third_party/STM/STM32F10x_StdPeriph_Driver/inc -mcpu=cortex-m3 -mthumb -fno-unroll-loops stmlib/third_party/STM/STM32F10x_StdPeriph_Driver/src/stm32f10x_gpio.c -MF build/braids/stm32f10x_gpio.d -MT build/braids/stm32f10x_gpio.o
/usr/local/arm-4.8.3/bin/arm-none-eabi-gcc -MM -g -O2 -Wall -Werror -Wno-unused-local-typedefs -fasm -finline -finline-functions-called-once -fdata-sections -ffunction-sections -fshort-enums -fno-move-loop-invariants -I. -DGCC_ARMCM3 -DSTM32F10X_MD -DAPPLICATION -DF_CPU=72000000L -DF_CRYSTAL=8000000L -DUSE_STDPERIPH_DRIVER -DSYSCLK_FREQ_72MHz=72000000L -Istmlib/third_party/STM -Istmlib/third_party/STM/CMSIS/CM3_f10x -Istmlib/third_party/STM/CMSIS/CM3_f10x/startup/gcc -Istmlib/third_party/STM/STM32F10x_StdPeriph_Driver/inc -mcpu=cortex-m3 -mthumb -fno-unroll-loops stmlib/third_party/STM/STM32F10x_StdPeriph_Driver/src/stm32f10x_i2c.c -MF build/braids/stm32f10x_i2c.d -MT build/braids/stm32f10x_i2c.o
/usr/local/arm-4.8.3/bin/arm-none-eabi-gcc -MM -g -O2 -Wall -Werror -Wno-unused-local-typedefs -fasm -finline -finline-functions-called-once -fdata-sections -ffunction-sections -fshort-enums -fno-move-loop-invariants -I. -DGCC_ARMCM3 -DSTM32F10X_MD -DAPPLICATION -DF_CPU=72000000L -DF_CRYSTAL=8000000L -DUSE_STDPERIPH_DRIVER -DSYSCLK_FREQ_72MHz=72000000L -Istmlib/third_party/STM -Istmlib/third_party/STM/CMSIS/CM3_f10x -Istmlib/third_party/STM/CMSIS/CM3_f10x/startup/gcc -Istmlib/third_party/STM/STM32F10x_StdPeriph_Driver/inc -mcpu=cortex-m3 -mthumb -fno-unroll-loops stmlib/third_party/STM/STM32F10x_StdPeriph_Driver/src/stm32f10x_iwdg.c -MF build/braids/stm32f10x_iwdg.d -MT build/braids/stm32f10x_iwdg.o
/usr/local/arm-4.8.3/bin/arm-none-eabi-gcc -MM -g -O2 -Wall -Werror -Wno-unused-local-typedefs -fasm -finline -finline-functions-called-once -fdata-sections -ffunction-sections -fshort-enums -fno-move-loop-invariants -I. -DGCC_ARMCM3 -DSTM32F10X_MD -DAPPLICATION -DF_CPU=72000000L -DF_CRYSTAL=8000000L -DUSE_STDPERIPH_DRIVER -DSYSCLK_FREQ_72MHz=72000000L -Istmlib/third_party/STM -Istmlib/third_party/STM/CMSIS/CM3_f10x -Istmlib/third_party/STM/CMSIS/CM3_f10x/startup/gcc -Istmlib/third_party/STM/STM32F10x_StdPeriph_Driver/inc -mcpu=cortex-m3 -mthumb -fno-unroll-loops stmlib/third_party/STM/STM32F10x_StdPeriph_Driver/src/stm32f10x_pwr.c -MF build/braids/stm32f10x_pwr.d -MT build/braids/stm32f10x_pwr.o
/usr/local/arm-4.8.3/bin/arm-none-eabi-gcc -MM -g -O2 -Wall -Werror -Wno-unused-local-typedefs -fasm -finline -finline-functions-called-once -fdata-sections -ffunction-sections -fshort-enums -fno-move-loop-invariants -I. -DGCC_ARMCM3 -DSTM32F10X_MD -DAPPLICATION -DF_CPU=72000000L -DF_CRYSTAL=8000000L -DUSE_STDPERIPH_DRIVER -DSYSCLK_FREQ_72MHz=72000000L -Istmlib/third_party/STM -Istmlib/third_party/STM/CMSIS/CM3_f10x -Istmlib/third_party/STM/CMSIS/CM3_f10x/startup/gcc -Istmlib/third_party/STM/STM32F10x_StdPeriph_Driver/inc -mcpu=cortex-m3 -mthumb -fno-unroll-loops stmlib/third_party/STM/STM32F10x_StdPeriph_Driver/src/stm32f10x_rcc.c -MF build/braids/stm32f10x_rcc.d -MT build/braids/stm32f10x_rcc.o
/usr/local/arm-4.8.3/bin/arm-none-eabi-gcc -MM -g -O2 -Wall -Werror -Wno-unused-local-typedefs -fasm -finline -finline-functions-called-once -fdata-sections -ffunction-sections -fshort-enums -fno-move-loop-invariants -I. -DGCC_ARMCM3 -DSTM32F10X_MD -DAPPLICATION -DF_CPU=72000000L -DF_CRYSTAL=8000000L -DUSE_STDPERIPH_DRIVER -DSYSCLK_FREQ_72MHz=72000000L -Istmlib/third_party/STM -Istmlib/third_party/STM/CMSIS/CM3_f10x -Istmlib/third_party/STM/CMSIS/CM3_f10x/startup/gcc -Istmlib/third_party/STM/STM32F10x_StdPeriph_Driver/inc -mcpu=cortex-m3 -mthumb -fno-unroll-loops stmlib/third_party/STM/STM32F10x_StdPeriph_Driver/src/stm32f10x_rtc.c -MF build/braids/stm32f10x_rtc.d -MT build/braids/stm32f10x_rtc.o
/usr/local/arm-4.8.3/bin/arm-none-eabi-gcc -MM -g -O2 -Wall -Werror -Wno-unused-local-typedefs -fasm -finline -finline-functions-called-once -fdata-sections -ffunction-sections -fshort-enums -fno-move-loop-invariants -I. -DGCC_ARMCM3 -DSTM32F10X_MD -DAPPLICATION -DF_CPU=72000000L -DF_CRYSTAL=8000000L -DUSE_STDPERIPH_DRIVER -DSYSCLK_FREQ_72MHz=72000000L -Istmlib/third_party/STM -Istmlib/third_party/STM/CMSIS/CM3_f10x -Istmlib/third_party/STM/CMSIS/CM3_f10x/startup/gcc -Istmlib/third_party/STM/STM32F10x_StdPeriph_Driver/inc -mcpu=cortex-m3 -mthumb -fno-unroll-loops stmlib/third_party/STM/STM32F10x_StdPeriph_Driver/src/stm32f10x_sdio.c -MF build/braids/stm32f10x_sdio.d -MT build/braids/stm32f10x_sdio.o
/usr/local/arm-4.8.3/bin/arm-none-eabi-gcc -MM -g -O2 -Wall -Werror -Wno-unused-local-typedefs -fasm -finline -finline-functions-called-once -fdata-sections -ffunction-sections -fshort-enums -fno-move-loop-invariants -I. -DGCC_ARMCM3 -DSTM32F10X_MD -DAPPLICATION -DF_CPU=72000000L -DF_CRYSTAL=8000000L -DUSE_STDPERIPH_DRIVER -DSYSCLK_FREQ_72MHz=72000000L -Istmlib/third_party/STM -Istmlib/third_party/STM/CMSIS/CM3_f10x -Istmlib/third_party/STM/CMSIS/CM3_f10x/startup/gcc -Istmlib/third_party/STM/STM32F10x_StdPeriph_Driver/inc -mcpu=cortex-m3 -mthumb -fno-unroll-loops stmlib/third_party/STM/STM32F10x_StdPeriph_Driver/src/stm32f10x_spi.c -MF build/braids/stm32f10x_spi.d -MT build/braids/stm32f10x_spi.o
/usr/local/arm-4.8.3/bin/arm-none-eabi-gcc -MM -g -O2 -Wall -Werror -Wno-unused-local-typedefs -fasm -finline -finline-functions-called-once -fdata-sections -ffunction-sections -fshort-enums -fno-move-loop-invariants -I. -DGCC_ARMCM3 -DSTM32F10X_MD -DAPPLICATION -DF_CPU=72000000L -DF_CRYSTAL=8000000L -DUSE_STDPERIPH_DRIVER -DSYSCLK_FREQ_72MHz=72000000L -Istmlib/third_party/STM -Istmlib/third_party/STM/CMSIS/CM3_f10x -Istmlib/third_party/STM/CMSIS/CM3_f10x/startup/gcc -Istmlib/third_party/STM/STM32F10x_StdPeriph_Driver/inc -mcpu=cortex-m3 -mthumb -fno-unroll-loops stmlib/third_party/STM/STM32F10x_StdPeriph_Driver/src/stm32f10x_tim.c -MF build/braids/stm32f10x_tim.d -MT build/braids/stm32f10x_tim.o
/usr/local/arm-4.8.3/bin/arm-none-eabi-gcc -MM -g -O2 -Wall -Werror -Wno-unused-local-typedefs -fasm -finline -finline-functions-called-once -fdata-sections -ffunction-sections -fshort-enums -fno-move-loop-invariants -I. -DGCC_ARMCM3 -DSTM32F10X_MD -DAPPLICATION -DF_CPU=72000000L -DF_CRYSTAL=8000000L -DUSE_STDPERIPH_DRIVER -DSYSCLK_FREQ_72MHz=72000000L -Istmlib/third_party/STM -Istmlib/third_party/STM/CMSIS/CM3_f10x -Istmlib/third_party/STM/CMSIS/CM3_f10x/startup/gcc -Istmlib/third_party/STM/STM32F10x_StdPeriph_Driver/inc -mcpu=cortex-m3 -mthumb -fno-unroll-loops stmlib/third_party/STM/STM32F10x_StdPeriph_Driver/src/stm32f10x_usart. c -MF build/braids/stm32f10x_usart.d -MT build/braids/stm32f10x_usart.o
/usr/local/arm-4.8.3/bin/arm-none-eabi-gcc -MM -g -O2 -Wall -Werror -Wno-unused-local-typedefs -fasm -finline -finline-functions-called-once -fdata-sections -ffunction-sections -fshort-enums -fno-move-loop-invariants -I. -DGCC_ARMCM3 -DSTM32F10X_MD -DAPPLICATION -DF_CPU=72000000L -DF_CRYSTAL=8000000L -DUSE_STDPERIPH_DRIVER -DSYSCLK_FREQ_72MHz=72000000L -Istmlib/third_party/STM -Istmlib/third_party/STM/CMSIS/CM3_f10x -Istmlib/third_party/STM/CMSIS/CM3_f10x/startup/gcc -Istmlib/third_party/STM/STM32F10x_StdPeriph_Driver/inc -mcpu=cortex-m3 -mthumb -fno-unroll-loops stmlib/third_party/STM/STM32F10x_StdPeriph_Driver/src/stm32f10x_wwdg.c -MF build/braids/stm32f10x_wwdg.d -MT build/braids/stm32f10x_wwdg.o
/usr/local/arm-4.8.3/bin/arm-none-eabi-gcc -c -x assembler-with-cpp -MM -mcpu=cortex-m3 -mthumb -fno-unroll-loops stmlib/third_party/STM/CMSIS/CM3_f10x/startup/gcc/startup_stm32f10x_md .s -MF build/braids/startup_stm32f10x_md.d -MT build/braids/startup_stm32f10x_md.o
cat build/braids/analog_oscillator.d build/braids/braids.d build/braids/digital_oscillator.d build/braids/macro_oscillator.d build/braids/quantizer.d build/braids/resources.d build/braids/settings.d build/braids/ui.d build/braids/adc.d build/braids/dac.d build/braids/debug_pin.d build/braids/display.d build/braids/encoder.d build/braids/gate_input.d build/braids/internal_adc.d build/braids/system.d build/braids/uart_logger.d build/braids/random.d build/braids/bootloader_utils.d build/braids/system_clock.d build/braids/core_cm3.d build/braids/system_stm32f10x.d build/braids/misc.d build/braids/stm32f10x_adc.d build/braids/stm32f10x_bkp.d build/braids/stm32f10x_can.d build/braids/stm32f10x_crc.d build/braids/stm32f10x_dac.d build/braids/stm32f10x_dbgmcu.d build/braids/stm32f10x_dma.d build/braids/stm32f10x_exti.d build/braids/stm32f10x_flash.d build/braids/stm32f10x_fsmc.d build/braids/stm32f10x_gpio.d build/braids/stm32f10x_i2c.d build/braids/stm32f10x_iwdg.d build/braids/stm32f10x_pwr.d build/braids/stm32f10x_rcc.d build/braids/stm32f10x_rtc.d build/braids/stm32f10x_sdio.d build/braids/stm32f10x_spi.d build/braids/stm32f10x_tim.d build/braids/stm32f10x_usart.d build/braids/stm32f10x_wwdg.d build/braids/startup_stm32f10x_md.d > build/braids/depends.mk
/usr/local/arm-4.8.3/bin/arm-none-eabi-g++ -c -g -O2 -Wall -Werror -Wno-unused-local-typedefs -fasm -finline -finline-functions-called-once -fdata-sections -ffunction-sections -fshort-enums -fno-move-loop-invariants -I. -DGCC_ARMCM3 -DSTM32F10X_MD -DAPPLICATION -DF_CPU=72000000L -DF_CRYSTAL=8000000L -DUSE_STDPERIPH_DRIVER -DSYSCLK_FREQ_72MHz=72000000L -Istmlib/third_party/STM -Istmlib/third_party/STM/CMSIS/CM3_f10x -Istmlib/third_party/STM/CMSIS/CM3_f10x/startup/gcc -Istmlib/third_party/STM/STM32F10x_StdPeriph_Driver/inc -mcpu=cortex-m3 -mthumb -fno-unroll-loops -fno-exceptions -fno-rtti braids/analog_oscillator.cc -o build/braids/analog_oscillator.o
/usr/local/arm-4.8.3/bin/arm-none-eabi-g++ -c -g -O2 -Wall -Werror -Wno-unused-local-typedefs -fasm -finline -finline-functions-called-once -fdata-sections -ffunction-sections -fshort-enums -fno-move-loop-invariants -I. -DGCC_ARMCM3 -DSTM32F10X_MD -DAPPLICATION -DF_CPU=72000000L -DF_CRYSTAL=8000000L -DUSE_STDPERIPH_DRIVER -DSYSCLK_FREQ_72MHz=72000000L -Istmlib/third_party/STM -Istmlib/third_party/STM/CMSIS/CM3_f10x -Istmlib/third_party/STM/CMSIS/CM3_f10x/startup/gcc -Istmlib/third_party/STM/STM32F10x_StdPeriph_Driver/inc -mcpu=cortex-m3 -mthumb -fno-unroll-loops -fno-exceptions -fno-rtti braids/braids.cc -o build/braids/braids.o
/usr/local/arm-4.8.3/bin/arm-none-eabi-g++ -c -g -O2 -Wall -Werror -Wno-unused-local-typedefs -fasm -finline -finline-functions-called-once -fdata-sections -ffunction-sections -fshort-enums -fno-move-loop-invariants -I. -DGCC_ARMCM3 -DSTM32F10X_MD -DAPPLICATION -DF_CPU=72000000L -DF_CRYSTAL=8000000L -DUSE_STDPERIPH_DRIVER -DSYSCLK_FREQ_72MHz=72000000L -Istmlib/third_party/STM -Istmlib/third_party/STM/CMSIS/CM3_f10x -Istmlib/third_party/STM/CMSIS/CM3_f10x/startup/gcc -Istmlib/third_party/STM/STM32F10x_StdPeriph_Driver/inc -mcpu=cortex-m3 -mthumb -fno-unroll-loops -fno-exceptions -fno-rtti braids/digital_oscillator.cc -o build/braids/digital_oscillator.o
/usr/local/arm-4.8.3/bin/arm-none-eabi-g++ -c -g -O2 -Wall -Werror -Wno-unused-local-typedefs -fasm -finline -finline-functions-called-once -fdata-sections -ffunction-sections -fshort-enums -fno-move-loop-invariants -I. -DGCC_ARMCM3 -DSTM32F10X_MD -DAPPLICATION -DF_CPU=72000000L -DF_CRYSTAL=8000000L -DUSE_STDPERIPH_DRIVER -DSYSCLK_FREQ_72MHz=72000000L -Istmlib/third_party/STM -Istmlib/third_party/STM/CMSIS/CM3_f10x -Istmlib/third_party/STM/CMSIS/CM3_f10x/startup/gcc -Istmlib/third_party/STM/STM32F10x_StdPeriph_Driver/inc -mcpu=cortex-m3 -mthumb -fno-unroll-loops -fno-exceptions -fno-rtti braids/macro_oscillator.cc -o build/braids/macro_oscillator.o
/usr/local/arm-4.8.3/bin/arm-none-eabi-g++ -c -g -O2 -Wall -Werror -Wno-unused-local-typedefs -fasm -finline -finline-functions-called-once -fdata-sections -ffunction-sections -fshort-enums -fno-move-loop-invariants -I. -DGCC_ARMCM3 -DSTM32F10X_MD -DAPPLICATION -DF_CPU=72000000L -DF_CRYSTAL=8000000L -DUSE_STDPERIPH_DRIVER -DSYSCLK_FREQ_72MHz=72000000L -Istmlib/third_party/STM -Istmlib/third_party/STM/CMSIS/CM3_f10x -Istmlib/third_party/STM/CMSIS/CM3_f10x/startup/gcc -Istmlib/third_party/STM/STM32F10x_StdPeriph_Driver/inc -mcpu=cortex-m3 -mthumb -fno-unroll-loops -fno-exceptions -fno-rtti braids/quantizer.cc -o build/braids/quantizer.o
/usr/local/arm-4.8.3/bin/arm-none-eabi-g++ -c -g -O2 -Wall -Werror -Wno-unused-local-typedefs -fasm -finline -finline-functions-called-once -fdata-sections -ffunction-sections -fshort-enums -fno-move-loop-invariants -I. -DGCC_ARMCM3 -DSTM32F10X_MD -DAPPLICATION -DF_CPU=72000000L -DF_CRYSTAL=8000000L -DUSE_STDPERIPH_DRIVER -DSYSCLK_FREQ_72MHz=72000000L -Istmlib/third_party/STM -Istmlib/third_party/STM/CMSIS/CM3_f10x -Istmlib/third_party/STM/CMSIS/CM3_f10x/startup/gcc -Istmlib/third_party/STM/STM32F10x_StdPeriph_Driver/inc -mcpu=cortex-m3 -mthumb -fno-unroll-loops -fno-exceptions -fno-rtti braids/resources.cc -o build/braids/resources.o
/usr/local/arm-4.8.3/bin/arm-none-eabi-g++ -c -g -O2 -Wall -Werror -Wno-unused-local-typedefs -fasm -finline -finline-functions-called-once -fdata-sections -ffunction-sections -fshort-enums -fno-move-loop-invariants -I. -DGCC_ARMCM3 -DSTM32F10X_MD -DAPPLICATION -DF_CPU=72000000L -DF_CRYSTAL=8000000L -DUSE_STDPERIPH_DRIVER -DSYSCLK_FREQ_72MHz=72000000L -Istmlib/third_party/STM -Istmlib/third_party/STM/CMSIS/CM3_f10x -Istmlib/third_party/STM/CMSIS/CM3_f10x/startup/gcc -Istmlib/third_party/STM/STM32F10x_StdPeriph_Driver/inc -mcpu=cortex-m3 -mthumb -fno-unroll-loops -fno-exceptions -fno-rtti braids/settings.cc -o build/braids/settings.o
/usr/local/arm-4.8.3/bin/arm-none-eabi-g++ -c -g -O2 -Wall -Werror -Wno-unused-local-typedefs -fasm -finline -finline-functions-called-once -fdata-sections -ffunction-sections -fshort-enums -fno-move-loop-invariants -I. -DGCC_ARMCM3 -DSTM32F10X_MD -DAPPLICATION -DF_CPU=72000000L -DF_CRYSTAL=8000000L -DUSE_STDPERIPH_DRIVER -DSYSCLK_FREQ_72MHz=72000000L -Istmlib/third_party/STM -Istmlib/third_party/STM/CMSIS/CM3_f10x -Istmlib/third_party/STM/CMSIS/CM3_f10x/startup/gcc -Istmlib/third_party/STM/STM32F10x_StdPeriph_Driver/inc -mcpu=cortex-m3 -mthumb -fno-unroll-loops -fno-exceptions -fno-rtti braids/ui.cc -o build/braids/ui.o
/usr/local/arm-4.8.3/bin/arm-none-eabi-g++ -c -g -O2 -Wall -Werror -Wno-unused-local-typedefs -fasm -finline -finline-functions-called-once -fdata-sections -ffunction-sections -fshort-enums -fno-move-loop-invariants -I. -DGCC_ARMCM3 -DSTM32F10X_MD -DAPPLICATION -DF_CPU=72000000L -DF_CRYSTAL=8000000L -DUSE_STDPERIPH_DRIVER -DSYSCLK_FREQ_72MHz=72000000L -Istmlib/third_party/STM -Istmlib/third_party/STM/CMSIS/CM3_f10x -Istmlib/third_party/STM/CMSIS/CM3_f10x/startup/gcc -Istmlib/third_party/STM/STM32F10x_StdPeriph_Driver/inc -mcpu=cortex-m3 -mthumb -fno-unroll-loops -fno-exceptions -fno-rtti braids/drivers/adc.cc -o build/braids/adc.o
/usr/local/arm-4.8.3/bin/arm-none-eabi-g++ -c -g -O2 -Wall -Werror -Wno-unused-local-typedefs -fasm -finline -finline-functions-called-once -fdata-sections -ffunction-sections -fshort-enums -fno-move-loop-invariants -I. -DGCC_ARMCM3 -DSTM32F10X_MD -DAPPLICATION -DF_CPU=72000000L -DF_CRYSTAL=8000000L -DUSE_STDPERIPH_DRIVER -DSYSCLK_FREQ_72MHz=72000000L -Istmlib/third_party/STM -Istmlib/third_party/STM/CMSIS/CM3_f10x -Istmlib/third_party/STM/CMSIS/CM3_f10x/startup/gcc -Istmlib/third_party/STM/STM32F10x_StdPeriph_Driver/inc -mcpu=cortex-m3 -mthumb -fno-unroll-loops -fno-exceptions -fno-rtti braids/drivers/dac.cc -o build/braids/dac.o
/usr/local/arm-4.8.3/bin/arm-none-eabi-g++ -c -g -O2 -Wall -Werror -Wno-unused-local-typedefs -fasm -finline -finline-functions-called-once -fdata-sections -ffunction-sections -fshort-enums -fno-move-loop-invariants -I. -DGCC_ARMCM3 -DSTM32F10X_MD -DAPPLICATION -DF_CPU=72000000L -DF_CRYSTAL=8000000L -DUSE_STDPERIPH_DRIVER -DSYSCLK_FREQ_72MHz=72000000L -Istmlib/third_party/STM -Istmlib/third_party/STM/CMSIS/CM3_f10x -Istmlib/third_party/STM/CMSIS/CM3_f10x/startup/gcc -Istmlib/third_party/STM/STM32F10x_StdPeriph_Driver/inc -mcpu=cortex-m3 -mthumb -fno-unroll-loops -fno-exceptions -fno-rtti braids/drivers/debug_pin.cc -o build/braids/debug_pin.o
/usr/local/arm-4.8.3/bin/arm-none-eabi-g++ -c -g -O2 -Wall -Werror -Wno-unused-local-typedefs -fasm -finline -finline-functions-called-once -fdata-sections -ffunction-sections -fshort-enums -fno-move-loop-invariants -I. -DGCC_ARMCM3 -DSTM32F10X_MD -DAPPLICATION -DF_CPU=72000000L -DF_CRYSTAL=8000000L -DUSE_STDPERIPH_DRIVER -DSYSCLK_FREQ_72MHz=72000000L -Istmlib/third_party/STM -Istmlib/third_party/STM/CMSIS/CM3_f10x -Istmlib/third_party/STM/CMSIS/CM3_f10x/startup/gcc -Istmlib/third_party/STM/STM32F10x_StdPeriph_Driver/inc -mcpu=cortex-m3 -mthumb -fno-unroll-loops -fno-exceptions -fno-rtti braids/drivers/display.cc -o build/braids/display.o
/usr/local/arm-4.8.3/bin/arm-none-eabi-g++ -c -g -O2 -Wall -Werror -Wno-unused-local-typedefs -fasm -finline -finline-functions-called-once -fdata-sections -ffunction-sections -fshort-enums -fno-move-loop-invariants -I. -DGCC_ARMCM3 -DSTM32F10X_MD -DAPPLICATION -DF_CPU=72000000L -DF_CRYSTAL=8000000L -DUSE_STDPERIPH_DRIVER -DSYSCLK_FREQ_72MHz=72000000L -Istmlib/third_party/STM -Istmlib/third_party/STM/CMSIS/CM3_f10x -Istmlib/third_party/STM/CMSIS/CM3_f10x/startup/gcc -Istmlib/third_party/STM/STM32F10x_StdPeriph_Driver/inc -mcpu=cortex-m3 -mthumb -fno-unroll-loops -fno-exceptions -fno-rtti braids/drivers/encoder.cc -o build/braids/encoder.o
/usr/local/arm-4.8.3/bin/arm-none-eabi-g++ -c -g -O2 -Wall -Werror -Wno-unused-local-typedefs -fasm -finline -finline-functions-called-once -fdata-sections -ffunction-sections -fshort-enums -fno-move-loop-invariants -I. -DGCC_ARMCM3 -DSTM32F10X_MD -DAPPLICATION -DF_CPU=72000000L -DF_CRYSTAL=8000000L -DUSE_STDPERIPH_DRIVER -DSYSCLK_FREQ_72MHz=72000000L -Istmlib/third_party/STM -Istmlib/third_party/STM/CMSIS/CM3_f10x -Istmlib/third_party/STM/CMSIS/CM3_f10x/startup/gcc -Istmlib/third_party/STM/STM32F10x_StdPeriph_Driver/inc -mcpu=cortex-m3 -mthumb -fno-unroll-loops -fno-exceptions -fno-rtti braids/drivers/gate_input.cc -o build/braids/gate_input.o
/usr/local/arm-4.8.3/bin/arm-none-eabi-g++ -c -g -O2 -Wall -Werror -Wno-unused-local-typedefs -fasm -finline -finline-functions-called-once -fdata-sections -ffunction-sections -fshort-enums -fno-move-loop-invariants -I. -DGCC_ARMCM3 -DSTM32F10X_MD -DAPPLICATION -DF_CPU=72000000L -DF_CRYSTAL=8000000L -DUSE_STDPERIPH_DRIVER -DSYSCLK_FREQ_72MHz=72000000L -Istmlib/third_party/STM -Istmlib/third_party/STM/CMSIS/CM3_f10x -Istmlib/third_party/STM/CMSIS/CM3_f10x/startup/gcc -Istmlib/third_party/STM/STM32F10x_StdPeriph_Driver/inc -mcpu=cortex-m3 -mthumb -fno-unroll-loops -fno-exceptions -fno-rtti braids/drivers/internal_adc.cc -o build/braids/internal_adc.o
/usr/local/arm-4.8.3/bin/arm-none-eabi-g++ -c -g -O2 -Wall -Werror -Wno-unused-local-typedefs -fasm -finline -finline-functions-called-once -fdata-sections -ffunction-sections -fshort-enums -fno-move-loop-invariants -I. -DGCC_ARMCM3 -DSTM32F10X_MD -DAPPLICATION -DF_CPU=72000000L -DF_CRYSTAL=8000000L -DUSE_STDPERIPH_DRIVER -DSYSCLK_FREQ_72MHz=72000000L -Istmlib/third_party/STM -Istmlib/third_party/STM/CMSIS/CM3_f10x -Istmlib/third_party/STM/CMSIS/CM3_f10x/startup/gcc -Istmlib/third_party/STM/STM32F10x_StdPeriph_Driver/inc -mcpu=cortex-m3 -mthumb -fno-unroll-loops -fno-exceptions -fno-rtti braids/drivers/system.cc -o build/braids/system.o
/usr/local/arm-4.8.3/bin/arm-none-eabi-g++ -c -g -O2 -Wall -Werror -Wno-unused-local-typedefs -fasm -finline -finline-functions-called-once -fdata-sections -ffunction-sections -fshort-enums -fno-move-loop-invariants -I. -DGCC_ARMCM3 -DSTM32F10X_MD -DAPPLICATION -DF_CPU=72000000L -DF_CRYSTAL=8000000L -DUSE_STDPERIPH_DRIVER -DSYSCLK_FREQ_72MHz=72000000L -Istmlib/third_party/STM -Istmlib/third_party/STM/CMSIS/CM3_f10x -Istmlib/third_party/STM/CMSIS/CM3_f10x/startup/gcc -Istmlib/third_party/STM/STM32F10x_StdPeriph_Driver/inc -mcpu=cortex-m3 -mthumb -fno-unroll-loops -fno-exceptions -fno-rtti braids/drivers/uart_logger.cc -o build/braids/uart_logger.o
/usr/local/arm-4.8.3/bin/arm-none-eabi-g++ -c -g -O2 -Wall -Werror -Wno-unused-local-typedefs -fasm -finline -finline-functions-called-once -fdata-sections -ffunction-sections -fshort-enums -fno-move-loop-invariants -I. -DGCC_ARMCM3 -DSTM32F10X_MD -DAPPLICATION -DF_CPU=72000000L -DF_CRYSTAL=8000000L -DUSE_STDPERIPH_DRIVER -DSYSCLK_FREQ_72MHz=72000000L -Istmlib/third_party/STM -Istmlib/third_party/STM/CMSIS/CM3_f10x -Istmlib/third_party/STM/CMSIS/CM3_f10x/startup/gcc -Istmlib/third_party/STM/STM32F10x_StdPeriph_Driver/inc -mcpu=cortex-m3 -mthumb -fno-unroll-loops -fno-exceptions -fno-rtti stmlib/utils/random.cc -o build/braids/random.o
/usr/local/arm-4.8.3/bin/arm-none-eabi-g++ -c -g -O2 -Wall -Werror -Wno-unused-local-typedefs -fasm -finline -finline-functions-called-once -fdata-sections -ffunction-sections -fshort-enums -fno-move-loop-invariants -I. -DGCC_ARMCM3 -DSTM32F10X_MD -DAPPLICATION -DF_CPU=72000000L -DF_CRYSTAL=8000000L -DUSE_STDPERIPH_DRIVER -DSYSCLK_FREQ_72MHz=72000000L -Istmlib/third_party/STM -Istmlib/third_party/STM/CMSIS/CM3_f10x -Istmlib/third_party/STM/CMSIS/CM3_f10x/startup/gcc -Istmlib/third_party/STM/STM32F10x_StdPeriph_Driver/inc -mcpu=cortex-m3 -mthumb -fno-unroll-loops -fno-exceptions -fno-rtti stmlib/system/bootloader_utils.cc -o build/braids/bootloader_utils.o
/usr/local/arm-4.8.3/bin/arm-none-eabi-g++ -c -g -O2 -Wall -Werror -Wno-unused-local-typedefs -fasm -finline -finline-functions-called-once -fdata-sections -ffunction-sections -fshort-enums -fno-move-loop-invariants -I. -DGCC_ARMCM3 -DSTM32F10X_MD -DAPPLICATION -DF_CPU=72000000L -DF_CRYSTAL=8000000L -DUSE_STDPERIPH_DRIVER -DSYSCLK_FREQ_72MHz=72000000L -Istmlib/third_party/STM -Istmlib/third_party/STM/CMSIS/CM3_f10x -Istmlib/third_party/STM/CMSIS/CM3_f10x/startup/gcc -Istmlib/third_party/STM/STM32F10x_StdPeriph_Driver/inc -mcpu=cortex-m3 -mthumb -fno-unroll-loops -fno-exceptions -fno-rtti stmlib/system/system_clock.cc -o build/braids/system_clock.o
/usr/local/arm-4.8.3/bin/arm-none-eabi-gcc -c -g -O2 -Wall -Werror -Wno-unused-local-typedefs -fasm -finline -finline-functions-called-once -fdata-sections -ffunction-sections -fshort-enums -fno-move-loop-invariants -I. -DGCC_ARMCM3 -DSTM32F10X_MD -DAPPLICATION -DF_CPU=72000000L -DF_CRYSTAL=8000000L -DUSE_STDPERIPH_DRIVER -DSYSCLK_FREQ_72MHz=72000000L -Istmlib/third_party/STM -Istmlib/third_party/STM/CMSIS/CM3_f10x -Istmlib/third_party/STM/CMSIS/CM3_f10x/startup/gcc -Istmlib/third_party/STM/STM32F10x_StdPeriph_Driver/inc -mcpu=cortex-m3 -mthumb -fno-unroll-loops -std=c99 stmlib/third_party/STM/CMSIS/CM3_f10x/core_cm3.c -o build/braids/core_cm3.o
/usr/local/arm-4.8.3/bin/arm-none-eabi-gcc -c -g -O2 -Wall -Werror -Wno-unused-local-typedefs -fasm -finline -finline-functions-called-once -fdata-sections -ffunction-sections -fshort-enums -fno-move-loop-invariants -I. -DGCC_ARMCM3 -DSTM32F10X_MD -DAPPLICATION -DF_CPU=72000000L -DF_CRYSTAL=8000000L -DUSE_STDPERIPH_DRIVER -DSYSCLK_FREQ_72MHz=72000000L -Istmlib/third_party/STM -Istmlib/third_party/STM/CMSIS/CM3_f10x -Istmlib/third_party/STM/CMSIS/CM3_f10x/startup/gcc -Istmlib/third_party/STM/STM32F10x_StdPeriph_Driver/inc -mcpu=cortex-m3 -mthumb -fno-unroll-loops -std=c99 stmlib/third_party/STM/CMSIS/CM3_f10x/system_stm32f10x.c -o build/braids/system_stm32f10x.o
/usr/local/arm-4.8.3/bin/arm-none-eabi-gcc -c -g -O2 -Wall -Werror -Wno-unused-local-typedefs -fasm -finline -finline-functions-called-once -fdata-sections -ffunction-sections -fshort-enums -fno-move-loop-invariants -I. -DGCC_ARMCM3 -DSTM32F10X_MD -DAPPLICATION -DF_CPU=72000000L -DF_CRYSTAL=8000000L -DUSE_STDPERIPH_DRIVER -DSYSCLK_FREQ_72MHz=72000000L -Istmlib/third_party/STM -Istmlib/third_party/STM/CMSIS/CM3_f10x -Istmlib/third_party/STM/CMSIS/CM3_f10x/startup/gcc -Istmlib/third_party/STM/STM32F10x_StdPeriph_Driver/inc -mcpu=cortex-m3 -mthumb -fno-unroll-loops -std=c99 stmlib/third_party/STM/STM32F10x_StdPeriph_Driver/src/misc.c -o build/braids/misc.o
/usr/local/arm-4.8.3/bin/arm-none-eabi-gcc -c -g -O2 -Wall -Werror -Wno-unused-local-typedefs -fasm -finline -finline-functions-called-once -fdata-sections -ffunction-sections -fshort-enums -fno-move-loop-invariants -I. -DGCC_ARMCM3 -DSTM32F10X_MD -DAPPLICATION -DF_CPU=72000000L -DF_CRYSTAL=8000000L -DUSE_STDPERIPH_DRIVER -DSYSCLK_FREQ_72MHz=72000000L -Istmlib/third_party/STM -Istmlib/third_party/STM/CMSIS/CM3_f10x -Istmlib/third_party/STM/CMSIS/CM3_f10x/startup/gcc -Istmlib/third_party/STM/STM32F10x_StdPeriph_Driver/inc -mcpu=cortex-m3 -mthumb -fno-unroll-loops -std=c99 stmlib/third_party/STM/STM32F10x_StdPeriph_Driver/src/stm32f10x_adc.c -o build/braids/stm32f10x_adc.o
/usr/local/arm-4.8.3/bin/arm-none-eabi-gcc -c -g -O2 -Wall -Werror -Wno-unused-local-typedefs -fasm -finline -finline-functions-called-once -fdata-sections -ffunction-sections -fshort-enums -fno-move-loop-invariants -I. -DGCC_ARMCM3 -DSTM32F10X_MD -DAPPLICATION -DF_CPU=72000000L -DF_CRYSTAL=8000000L -DUSE_STDPERIPH_DRIVER -DSYSCLK_FREQ_72MHz=72000000L -Istmlib/third_party/STM -Istmlib/third_party/STM/CMSIS/CM3_f10x -Istmlib/third_party/STM/CMSIS/CM3_f10x/startup/gcc -Istmlib/third_party/STM/STM32F10x_StdPeriph_Driver/inc -mcpu=cortex-m3 -mthumb -fno-unroll-loops -std=c99 stmlib/third_party/STM/STM32F10x_StdPeriph_Driver/src/stm32f10x_bkp.c -o build/braids/stm32f10x_bkp.o
/usr/local/arm-4.8.3/bin/arm-none-eabi-gcc -c -g -O2 -Wall -Werror -Wno-unused-local-typedefs -fasm -finline -finline-functions-called-once -fdata-sections -ffunction-sections -fshort-enums -fno-move-loop-invariants -I. -DGCC_ARMCM3 -DSTM32F10X_MD -DAPPLICATION -DF_CPU=72000000L -DF_CRYSTAL=8000000L -DUSE_STDPERIPH_DRIVER -DSYSCLK_FREQ_72MHz=72000000L -Istmlib/third_party/STM -Istmlib/third_party/STM/CMSIS/CM3_f10x -Istmlib/third_party/STM/CMSIS/CM3_f10x/startup/gcc -Istmlib/third_party/STM/STM32F10x_StdPeriph_Driver/inc -mcpu=cortex-m3 -mthumb -fno-unroll-loops -std=c99 stmlib/third_party/STM/STM32F10x_StdPeriph_Driver/src/stm32f10x_can.c -o build/braids/stm32f10x_can.o
/usr/local/arm-4.8.3/bin/arm-none-eabi-gcc -c -g -O2 -Wall -Werror -Wno-unused-local-typedefs -fasm -finline -finline-functions-called-once -fdata-sections -ffunction-sections -fshort-enums -fno-move-loop-invariants -I. -DGCC_ARMCM3 -DSTM32F10X_MD -DAPPLICATION -DF_CPU=72000000L -DF_CRYSTAL=8000000L -DUSE_STDPERIPH_DRIVER -DSYSCLK_FREQ_72MHz=72000000L -Istmlib/third_party/STM -Istmlib/third_party/STM/CMSIS/CM3_f10x -Istmlib/third_party/STM/CMSIS/CM3_f10x/startup/gcc -Istmlib/third_party/STM/STM32F10x_StdPeriph_Driver/inc -mcpu=cortex-m3 -mthumb -fno-unroll-loops -std=c99 stmlib/third_party/STM/STM32F10x_StdPeriph_Driver/src/stm32f10x_crc.c -o build/braids/stm32f10x_crc.o
/usr/local/arm-4.8.3/bin/arm-none-eabi-gcc -c -g -O2 -Wall -Werror -Wno-unused-local-typedefs -fasm -finline -finline-functions-called-once -fdata-sections -ffunction-sections -fshort-enums -fno-move-loop-invariants -I. -DGCC_ARMCM3 -DSTM32F10X_MD -DAPPLICATION -DF_CPU=72000000L -DF_CRYSTAL=8000000L -DUSE_STDPERIPH_DRIVER -DSYSCLK_FREQ_72MHz=72000000L -Istmlib/third_party/STM -Istmlib/third_party/STM/CMSIS/CM3_f10x -Istmlib/third_party/STM/CMSIS/CM3_f10x/startup/gcc -Istmlib/third_party/STM/STM32F10x_StdPeriph_Driver/inc -mcpu=cortex-m3 -mthumb -fno-unroll-loops -std=c99 stmlib/third_party/STM/STM32F10x_StdPeriph_Driver/src/stm32f10x_dac.c -o build/braids/stm32f10x_dac.o
/usr/local/arm-4.8.3/bin/arm-none-eabi-gcc -c -g -O2 -Wall -Werror -Wno-unused-local-typedefs -fasm -finline -finline-functions-called-once -fdata-sections -ffunction-sections -fshort-enums -fno-move-loop-invariants -I. -DGCC_ARMCM3 -DSTM32F10X_MD -DAPPLICATION -DF_CPU=72000000L -DF_CRYSTAL=8000000L -DUSE_STDPERIPH_DRIVER -DSYSCLK_FREQ_72MHz=72000000L -Istmlib/third_party/STM -Istmlib/third_party/STM/CMSIS/CM3_f10x -Istmlib/third_party/STM/CMSIS/CM3_f10x/startup/gcc -Istmlib/third_party/STM/STM32F10x_StdPeriph_Driver/inc -mcpu=cortex-m3 -mthumb -fno-unroll-loops -std=c99 stmlib/third_party/STM/STM32F10x_StdPeriph_Driver/src/stm32f10x_dbgmcu .c -o build/braids/stm32f10x_dbgmcu.o
/usr/local/arm-4.8.3/bin/arm-none-eabi-gcc -c -g -O2 -Wall -Werror -Wno-unused-local-typedefs -fasm -finline -finline-functions-called-once -fdata-sections -ffunction-sections -fshort-enums -fno-move-loop-invariants -I. -DGCC_ARMCM3 -DSTM32F10X_MD -DAPPLICATION -DF_CPU=72000000L -DF_CRYSTAL=8000000L -DUSE_STDPERIPH_DRIVER -DSYSCLK_FREQ_72MHz=72000000L -Istmlib/third_party/STM -Istmlib/third_party/STM/CMSIS/CM3_f10x -Istmlib/third_party/STM/CMSIS/CM3_f10x/startup/gcc -Istmlib/third_party/STM/STM32F10x_StdPeriph_Driver/inc -mcpu=cortex-m3 -mthumb -fno-unroll-loops -std=c99 stmlib/third_party/STM/STM32F10x_StdPeriph_Driver/src/stm32f10x_dma.c -o build/braids/stm32f10x_dma.o
/usr/local/arm-4.8.3/bin/arm-none-eabi-gcc -c -g -O2 -Wall -Werror -Wno-unused-local-typedefs -fasm -finline -finline-functions-called-once -fdata-sections -ffunction-sections -fshort-enums -fno-move-loop-invariants -I. -DGCC_ARMCM3 -DSTM32F10X_MD -DAPPLICATION -DF_CPU=72000000L -DF_CRYSTAL=8000000L -DUSE_STDPERIPH_DRIVER -DSYSCLK_FREQ_72MHz=72000000L -Istmlib/third_party/STM -Istmlib/third_party/STM/CMSIS/CM3_f10x -Istmlib/third_party/STM/CMSIS/CM3_f10x/startup/gcc -Istmlib/third_party/STM/STM32F10x_StdPeriph_Driver/inc -mcpu=cortex-m3 -mthumb -fno-unroll-loops -std=c99 stmlib/third_party/STM/STM32F10x_StdPeriph_Driver/src/stm32f10x_exti.c -o build/braids/stm32f10x_exti.o
/usr/local/arm-4.8.3/bin/arm-none-eabi-gcc -c -g -O2 -Wall -Werror -Wno-unused-local-typedefs -fasm -finline -finline-functions-called-once -fdata-sections -ffunction-sections -fshort-enums -fno-move-loop-invariants -I. -DGCC_ARMCM3 -DSTM32F10X_MD -DAPPLICATION -DF_CPU=72000000L -DF_CRYSTAL=8000000L -DUSE_STDPERIPH_DRIVER -DSYSCLK_FREQ_72MHz=72000000L -Istmlib/third_party/STM -Istmlib/third_party/STM/CMSIS/CM3_f10x -Istmlib/third_party/STM/CMSIS/CM3_f10x/startup/gcc -Istmlib/third_party/STM/STM32F10x_StdPeriph_Driver/inc -mcpu=cortex-m3 -mthumb -fno-unroll-loops -std=c99 stmlib/third_party/STM/STM32F10x_StdPeriph_Driver/src/stm32f10x_flash. c -o build/braids/stm32f10x_flash.o
/usr/local/arm-4.8.3/bin/arm-none-eabi-gcc -c -g -O2 -Wall -Werror -Wno-unused-local-typedefs -fasm -finline -finline-functions-called-once -fdata-sections -ffunction-sections -fshort-enums -fno-move-loop-invariants -I. -DGCC_ARMCM3 -DSTM32F10X_MD -DAPPLICATION -DF_CPU=72000000L -DF_CRYSTAL=8000000L -DUSE_STDPERIPH_DRIVER -DSYSCLK_FREQ_72MHz=72000000L -Istmlib/third_party/STM -Istmlib/third_party/STM/CMSIS/CM3_f10x -Istmlib/third_party/STM/CMSIS/CM3_f10x/startup/gcc -Istmlib/third_party/STM/STM32F10x_StdPeriph_Driver/inc -mcpu=cortex-m3 -mthumb -fno-unroll-loops -std=c99 stmlib/third_party/STM/STM32F10x_StdPeriph_Driver/src/stm32f10x_fsmc.c -o build/braids/stm32f10x_fsmc.o
/usr/local/arm-4.8.3/bin/arm-none-eabi-gcc -c -g -O2 -Wall -Werror -Wno-unused-local-typedefs -fasm -finline -finline-functions-called-once -fdata-sections -ffunction-sections -fshort-enums -fno-move-loop-invariants -I. -DGCC_ARMCM3 -DSTM32F10X_MD -DAPPLICATION -DF_CPU=72000000L -DF_CRYSTAL=8000000L -DUSE_STDPERIPH_DRIVER -DSYSCLK_FREQ_72MHz=72000000L -Istmlib/third_party/STM -Istmlib/third_party/STM/CMSIS/CM3_f10x -Istmlib/third_party/STM/CMSIS/CM3_f10x/startup/gcc -Istmlib/third_party/STM/STM32F10x_StdPeriph_Driver/inc -mcpu=cortex-m3 -mthumb -fno-unroll-loops -std=c99 stmlib/third_party/STM/STM32F10x_StdPeriph_Driver/src/stm32f10x_gpio.c -o build/braids/stm32f10x_gpio.o
/usr/local/arm-4.8.3/bin/arm-none-eabi-gcc -c -g -O2 -Wall -Werror -Wno-unused-local-typedefs -fasm -finline -finline-functions-called-once -fdata-sections -ffunction-sections -fshort-enums -fno-move-loop-invariants -I. -DGCC_ARMCM3 -DSTM32F10X_MD -DAPPLICATION -DF_CPU=72000000L -DF_CRYSTAL=8000000L -DUSE_STDPERIPH_DRIVER -DSYSCLK_FREQ_72MHz=72000000L -Istmlib/third_party/STM -Istmlib/third_party/STM/CMSIS/CM3_f10x -Istmlib/third_party/STM/CMSIS/CM3_f10x/startup/gcc -Istmlib/third_party/STM/STM32F10x_StdPeriph_Driver/inc -mcpu=cortex-m3 -mthumb -fno-unroll-loops -std=c99 stmlib/third_party/STM/STM32F10x_StdPeriph_Driver/src/stm32f10x_i2c.c -o build/braids/stm32f10x_i2c.o
/usr/local/arm-4.8.3/bin/arm-none-eabi-gcc -c -g -O2 -Wall -Werror -Wno-unused-local-typedefs -fasm -finline -finline-functions-called-once -fdata-sections -ffunction-sections -fshort-enums -fno-move-loop-invariants -I. -DGCC_ARMCM3 -DSTM32F10X_MD -DAPPLICATION -DF_CPU=72000000L -DF_CRYSTAL=8000000L -DUSE_STDPERIPH_DRIVER -DSYSCLK_FREQ_72MHz=72000000L -Istmlib/third_party/STM -Istmlib/third_party/STM/CMSIS/CM3_f10x -Istmlib/third_party/STM/CMSIS/CM3_f10x/startup/gcc -Istmlib/third_party/STM/STM32F10x_StdPeriph_Driver/inc -mcpu=cortex-m3 -mthumb -fno-unroll-loops -std=c99 stmlib/third_party/STM/STM32F10x_StdPeriph_Driver/src/stm32f10x_iwdg.c -o build/braids/stm32f10x_iwdg.o
/usr/local/arm-4.8.3/bin/arm-none-eabi-gcc -c -g -O2 -Wall -Werror -Wno-unused-local-typedefs -fasm -finline -finline-functions-called-once -fdata-sections -ffunction-sections -fshort-enums -fno-move-loop-invariants -I. -DGCC_ARMCM3 -DSTM32F10X_MD -DAPPLICATION -DF_CPU=72000000L -DF_CRYSTAL=8000000L -DUSE_STDPERIPH_DRIVER -DSYSCLK_FREQ_72MHz=72000000L -Istmlib/third_party/STM -Istmlib/third_party/STM/CMSIS/CM3_f10x -Istmlib/third_party/STM/CMSIS/CM3_f10x/startup/gcc -Istmlib/third_party/STM/STM32F10x_StdPeriph_Driver/inc -mcpu=cortex-m3 -mthumb -fno-unroll-loops -std=c99 stmlib/third_party/STM/STM32F10x_StdPeriph_Driver/src/stm32f10x_pwr.c -o build/braids/stm32f10x_pwr.o
/usr/local/arm-4.8.3/bin/arm-none-eabi-gcc -c -g -O2 -Wall -Werror -Wno-unused-local-typedefs -fasm -finline -finline-functions-called-once -fdata-sections -ffunction-sections -fshort-enums -fno-move-loop-invariants -I. -DGCC_ARMCM3 -DSTM32F10X_MD -DAPPLICATION -DF_CPU=72000000L -DF_CRYSTAL=8000000L -DUSE_STDPERIPH_DRIVER -DSYSCLK_FREQ_72MHz=72000000L -Istmlib/third_party/STM -Istmlib/third_party/STM/CMSIS/CM3_f10x -Istmlib/third_party/STM/CMSIS/CM3_f10x/startup/gcc -Istmlib/third_party/STM/STM32F10x_StdPeriph_Driver/inc -mcpu=cortex-m3 -mthumb -fno-unroll-loops -std=c99 stmlib/third_party/STM/STM32F10x_StdPeriph_Driver/src/stm32f10x_rcc.c -o build/braids/stm32f10x_rcc.o
/usr/local/arm-4.8.3/bin/arm-none-eabi-gcc -c -g -O2 -Wall -Werror -Wno-unused-local-typedefs -fasm -finline -finline-functions-called-once -fdata-sections -ffunction-sections -fshort-enums -fno-move-loop-invariants -I. -DGCC_ARMCM3 -DSTM32F10X_MD -DAPPLICATION -DF_CPU=72000000L -DF_CRYSTAL=8000000L -DUSE_STDPERIPH_DRIVER -DSYSCLK_FREQ_72MHz=72000000L -Istmlib/third_party/STM -Istmlib/third_party/STM/CMSIS/CM3_f10x -Istmlib/third_party/STM/CMSIS/CM3_f10x/startup/gcc -Istmlib/third_party/STM/STM32F10x_StdPeriph_Driver/inc -mcpu=cortex-m3 -mthumb -fno-unroll-loops -std=c99 stmlib/third_party/STM/STM32F10x_StdPeriph_Driver/src/stm32f10x_rtc.c -o build/braids/stm32f10x_rtc.o
/usr/local/arm-4.8.3/bin/arm-none-eabi-gcc -c -g -O2 -Wall -Werror -Wno-unused-local-typedefs -fasm -finline -finline-functions-called-once -fdata-sections -ffunction-sections -fshort-enums -fno-move-loop-invariants -I. -DGCC_ARMCM3 -DSTM32F10X_MD -DAPPLICATION -DF_CPU=72000000L -DF_CRYSTAL=8000000L -DUSE_STDPERIPH_DRIVER -DSYSCLK_FREQ_72MHz=72000000L -Istmlib/third_party/STM -Istmlib/third_party/STM/CMSIS/CM3_f10x -Istmlib/third_party/STM/CMSIS/CM3_f10x/startup/gcc -Istmlib/third_party/STM/STM32F10x_StdPeriph_Driver/inc -mcpu=cortex-m3 -mthumb -fno-unroll-loops -std=c99 stmlib/third_party/STM/STM32F10x_StdPeriph_Driver/src/stm32f10x_sdio.c -o build/braids/stm32f10x_sdio.o
/usr/local/arm-4.8.3/bin/arm-none-eabi-gcc -c -g -O2 -Wall -Werror -Wno-unused-local-typedefs -fasm -finline -finline-functions-called-once -fdata-sections -ffunction-sections -fshort-enums -fno-move-loop-invariants -I. -DGCC_ARMCM3 -DSTM32F10X_MD -DAPPLICATION -DF_CPU=72000000L -DF_CRYSTAL=8000000L -DUSE_STDPERIPH_DRIVER -DSYSCLK_FREQ_72MHz=72000000L -Istmlib/third_party/STM -Istmlib/third_party/STM/CMSIS/CM3_f10x -Istmlib/third_party/STM/CMSIS/CM3_f10x/startup/gcc -Istmlib/third_party/STM/STM32F10x_StdPeriph_Driver/inc -mcpu=cortex-m3 -mthumb -fno-unroll-loops -std=c99 stmlib/third_party/STM/STM32F10x_StdPeriph_Driver/src/stm32f10x_spi.c -o build/braids/stm32f10x_spi.o
/usr/local/arm-4.8.3/bin/arm-none-eabi-gcc -c -g -O2 -Wall -Werror -Wno-unused-local-typedefs -fasm -finline -finline-functions-called-once -fdata-sections -ffunction-sections -fshort-enums -fno-move-loop-invariants -I. -DGCC_ARMCM3 -DSTM32F10X_MD -DAPPLICATION -DF_CPU=72000000L -DF_CRYSTAL=8000000L -DUSE_STDPERIPH_DRIVER -DSYSCLK_FREQ_72MHz=72000000L -Istmlib/third_party/STM -Istmlib/third_party/STM/CMSIS/CM3_f10x -Istmlib/third_party/STM/CMSIS/CM3_f10x/startup/gcc -Istmlib/third_party/STM/STM32F10x_StdPeriph_Driver/inc -mcpu=cortex-m3 -mthumb -fno-unroll-loops -std=c99 stmlib/third_party/STM/STM32F10x_StdPeriph_Driver/src/stm32f10x_tim.c -o build/braids/stm32f10x_tim.o
/usr/local/arm-4.8.3/bin/arm-none-eabi-gcc -c -g -O2 -Wall -Werror -Wno-unused-local-typedefs -fasm -finline -finline-functions-called-once -fdata-sections -ffunction-sections -fshort-enums -fno-move-loop-invariants -I. -DGCC_ARMCM3 -DSTM32F10X_MD -DAPPLICATION -DF_CPU=72000000L -DF_CRYSTAL=8000000L -DUSE_STDPERIPH_DRIVER -DSYSCLK_FREQ_72MHz=72000000L -Istmlib/third_party/STM -Istmlib/third_party/STM/CMSIS/CM3_f10x -Istmlib/third_party/STM/CMSIS/CM3_f10x/startup/gcc -Istmlib/third_party/STM/STM32F10x_StdPeriph_Driver/inc -mcpu=cortex-m3 -mthumb -fno-unroll-loops -std=c99 stmlib/third_party/STM/STM32F10x_StdPeriph_Driver/src/stm32f10x_usart. c -o build/braids/stm32f10x_usart.o
/usr/local/arm-4.8.3/bin/arm-none-eabi-gcc -c -g -O2 -Wall -Werror -Wno-unused-local-typedefs -fasm -finline -finline-functions-called-once -fdata-sections -ffunction-sections -fshort-enums -fno-move-loop-invariants -I. -DGCC_ARMCM3 -DSTM32F10X_MD -DAPPLICATION -DF_CPU=72000000L -DF_CRYSTAL=8000000L -DUSE_STDPERIPH_DRIVER -DSYSCLK_FREQ_72MHz=72000000L -Istmlib/third_party/STM -Istmlib/third_party/STM/CMSIS/CM3_f10x -Istmlib/third_party/STM/CMSIS/CM3_f10x/startup/gcc -Istmlib/third_party/STM/STM32F10x_StdPeriph_Driver/inc -mcpu=cortex-m3 -mthumb -fno-unroll-loops -std=c99 stmlib/third_party/STM/STM32F10x_StdPeriph_Driver/src/stm32f10x_wwdg.c -o build/braids/stm32f10x_wwdg.o
/usr/local/arm-4.8.3/bin/arm-none-eabi-gcc -c -x assembler-with-cpp -mcpu=cortex-m3 -mthumb -fno-unroll-loops stmlib/third_party/STM/CMSIS/CM3_f10x/startup/gcc/startup_stm32f10x_md .s -o build/braids/startup_stm32f10x_md.o
/usr/local/arm-4.8.3/bin/arm-none-eabi-gcc -Wl,-Map=build/braids/braids.map -Wl,--gc-sections -T stmlib/linker_scripts/stm32f10x_flash_md_application.ld -mcpu=cortex-m3 -mthumb -fno-unroll-loops -I. -DGCC_ARMCM3 -DSTM32F10X_MD -DAPPLICATION -DF_CPU=72000000L -DF_CRYSTAL=8000000L -DUSE_STDPERIPH_DRIVER -DSYSCLK_FREQ_72MHz=72000000L -Istmlib/third_party/STM -Istmlib/third_party/STM/CMSIS/CM3_f10x -Istmlib/third_party/STM/CMSIS/CM3_f10x/startup/gcc -Istmlib/third_party/STM/STM32F10x_StdPeriph_Driver/inc -Lstmlib/third_party/STM -o build/braids/braids.elf build/braids/analog_oscillator.o build/braids/braids.o build/braids/digital_oscillator.o build/braids/macro_oscillator.o build/braids/quantizer.o build/braids/resources.o build/braids/settings.o build/braids/ui.o build/braids/adc.o build/braids/dac.o build/braids/debug_pin.o build/braids/display.o build/braids/encoder.o build/braids/gate_input.o build/braids/internal_adc.o build/braids/system.o build/braids/uart_logger.o build/braids/random.o build/braids/bootloader_utils.o build/braids/system_clock.o build/braids/core_cm3.o build/braids/system_stm32f10x.o build/braids/misc.o build/braids/stm32f10x_adc.o build/braids/stm32f10x_bkp.o build/braids/stm32f10x_can.o build/braids/stm32f10x_crc.o build/braids/stm32f10x_dac.o build/braids/stm32f10x_dbgmcu.o build/braids/stm32f10x_dma.o build/braids/stm32f10x_exti.o build/braids/stm32f10x_flash.o build/braids/stm32f10x_fsmc.o build/braids/stm32f10x_gpio.o build/braids/stm32f10x_i2c.o build/braids/stm32f10x_iwdg.o build/braids/stm32f10x_pwr.o build/braids/stm32f10x_rcc.o build/braids/stm32f10x_rtc.o build/braids/stm32f10x_sdio.o build/braids/stm32f10x_spi.o build/braids/stm32f10x_tim.o build/braids/stm32f10x_usart.o build/braids/stm32f10x_wwdg.o build/braids/startup_stm32f10x_md.o
/usr/local/arm-4.8.3/bin/arm-none-eabi-objcopy -O ihex build/braids/braids.elf build/braids/braids.hex
cat build/braids/braids.hex build/braids_bootloader/braids_bootloader.hex | \
awk -f stmlib/programming/merge_hex.awk > build/braids/braids_bootloader_combo.hex
/usr/local/arm-4.8.3/bin/arm-none-eabi-objcopy -I ihex -O binary build/braids/braids_bootloader_combo.hex build/braids/braids_bootloader_combo.bin
openocd -f stmlib/programming/jtag/interface_stlink-v2.cfg -f stmlib/programming/jtag/stm32f10x_hla.cfg -f stmlib/programming/jtag/prelude_f10x.cfg -f stmlib/programming/jtag/erase_f10x.cfg -c "flash write_bank 0 build/braids/braids_bootloader_combo.bin 0x0" -c "verify_image buil
markfrancombe
Arghh hit some kind of word limit I guess...

Quote:
stmlib/programming/jtag/erase_f10x.cfg -c "flash write_bank 0 build/braids/braids_bootloader_combo.bin 0x0" -c "verify_image build/braids/braids_bootloader_combo.bin" -f stmlib/programming/jtag/postlude.cfg || openocd -f stmlib/programming/jtag/interface_stlink-v2.cfg -f stmlib/programming/jtag/stm32f10x_hla.cfg -f stmlib/programming/jtag/prelude_f10x.cfg -f stmlib/programming/jtag/erase_f10x.cfg -c "flash write_bank 0 build/braids/braids_bootloader_combo.bin 0x0" -c "verify_image build/braids/braids_bootloader_combo.bin" -f stmlib/programming/jtag/postlude.cfg
Open On-Chip Debugger 0.9.0 (2015-10-12-19:43)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
hla_jtag
adapter speed: 1000 kHz
adapter_nsrst_delay: 200
trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain connect_deassert_srst
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
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 v24 API v2 SWIM v4 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 3.213158
Info : stm32.cpu: hardware has 6 breakpoints, 4 watchpoints
target state: halted
target halted due to debug-request, current mode: Handler HardFault
xPSR: 0x01000003 pc: 0xfffffffe msp: 0xffffffdc
Info : device id = 0x20036410
Info : ignoring flash probed value, using configured bank size
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
Error: JTAG failure -4
Error: JTAG failure -4
Error: JTAG failure -4
Error: JTAG failure -4
Error: JTAG failure -4
Error: JTAG failure -4
Error: JTAG failure -4
Error: JTAG failure -4
Error: JTAG failure -4
Error: JTAG failure -4
Error: JTAG failure -4
Error: JTAG failure -4
Error: JTAG failure -4
Error: JTAG failure -4
Error: JTAG failure -4
Error: JTAG failure -4
Error: JTAG failure -4
target state: halted
target halted due to breakpoint, current mode: Handler HardFault
xPSR: 0x01000003 pc: 0x20000000 msp: 0xffffffdc
Error: JTAG failure -4
Error: error writing to flash at address 0x08000000 at offset 0x00000000

Open On-Chip Debugger 0.9.0 (2015-10-12-19:43)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
hla_jtag
adapter speed: 1000 kHz
adapter_nsrst_delay: 200
trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain connect_deassert_srst
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
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 v24 API v2 SWIM v4 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 3.192632
Error: init mode failed (unable to connect to the target)
in procedure 'init' called at file "stmlib/programming/jtag/prelude_f10x.cfg", line 23
in procedure 'ocd_bouncer'

make: *** [upload_combo_jtag] Error 1
gbiz
Well. It's not all bad. The MCU is alive & reporting the same id as one i've just done in a streams. It's reporting a sane voltage, & it's erased the flash.

Try this:

openocd -f interface/stlink-v2.cfg -f target/stm32f1x_stlink.cfg -c init -c halt -c "flash write_bank 0 build/braids/braids_bootloader_combo.bin 0x0"
markfrancombe
gbiz wrote:
Well. It's not all bad. The MCU is alive & reporting the same id as one i've just done in a streams. It's reporting a sane voltage, & it's erased the flash.

Try this:

openocd -f interface/stlink-v2.cfg -f target/stm32f1x_stlink.cfg -c init -c halt -c "flash write_bank 0 build/braids/braids_bootloader_combo.bin 0x0"


Thanks for that gbiz... I will give that a go later, incidentally, is this just ONE BIG command that I type in one go? And.. er, if its not to much to ask... What does it do?

AND IN OTHER NEWS and news that requires a Miley icon Miley Cyrus

CLOUDS NOW WORKS!!!!
I spent the day in a friends electronics workshop who "has the right gear!" A nice microscope and a flux pen and some titanium tweezers.. scraping out gunge from around the chip legs and re flowing horrible looking joints, and first we got the processor working again, nice pretty lights, but then I was getting very intermittent and deafening noise, not in any way related to the input signal. A few minutes more with the tweezers and I pulled out a tiny fleck, not visible to naked eye... from between the legs of one of the opamps, not sure if that was the total cause, but next power up, it worked!!!

Of course with a deep module like this, that Ive never owned before, I cant say if ALL operation is as it should be (input level DOES NOT bring the input down to zero, for example, is this normal?)
But its pitching ok, freezing ok, and blend knob OK, size of grains is doing its thing, the only knob Im not hearing much change from is the TEXTURE knob... But ill figure out, and read up how that should work and see if thats a thing.

So... of course I still have Braids to do.. but I would hereby like to thank

gbiz Guinness ftw!
bennelong.bicyclist Guinness ftw!
BARE BONES Guinness ftw!
adam Guinness ftw!
Altitude909 Guinness ftw!

I owe you all real Guinness if ever you are in Oslo!

I have learned my lessons from you guys, Good FLUX!!! and Good magnification, and good cleaning solution...!!

SO I guess Ill fit the panel on and head over to the Sucessful Mutable builds thread!

w00t

Mark
gbiz
markfrancombe wrote:
gbiz wrote:
Well. It's not all bad. The MCU is alive & reporting the same id as one i've just done in a streams. It's reporting a sane voltage, & it's erased the flash.

Try this:

openocd -f interface/stlink-v2.cfg -f target/stm32f1x_stlink.cfg -c init -c halt -c "flash write_bank 0 build/braids/braids_bootloader_combo.bin 0x0"


Thanks for that gbiz... I will give that a go later, incidentally, is this just ONE BIG command that I type in one go? And.. er, if its not to much to ask... What does it do?


Yes all that line, including the quotes !!.

It's most of the command that make runs to flash the binary, less a couple of configure options. I doubt it'll help, but it's worth a try.

I had a look at the com led on my stlink-v2 last night when i was flashing a Streams. Plug it in, it's red. Issue any openocd command to the target, it'll flash red/green during the command. Then it'll stay green. Any further commands, it'll flash red/green & then return to green. That was on a laptop running Linux natively.

markfrancombe wrote:

AND IN OTHER NEWS and news that requires a Miley icon Miley Cyrus

CLOUDS NOW WORKS!!!!
I spent the day in a friends electronics workshop who "has the right gear!" A nice microscope and a flux pen and some titanium tweezers.. scraping out gunge from around the chip legs and re flowing horrible looking joints, and first we got the processor working again, nice pretty lights, but then I was getting very intermittent and deafening noise, not in any way related to the input signal. A few minutes more with the tweezers and I pulled out a tiny fleck, not visible to naked eye... from between the legs of one of the opamps, not sure if that was the total cause, but next power up, it worked!!!

Of course with a deep module like this, that Ive never owned before, I cant say if ALL operation is as it should be (input level DOES NOT bring the input down to zero, for example, is this normal?)
But its pitching ok, freezing ok, and blend knob OK, size of grains is doing its thing, the only knob Im not hearing much change from is the TEXTURE knob... But ill figure out, and read up how that should work and see if thats a thing.

So... of course I still have Braids to do.. but I would hereby like to thank

gbiz Guinness ftw!
bennelong.bicyclist Guinness ftw!
BARE BONES Guinness ftw!
adam Guinness ftw!
Altitude909 Guinness ftw!

I owe you all real Guinness if ever you are in Oslo!

I have learned my lessons from you guys, Good FLUX!!! and Good magnification, and good cleaning solution...!!

SO I guess Ill fit the panel on and head over to the Sucessful Mutable builds thread!

w00t

Mark


screaming goo yo beer!
adam
glad to hear it came out ok smile
adam
Puzzler wrote:
adam wrote:
i guess it's pulsing quality might give a clue - something oscillating?


i thin reverberation just makes it very loud.

maybe the crystal is broken?!


was reading this yesterday - makes me wonder if one of the caps is the wrong value or is not working for whatever reason?

https://olimex.wordpress.com/2015/10/19/twitter-quiz-the-answer/
markfrancombe
Quote:
SO I guess Ill fit the panel on and head over to the Sucessful Mutable builds thread!


well of course I spoke too soon there of course, 20 minute play on it reveals some intermittent behavior, cant quite get to the bottom of it, or reproduce. Certainly one thing Ive notices the the DENSITY knob has some kind of middle weight to it... I hear stuff on end, and as I turn to middle it cuts out and then appears again towards the top end...

Weird thing is the intermitanness is not caused or helped by moving the board or any human interaction... Im playing Beethovens 5th from a RadioMusic module right now, with the verb mode. lovely... then crackle, it cuts out for a second and come back in...

GAH.. but Im not too distraught, this is a huge step... now its just normal trouble shooting... just back to the tweezers and cleaning I guess...
gbiz
markfrancombe wrote:
Quote:
SO I guess Ill fit the panel on and head over to the Sucessful Mutable builds thread!


well of course I spoke too soon there of course, 20 minute play on it reveals some intermittent behavior, cant quite get to the bottom of it, or reproduce. Certainly one thing Ive notices the the DENSITY knob has some kind of middle weight to it... I hear stuff on end, and as I turn to middle it cuts out and then appears again towards the top end...

Weird thing is the intermitanness is not caused or helped by moving the board or any human interaction... Im playing Beethovens 5th from a RadioMusic module right now, with the verb mode. lovely... then crackle, it cuts out for a second and come back in...

GAH.. but Im not too distraught, this is a huge step... now its just normal trouble shooting... just back to the tweezers and cleaning I guess...


I know you said that this intermittant behaviour can't be induced, but it sounds a lot like a dry joint. You might be able to find it by going round the board, whilst it's playing like that, & VERY gently tapping each component with a thin plastic or wood implement, in an attempt to induce the behaviour.

If you like the reverb with the default firmware, try flashing it with Parasites & give the Oliverb a go.
markfrancombe
gbiz wrote:


I know you said that this intermittant behaviour can't be induced, but it sounds a lot like a dry joint. You might be able to find it by going round the board, whilst it's playing like that, & VERY gently tapping each component with a thin plastic or wood implement, in an attempt to induce the behaviour.


Yeah I kinda tried that, but Ill do it again, but more methodically, thing is it was doing it even though I was sat at the other end of the room, one thing I can say is a I suspect stuff around the texture knob, that doesnt seem to do anything...
gbiz wrote:


If you like the reverb with the default firmware, try flashing it with Parasites & give the Oliverb a go.


I intend to, but I think Ill wait for a while, don't want to enter a new hole right now... That one I should be able to just load using audio file right? IM totally out of water with this VM method...
gbiz
markfrancombe wrote:
gbiz wrote:


I know you said that this intermittant behaviour can't be induced, but it sounds a lot like a dry joint. You might be able to find it by going round the board, whilst it's playing like that, & VERY gently tapping each component with a thin plastic or wood implement, in an attempt to induce the behaviour.


Yeah I kinda tried that, but Ill do it again, but more methodically, thing is it was doing it even though I was sat at the other end of the room, one thing I can say is a I suspect stuff around the texture knob, that doesnt seem to do anything...


The voltage from the wiper of the texture pot goes straight into the MCU. So check the pot itself has 3.3V on one outer leg, 0v on the other outer leg & the middle swings from 0V to 3.3V as you turn the pot. Then check you get the same voltage swing at p22 of the MCU, though that's going to be tricky given the pin spacing.

markfrancombe wrote:

gbiz wrote:


If you like the reverb with the default firmware, try flashing it with Parasites & give the Oliverb a go.


I intend to, but I think Ill wait for a while, don't want to enter a new hole right now... That one I should be able to just load using audio file right? IM totally out of water with this VM method...


Yeah, just play the wav into it, as documented in the Mutable manual. The level is quite critical, but you can use the LEDs as a level meter. LED4 just starting to indicate red works for me.

Now you have the bootloader in the MCU, you can easily revert back to the stock Mutable firmware using the same method.
makers
markfrancombe wrote:
Certainly one thing Ive notices the the DENSITY knob has some kind of middle weight to it... I hear stuff on end, and as I turn to middle it cuts out and then appears again towards the top end...


This is how Density is supposed to function. Texture adjustments will often be subtle in result. Now you've got life in he module, it's time to read the manual.
AlanP
makers wrote:
This is how Density is supposed to function. Texture adjustments will often be subtle in result. Now you've got life in he module, it's time to read the manual.


... but manuals are the very last port of call, after you've spent months trying to work out for yourself what "X" and "FIX" do!
jackmattson
Built Braids.

first trial revealed (probably) a short on the STM. LM117 3.3 was getting HOT.
Brought it to a pro at work and he says that now it's totally sitting fine (that chip).

LM1117 still gets HOT! and the STM gets warm.

+5v in on power. Check.
Power circuit soldered correctly (checking with beeper and .brb).

Is it possible that I fried something with the short that needs to be replaced?
Just suspicious that it's the same hot chip.

Tips?

(on a side note, just built two working Tides smile )
adam
might be a short somewhere else
Puzzler
Another Clouds issue:

Everything woprking fine except if the dry/wet is fully CW, you can still hear the dry sound, just in loudness reduced, appoximetly about -10db.

Retouched every joint, no success so far. MY ASS IS BLEEDING
adam
can you find the source of the noise with a scope?
Puzzler
No, but you might specify what kind of scope you are talking about. seriously, i just don't get it

Anf these are two different modules. One with the noise issue, the other one with the dry/wet issue.
adam
an oscilloscope - like if you can find out if it's there just after the dac for instance
BARE BONES
great news Mark!

I'm in Oslo end of Feb, i'll catch you for that Guinness then wink
magneticstripper
i wrote earlier about a similar issue with the clouds wet/dry knob. it seems to be a rolling offset, as if the max were reached and then it started going backwards. i checked the wiper voltage and it looked correct. could this be a voltage reference issue?
livefreela
@jackmattson - most certainly a short somewhere on the 3.3 volt rail. being that the stm is getting warm as well, that's where i'd check first. check the schematic and wick up the 3.3 lines headed to that chip. add some flux first. sometimes some excess solder can build up behind the pins eluding visual inspection. the side of the chip adjacent to the display looks most suspect. the good news is that in my experiences the stm survives these kind of shorts, though i have had to lift a few chips to clean up solder globbed up on the pads beneath. although in a few cases for me, sometimes an application of flux all around the chip and a pass with hot air was all it took...

also, troubleshooting/reworking these boards with pots/display/jacks etc is a huge pain in the ass. i've found waiting to install those parts until firmware is successfully uploaded/the board is running without anything getting hot can save a ton of aggravation.
adam
there has been one case where an elements acted erratically until the pots were installed - just something for people to keep in mind if modules are misbehaving after the firmwares uploaded and everything else seems fine
jackmattson
livefreela wrote:
@jackmattson - most certainly a short somewhere on the 3.3 volt rail. being that the stm is getting warm as well, that's where i'd check first. check the schematic and wick up the 3.3 lines headed to that chip. add some flux first. sometimes some excess solder can build up behind the pins eluding visual inspection. the side of the chip adjacent to the display looks most suspect. the good news is that in my experiences the stm survives these kind of shorts, though i have had to lift a few chips to clean up solder globbed up on the pads beneath. although in a few cases for me, sometimes an application of flux all around the chip and a pass with hot air was all it took...

also, troubleshooting/reworking these boards with pots/display/jacks etc is a huge pain in the ass. i've found waiting to install those parts until firmware is successfully uploaded/the board is running without anything getting hot can save a ton of aggravation.


Hey I think you are right about the 3.3 rail.
No idea though. I've mopped up that SMT 100 times. Even had a pro EE at work lift it and rework it. It's possible he didn't solve the problem, but I have confidence in him.
I've traced the (power) circuit. Everything is beeping in the right places. 3.5 (close enough) is coming out the right pin of the LM11117.
[Don't know if it's worth noting but I only had a 14 pin header so I chopped the Gate pins off my power on the board... 5 and 12's coming in fine though]
I thought maybe I shorted the LM1117 so I tried another. Still hot.
For kicks, I tried loading the firmware but couldn't get it to go into boot mode.
Once when I first plugged it in (and the STM was mostly like to have been shorted), I saw something on the LED's but haven't since.
I've reworked just about every part just poking with a hot iron and making sure it's all soaked up and connected but no change. Hmmmm.
So far every other project has been solvable so I'm pretty sure this one is too.
I'm about to make another parts order. Do you think it's worth replacing the F3?
adam
the problem isn't a loose connection - it's a solder connection between power and ground somewhere (as long as your chips, diodes etc are all the right way round), have you looked at the vias in case theres solder in any of them?

edit - i'll add check the ics with magnification in case there are bridges between any pins
jackmattson
@Adam
I hadn't! Didn't know that could short. But now I have. All clean.
adam
how about the ics with magnification in case there are bridges between any pins?
jackmattson
Done that. Everything in sight is good and has also been tested with beeper to make sure nothing is touching.
Actually double checked and I think the last two pins might be touching...
Watch this space.

So I'm getting beeps here and here. Are they connected internally?
adam
You need to be careful not to fry the stm with your multimeter
jackmattson
adam wrote:
You need to be careful not to fry the stm with your multimeter

Really? I always checked pin connections using the beep tool. Is there a better way?
The board isn't plugged in.
adam
Some setting on the meter send a voltage , can be too high for some things

Can you post a screenshot of that section of the brd file and schematic?

Both pins may be connected to gnd, looks like it from the photo
jackmattson
just checked and I think may be connected. hmmm... what else could it be?

left second from top is GND. Then VBAT +3
On the top far left is also VBAT +3 and beside it is PB2/BOOT1.
adam
Sounds like they shouldn't be connected, what does the schematic say?
AlanP
The highlighted pads and vias in the screenshot are GND, which are all tied to the groundplane. The ss doesn't have the groundplane displayed, but they are tied to it. Go to "Tools" then "Ratsnest" to display it.
gbiz
If that's the general state of the board then the first thing you need to do is give it a thorough clean. If you read back through these threads there's more than one post where people have had similar issues cured by cleaning the flux off the board.

It's really much better to be doing this before you put the pots & jacks on. You don't need those inplace to flash the MCU. They make cleaning & close inspection of the board almost impossible.
Puzzler
Additional info to the dry/wet problem:

When I press the "Blending parameter button" and switch to one of the other modes for the BLEND knob, then the expected 100% wet signal is there. Only in dry/wet mode it isnt. seriously, i just don't get it
jackmattson
Well had an engineer here at work take a look and we reflowed the whole board. Still hot.

We lifted the SMT and touched the pads I was getting beeps from and there was no shortcut (short circuit). We put it back on and the shortcut was back.

His assumption was that the chip had shorted internally. So we took it back off (thank god for the air pen!) and I'll order a new F3.

Thanks everyone for your help! I'll let you know if that works.
jackmattson
Puzzler, sounds like you might have messed up some soldering. Probably not the software which should either work or not work.
Can you post a clear picture of your board?
adam
jackmattson wrote:
Well had an engineer here at work take a look and we reflowed the whole board. Still hot.

We lifted the SMT and touched the pads I was getting beeps from and there was no shortcut (short circuit). We put it back on and the shortcut was back.

His assumption was that the chip had shorted internally. So we took it back off (thank god for the air pen!) and I'll order a new F3.

Thanks everyone for your help! I'll let you know if that works.


have you defluxed as gbiz suggested?
jackmattson
Yup. With hot hot air and isop.
adam
ok, that eliminates that, when you reflowed did you use some extra flux?
markfrancombe
gbiz wrote:
Well. It's not all bad. The MCU is alive & reporting the same id as one i've just done in a streams. It's reporting a sane voltage, & it's erased the flash.

Try this:

openocd -f interface/stlink-v2.cfg -f target/stm32f1x_stlink.cfg -c init -c halt -c "flash write_bank 0 build/braids/braids_bootloader_combo.bin 0x0"


Been having too much fun with clouds.
Finally got around to giving this a go @gbiz

This happened...


Quote:
vagrant@vagrant-ubuntu-trusty-64:/vagrant/eurorack-modules$ openocd -f interface/stlink-v2.cfg -f target/stm32f1x_stlink.cfg -c init -c halt -c "flash write_bank 0 build/braids/braids_bootloader_combo.bin 0x0"
Open On-Chip Debugger 0.9.0 (2015-10-12-19:43)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
WARNING: target/stm32f1x_stlink.cfg is deprecated, please switch to target/stm32f1x.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
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 v24 API v2 SWIM v4 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 3.189474
Error: init mode failed (unable to connect to the target)
in procedure 'init'
in procedure 'ocd_bouncer'


So I read the WARNING thing and tried to be clever, replacing target/stm32f1x_stlink.cfg WITH target/stm32f1x.cfg

With THIS result


Quote:

vagrant@vagrant-ubuntu-trusty-64:/vagrant/eurorack-modules$ openocd -f interface/stlink-v2.cfg -f target/stm32f1x.cfg -c init -c halt -c "flash write_bank 0 build/braids/braids_bootloader_combo.bin 0x0"
Open On-Chip Debugger 0.9.0 (2015-10-12-19:43)
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 <transport>'.
Info : The selected transport took over low-level target control. The results might 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 v24 API v2 SWIM v4 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 3.206842
Error: init mode failed (unable to connect to the target)
in procedure 'init'
in procedure 'ocd_bouncer'



So I dont think thats that...
Again... its this Cannot connect to target thing, which I was having with stLink Utility on the PC
gbiz
First thing, go back to using "make -f braids/makefile upload_combo_jtag" from now on.

google hits suggest it's an issue between the STLink dongle & the target. That could be either of the two cables, the adapter board, or i suppose the MCU also.

It's reporting the 3.3V voltage on Braids, so part of it is working. That would suggest that the USB connection to the STLink dongle is ok.
markfrancombe
gbiz wrote:
or i suppose the MCU also.


hmm... bummer..

ok I tried "make -f braids/makefile upload_combo_jtag"


Quote:
vagrant@vagrant-ubuntu-trusty-64:/vagrant/eurorack-modules$ make -f braids/makefile upload_combo_jtag
cat build/braids/analog_oscillator.d build/braids/braids.d build/braids/digital_oscillator.d build/braids/macro_oscillator.d build/braids/quantizer.d build/braids/resources.d build/braids/settings.d build/braids/ui.d build/braids/adc.d build/braids/dac.d build/braids/debug_pin.d build/braids/display.d build/braids/encoder.d build/braids/gate_input.d build/braids/internal_adc.d build/braids/system.d build/braids/uart_logger.d build/braids/random.d build/braids/bootloader_utils.d build/braids/system_clock.d build/braids/core_cm3.d build/braids/system_stm32f10x.d build/braids/misc.d build/braids/stm32f10x_adc.d build/braids/stm32f10x_bkp.d build/braids/stm32f10x_can.d build/braids/stm32f10x_crc.d build/braids/stm32f10x_dac.d build/braids/stm32f10x_dbgmcu.d build/braids/stm32f10x_dma.d build/braids/stm32f10x_exti.d build/braids/stm32f10x_flash.d build/braids/stm32f10x_fsmc.d build/braids/stm32f10x_gpio.d build/braids/stm32f10x_i2c.d build/braids/stm32f10x_iwdg.d build/braids/stm32f10x_pwr.d build/braids/stm32f10x_rcc.d build/braids/stm32f10x_rtc.d build/braids/stm32f10x_sdio.d build/braids/stm32f10x_spi.d build/braids/stm32f10x_tim.d build/braids/stm32f10x_usart.d build/braids/stm32f10x_wwdg.d build/braids/startup_stm32f10x_md.d > build/braids/depends.mk
make: Warning: File `build/braids/depends.mk' has modification time 4e+02 s in the future
openocd -f stmlib/programming/jtag/interface_stlink-v2.cfg -f stmlib/programming/jtag/stm32f10x_hla.cfg -f stmlib/programming/jtag/prelude_f10x.cfg -f stmlib/programming/jtag/erase_f10x.cfg -c "flash write_bank 0 build/braids/braids_bootloader_combo.bin 0x0" -c "verify_image build/braids/braids_bootloader_combo.bin" -f stmlib/programming/jtag/postlude.cfg || openocd -f stmlib/programming/jtag/interface_stlink-v2.cfg -f stmlib/programming/jtag/stm32f10x_hla.cfg -f stmlib/programming/jtag/prelude_f10x.cfg -f stmlib/programming/jtag/erase_f10x.cfg -c "flash write_bank 0 build/braids/braids_bootloader_combo.bin 0x0" -c "verify_image build/braids/braids_bootloader_combo.bin" -f stmlib/programming/jtag/postlude.cfg
Open On-Chip Debugger 0.9.0 (2015-10-12-19:43)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
hla_jtag
adapter speed: 1000 kHz
adapter_nsrst_delay: 200
trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain connect_deassert_srst
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
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 v24 API v2 SWIM v4 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 3.197369
Error: init mode failed (unable to connect to the target)
in procedure 'init' called at file "stmlib/programming/jtag/prelude_f10x.cfg", line 23
in procedure 'ocd_bouncer'

Open On-Chip Debugger 0.9.0 (2015-10-12-19:43)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
hla_jtag
adapter speed: 1000 kHz
adapter_nsrst_delay: 200
trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain connect_deassert_srst
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
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 v24 API v2 SWIM v4 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 3.195790
Error: init mode failed (unable to connect to the target)
in procedure 'init' called at file "stmlib/programming/jtag/prelude_f10x.cfg", line 23
in procedure 'ocd_bouncer'

make: *** [upload_combo_jtag] Error 1


Still this unable to connect...

So if what you are saying is that SOME of the connection to the mcu is ok, or else it wouldnt report 3.3, then I guess some other part isnt ok...

Back to solder bridges, reflowing and microscopes? Its what fixed the Clouds in the end... and much has been said of my flux on this thread... so...

(Really appreciating your help BTW gbiz...)
gbiz
TBH, I didn't expect it to work. Using make is pulling in some additional config files, & as a result it's correctly using hla_jtag. Without it's using hla_swd. I'd hate for that be cause some breakage later. My Fedora system here with a different version of openocd doesn't seem to need that.

Anyway. Yes. Go back to cleaning & inspecting. Sorry. cry
(Don't forget to inspect around the crystal too).

As it worked once, you might want to check that the cables from the STLink dongle to Braids are fully home. Try wiggling them. Maybe one has a loose crimp. (And this is Muffwiggler, it's what we do screaming goo yo ).
markfrancombe
gbiz wrote:

(Don't forget to inspect around the crystal too).

As it worked once, you might want to check that the cables from the STLink dongle to Braids are fully home. Try wiggling them. Maybe one has a loose crimp. (And this is Muffwiggler, it's what we do screaming goo yo ).


smile

Just out of interest, is there any particular reason why around the crystal is more important than.. I dunno.. around the 4 diodes?

OH! And before I forget, lets just get one thing sorted that I keep forgetting to ask. BECAUSE of the semi correct reading you say it gave above I have been routinely keeping the jtag cable around a particular way. Whats the RIGHT way...?
So I have the red stripe of the jtag cable aligned on the dongle so the red line is next to the white likne on the red adapter board. Then on Braids the red line is facing OUTWARDS, adjacent to the edge of the board...

The only reason I ask, actally this is probably BIG clue, I tried with the cable round the OTHER way, for a laugh (checked earlier in thread this wasnt dangerours) and got the same terminal spew... (I think) That to me would mean bad news...
markfrancombe
WAIT...new result...!

OK , so I thought about what you said about muffwiggling the cable, and checked the JTAG header itself, although I could see green board between all the pins, 2 of them looked a little "close" bit too much solder, so I Solder Braided (he he) them off, and tried the make command again... to this...
...interesting...
...result...

er.. wossit mean?

Quote:
vagrant@vagrant-ubuntu-trusty-64:/vagrant/eurorack-modules$ make -f braids/makefile upload_combo_jtag
openocd -f stmlib/programming/jtag/interface_stlink-v2.cfg -f stmlib/programming/jtag/stm32f10x_hla.cfg -f stmlib/programming/jtag/prelude_f10x.cfg -f stmlib/programming/jtag/erase_f10x.cfg -c "flash write_bank 0 build/braids/braids_bootloader_combo.bin 0x0" -c "verify_image build/braids/braids_bootloader_combo.bin" -f stmlib/programming/jtag/postlude.cfg || openocd -f stmlib/programming/jtag/interface_stlink-v2.cfg -f stmlib/programming/jtag/stm32f10x_hla.cfg -f stmlib/programming/jtag/prelude_f10x.cfg -f stmlib/programming/jtag/erase_f10x.cfg -c "flash write_bank 0 build/braids/braids_bootloader_combo.bin 0x0" -c "verify_image build/braids/braids_bootloader_combo.bin" -f stmlib/programming/jtag/postlude.cfg
Open On-Chip Debugger 0.9.0 (2015-10-12-19:43)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
hla_jtag
adapter speed: 1000 kHz
adapter_nsrst_delay: 200
trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain connect_deassert_srst
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
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 v24 API v2 SWIM v4 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 3.221053
Info : stm32.cpu: hardware has 6 breakpoints, 4 watchpoints
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x81000000 pc: 0x0800102e msp: 0x200003a8
Info : device id = 0x20036410
Info : ignoring flash probed value, using configured bank size
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
target state: halted
target halted due to breakpoint, current mode: Handler HardFault
xPSR: 0x61000003 pc: 0x2000003a msp: 0xffffffdc
wrote 116260 bytes from file build/braids/braids_bootloader_combo.bin to flash bank 0 at offset 0x00000000 in 4.108000s (27.638 KiB/s)
target state: halted
target halted due to breakpoint, current mode: Handler HardFault
xPSR: 0x61000003 pc: 0x2000002e msp: 0xffffffdc
verified 116260 bytes in 1.902147s (59.688 KiB/s)
in procedure 'reset' called at file "stmlib/programming/jtag/postlude.cfg", line 24
in procedure 'ocd_bouncer'


Open On-Chip Debugger 0.9.0 (2015-10-12-19:43)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
hla_jtag
adapter speed: 1000 kHz
adapter_nsrst_delay: 200
trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain connect_deassert_srst
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
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 v24 API v2 SWIM v4 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 3.214737
Info : stm32.cpu: hardware has 6 breakpoints, 4 watchpoints
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x81000000 pc: 0x0800102e msp: 0x200003a8
Info : device id = 0x20036410
Info : ignoring flash probed value, using configured bank size
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
target state: halted
target halted due to breakpoint, current mode: Handler HardFault
xPSR: 0x61000003 pc: 0x2000003a msp: 0xffffffdc
wrote 116260 bytes from file build/braids/braids_bootloader_combo.bin to flash bank 0 at offset 0x00000000 in 4.077152s (27.847 KiB/s)
target state: halted
target halted due to breakpoint, current mode: Handler HardFault
xPSR: 0x61000003 pc: 0x2000002e msp: 0xffffffdc
verified 116260 bytes in 1.911833s (59.385 KiB/s)
in procedure 'reset' called at file "stmlib/programming/jtag/postlude.cfg", line 24
in procedure 'ocd_bouncer'


make: *** [upload_combo_jtag] Error 1
gbiz
markfrancombe wrote:
gbiz wrote:

(Don't forget to inspect around the crystal too).

As it worked once, you might want to check that the cables from the STLink dongle to Braids are fully home. Try wiggling them. Maybe one has a loose crimp. (And this is Muffwiggler, it's what we do screaming goo yo ).


smile

Just out of interest, is there any particular reason why around the crystal is more important than.. I dunno.. around the 4 diodes?


Two things the MCU won't function without, power & a clock. JTAG is reporting that 3.3V is there, so it's safe to assume we have power. The crystal supplies the MCU's clock ...

markfrancombe wrote:


OH! And before I forget, lets just get one thing sorted that I keep forgetting to ask. BECAUSE of the semi correct reading you say it gave above I have been routinely keeping the jtag cable around a particular way. Whats the RIGHT way...?
So I have the red stripe of the jtag cable aligned on the dongle so the red line is next to the white likne on the red adapter board. Then on Braids the red line is facing OUTWARDS, adjacent to the edge of the board...

The only reason I ask, actally this is probably BIG clue, I tried with the cable round the OTHER way, for a laugh (checked earlier in thread this wasnt dangerours) and got the same terminal spew... (I think) That to me would mean bad news...


You probably didn't get the voltage reported though (i hope not anyway). Pin1 on the JTAG is used to detact the target Vcc (in this case 3.3V). It's the one thing that openocd *is* reporting correctly !.

Pin 1 on the JTAG on Braids is as you describe. It's the upper of the two pins on the side nearest the PCB edge. The top right pin as you're looking at the back of the board. If you're in any doubt, it's marked on the silk in the Eagle brd file.

I have the Sparkfun adapter PCB (a blue one). All the headers on the adapter board & the STLink/V2 are keyed so the cables can only be connected one way. With the cables plugged in & laid out flat with no twists, the red stripe is on the same side throughout.
gbiz
markfrancombe wrote:
WAIT...new result...!

OK , so I thought about what you said about muffwiggling the cable, and checked the JTAG header itself, although I could see green board between all the pins, 2 of them looked a little "close" bit too much solder, so I Solder Braided (he he) them off, and tried the make command again... to this...
...interesting...
...result...

er.. wossit mean?

Quote:
vagrant@vagrant-ubuntu-trusty-64:/vagrant/eurorack-modules$ make -f braids/makefile upload_combo_jtag
openocd -f stmlib/programming/jtag/interface_stlink-v2.cfg -f stmlib/programming/jtag/stm32f10x_hla.cfg -f stmlib/programming/jtag/prelude_f10x.cfg -f stmlib/programming/jtag/erase_f10x.cfg -c "flash write_bank 0 build/braids/braids_bootloader_combo.bin 0x0" -c "verify_image build/braids/braids_bootloader_combo.bin" -f stmlib/programming/jtag/postlude.cfg || openocd -f stmlib/programming/jtag/interface_stlink-v2.cfg -f stmlib/programming/jtag/stm32f10x_hla.cfg -f stmlib/programming/jtag/prelude_f10x.cfg -f stmlib/programming/jtag/erase_f10x.cfg -c "flash write_bank 0 build/braids/braids_bootloader_combo.bin 0x0" -c "verify_image build/braids/braids_bootloader_combo.bin" -f stmlib/programming/jtag/postlude.cfg
Open On-Chip Debugger 0.9.0 (2015-10-12-19:43)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
hla_jtag
adapter speed: 1000 kHz
adapter_nsrst_delay: 200
trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain connect_deassert_srst
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
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 v24 API v2 SWIM v4 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 3.221053
Info : stm32.cpu: hardware has 6 breakpoints, 4 watchpoints
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x81000000 pc: 0x0800102e msp: 0x200003a8
Info : device id = 0x20036410
Info : ignoring flash probed value, using configured bank size
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
target state: halted
target halted due to breakpoint, current mode: Handler HardFault
xPSR: 0x61000003 pc: 0x2000003a msp: 0xffffffdc
wrote 116260 bytes from file build/braids/braids_bootloader_combo.bin to flash bank 0 at offset 0x00000000 in 4.108000s (27.638 KiB/s)
target state: halted
target halted due to breakpoint, current mode: Handler HardFault
xPSR: 0x61000003 pc: 0x2000002e msp: 0xffffffdc
verified 116260 bytes in 1.902147s (59.688 KiB/s)
in procedure 'reset' called at file "stmlib/programming/jtag/postlude.cfg", line 24
in procedure 'ocd_bouncer'


Open On-Chip Debugger 0.9.0 (2015-10-12-19:43)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
hla_jtag
adapter speed: 1000 kHz
adapter_nsrst_delay: 200
trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain connect_deassert_srst
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
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 v24 API v2 SWIM v4 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 3.214737
Info : stm32.cpu: hardware has 6 breakpoints, 4 watchpoints
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x81000000 pc: 0x0800102e msp: 0x200003a8
Info : device id = 0x20036410
Info : ignoring flash probed value, using configured bank size
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
target state: halted
target halted due to breakpoint, current mode: Handler HardFault
xPSR: 0x61000003 pc: 0x2000003a msp: 0xffffffdc
wrote 116260 bytes from file build/braids/braids_bootloader_combo.bin to flash bank 0 at offset 0x00000000 in 4.077152s (27.847 KiB/s)
target state: halted
target halted due to breakpoint, current mode: Handler HardFault
xPSR: 0x61000003 pc: 0x2000002e msp: 0xffffffdc
verified 116260 bytes in 1.911833s (59.385 KiB/s)
in procedure 'reset' called at file "stmlib/programming/jtag/postlude.cfg", line 24
in procedure 'ocd_bouncer'


make: *** [upload_combo_jtag] Error 1


"wrote 116260 bytes from file build/braids/braids_bootloader_combo.bin to flash bank 0 at offset 0x00000000 in 4.077152s (27.847 KiB/s)"

It flashed the MCU screaming goo yo
Try resetting the board smile
AlanP
gbiz wrote:
I have the Sparkfun adapter PCB (a blue one). All the headers on the adapter board & the STLink/V2 are keyed so the cables can only be connected one way. With the cables plugged in & laid out flat with no twists, the red stripe is on the same side throughout.


I've got the Sparkfun adapter PCB as well. Be VERY careful to not hook the 5V line up to the braids board, or the 5V will fry the 3V3 silicon.

Don't ask how I know.
gbiz
AlanP wrote:
gbiz wrote:
I have the Sparkfun adapter PCB (a blue one). All the headers on the adapter board & the STLink/V2 are keyed so the cables can only be connected one way. With the cables plugged in & laid out flat with no twists, the red stripe is on the same side throughout.


I've got the Sparkfun adapter PCB as well. Be VERY careful to not hook the 5V line up to the braids board, or the 5V will fry the 3V3 silicon.

Don't ask how I know.


Sorry, i have to ask hihi

The Sparkfun Cortex SWD adapter board i have doesn't provide 5V. The only supply rail on the JTAG/SWD interfaces is Vref, which is supplied by the target.
markfrancombe
AlanP wrote:
Be VERY careful to not hook the 5V line up to the braids board, or the 5V will fry the 3V3 silicon.

Don't ask how I know.


Just to be VERY clear here, you are NOT talking about the 5v supply from the PSU right? Just 5v that your particular adaptor uses?

I was under the impression that Braids was "one of those modules" that needed 5v supply? Id be very surprised if it doesnt seeing as the connector is one of them big ones and actually has 5v marked on the header...

m
markfrancombe
gbiz wrote:

It flashed the MCU screaming goo yo
Try resetting the board smile


Well thats something, w00t but if you mean pressing the reset button, nada...

OK back to the magnifier! very frustrating
gbiz
markfrancombe wrote:
gbiz wrote:

It flashed the MCU screaming goo yo
Try resetting the board smile


Well thats something, w00t but if you mean pressing the reset button, nada...

OK back to the magnifier! very frustrating


I assume you mean the display doesn't show anything.
Do you get any sound out of it ?.
markfrancombe
gbiz wrote:


I assume you mean the display doesn't show anything.
Do you get any sound out of it ?.


no nothing, didnt concentrate too much on Braids tonight due to...
See next post :(
markfrancombe
I knew it was too good to be true, tonight Clouds developed a fault.
Strange cos last night I played ALL evening with it, I calibrated the 1v/o, and had LOTS of fun! (especially with low density and triggering individual grains.. lovely!)

Tonight, it had developed a fault. :( It had already been put in the synth rack, so it hadnt been moved since yesterday,I find it hard to believe that this is caused by a solder joint if it was working fine yesterday.

Basically, if the Blend parameter (first light on) is OFF, and the thru sound should be heard, its not, instead is a mid pitched, very low quality noise comes out, all the time, it might not have anything to do with the input audio at all (I unplugged the input) noise continues... If I turn the blend knob, the sound DOES change, but none of the knobs really do anything.

But its a bit intermittent, in fact after one power cycle it worked again, for a bit, but then reverted back to this noise. Also, occasionally there would be a really quick spurt of the original sound, almost like a grains worth...

Other odd behaviour was that the mode button was not so responsive.. hard to explain but yesterday a quick press of that button would easily take me thru the modes, today, although the LEDS would change, it seems somehow sluggish, I had to ait a second for the next LED to light before pressing again.

Tomorrow Ill probably shoot a quickie iPhone video to post

Anyway all in all a depressing night... Any clues would be highly appreciated...

Mark
gbiz
Bummer. And it was all going so well. waah

Check all the voltages are OK would be my first step - +3v3, +3v3_A, AREF_-10, Vcc, Vee.

Check nothing is getting hot.

But then i'd be reaching for the On button on the scope ...
markfrancombe
gbiz wrote:
Bummer. And it was all going so well. waah

Check all the voltages are OK would be my first step - +3v3, +3v3_A, AREF_-10, Vcc, Vee.

Check nothing is getting hot.

But then i'd be reaching for the On button on the scope ...


Yeah... Im afraid all thats stepping a bit out of my knowledge zone...

the 3.3 I can follow on eagle from the reg... the rest.. nah.. no idea what you are on aboot! And my scope is more for pretty squiggly patterns than anything (although it has been used to set up oscillators and wave folders...)

Check if things are getting hot.. OK I get that.. Ill start there
hihi
adam
Sounds like looking at scope tutorials online would help you out, you've got something to practice on at least wink
gbiz
Adam's suggestion is a good one.

Those are all supply or reference voltages used in Clouds. You can measure them at:
3v3_A analog supply on the tab on IC7 (in common with most of these Mutable designs there are dual 3.3V supply rails, one for the digital section & one for the analog section).
Vcc (+12V) on p3 IC7
Vee (-12v) & -10V analog reference on either side of R30

You really need to check not just that they're the correct voltage, but also there's no fluctuation on them. You can only really do that with a scope.
markfrancombe
gbiz wrote:
Adam's suggestion is a good one.

Absolutely... I'll do it... and check the stuff u said tomorrow. thx gbiz
AlanP
markfrancombe wrote:
Just to be VERY clear here, you are NOT talking about the 5v supply from the PSU right? Just 5v that your particular adaptor uses?


I meant the JTAG header power pin. It goes straight to the 3V3 line.
markfrancombe
Hey everyone! Clouds is working again.. Pffff!
Nope, did nothing... Theres one change... NORMAL pitch is full up on the pitch knob, so theres no tuning it higher except thru CV.

The day before yesterdays dismal evening I did configure Clouds using the sending C2 in adnthen C4 in as per the instructions, however Im not sure that I tested afterwards... could it be that my sequencer (Mobius is not sending C2 but I dunno what would it be, C5 there for Clouds thinks C5 is C2..
...or something...

Anyway... leaving running in athe background tonight,, see if it does something after heating up a bit.. if thats the issue..
gbiz
Quick !!!. Go back to working on your Braids. Maybe the same magic dust will get sprinkled on that hihi
markfrancombe
markfrancombe wrote:
see if it does something after heating up a bit.. if thats the issue..


Yep that was it... It went BAD again... Im gonna leave it switch off for a bit and re-try... so assuming Im right, which thingy is it likely to be thats overheating.. the MCU I would imagine to stop functioning, or operate weirdly (ahh but it did do that.. a bit ... maybe) where this is more an audio thing... the codec?

And @gbiz, I spose you were right that checking all the supply voltages is the thing here, if a chip is getting wee bit too much, it might function while is was cool... Im guessing here... Its not a fucking steam engine...
Anyway, idiots electroncics 101 tell me that, if a supply is getting too much then theres a resister either not functioning or not dampening (is that an electronics word) the voltage enough...
How am I doing...?
Stop me if Im causing pain from over-laughing..

Mark
gbiz
If it's heat related then you might be able to feel a component getting warm. But it might also be failing when it gets to room temperature but work at a lower temperature. Some of those components must have taken a bit of a battering with all that rework (sorry wink )

Can you easily cool the board back down to a temperature where it's working ?. Then use the heat from the end of your finger to heat up selected components to try & provoke it to fail. Freezer spray is expensive stuff, but it's invaluable in finding faults like this.

You were doing ok until that last sentence wink
livefreela
re: clouds - i'm gonna call another 3.3v short - this one of a trickier nature. i had a streams board that did a similar thing. worked for a few minutes than gradually descended into madness. i had a whisker short, apparently not great enough to drop the rail to ground but enough to "bleed out" the regulator over time - voltage at the regulator would creep down gradually and upon hitting a certain point either the stm or the dac would crap out (in this instance said crapping out sounded like a zippering noise of increasing magnitude - actually kind of neat, but i digress). once the whisker was tracked down (optivisor was insufficient - needed a loupe) the module worked perfectly....

though i must say mark, should mw ever formalize an award for "wiggler of remarkably deranged determination" i hereby nominate you for it! lesser folks would have given up on this kind of madness ages ago thumbs up
adam
in the olden days before solder masks people used to suggest running a knife between traces once soldering was all done to get rid of these
gbiz
Again, it's down to close inspection of your work with a decent magnifier, as you go. And to do that you have to clean your work.

(I wouldn't want to run a knife between the pads of the MCU on one of these boards hihi ).
adam
you'd have to use magnification wink
jackmattson
Quick update on my braids:
Swapped the Microprocessor and successfully flashed it. No pitch voltage on the Pitch CV to the processor. Pretty sure all the shenanigans fried IC4. Ordered a new on. ... in the mean time...

been successfully hacking the firmware..

Expect a few new features... need to get in touch with Oliver and Benjolin when it's cleaned up and tested.
Flights of Fancy?
bennelong.bicyclist
jackmattson wrote:
been successfully hacking the firmware..

Expect a few new features... need to get in touch with Oliver and Benjolin when it's cleaned up and tested.
Flights of Fancy?


Is your code up on GitHub (or equivalent) yet? If so, where? Just curious!
jackmattson
Little slow it git it. Still prototyping
markfrancombe
livefreela wrote:
"wiggler of remarkably deranged determination"


HA HA yes thanks.. thats me. No news on Braids yet still dark as a dark thing. But tonight I ran Clouds for 3 hours WITHOUT any problems, (but with lots of fun). To quote DeNiro in Brazil.. "its seems to have fixed itself".. or not.

Now I write this, I realise that today I wasnt ever using the trigger input, only CV, so I guess Ill try that tomorrow... but of course if it was a bit of solder debris, it might have fallen out now its been in the rack for a while...

Anyway... not calling it totally fixed yet, but maybe... soon...
The other thing might be that my PSU is nearing the end of it powering capabilities, and today I wasn't using a module that draws considerably when operational... if thats a thing... but cant think what that would be... maybe Klee... or Vectr... but todays test was lovely, wish you were here...

NOTE TO SELF, plug in your damn soundcard and record something...)
markfrancombe
OK to get this 100% correct, there is one adjustment that seems to have gone funky. (Stress tests so far seem to suggest my previous problem has cleared up- i probably just cleaned something)

The issue is that the pitch knob gives a "normal" pitch when fully clockwise, and will only pitch DOWNWARDS. The odd thing is that IM sure it was ok before. I believe the changed occurred after running the calibration routine as expressed on the MI website, that of pressing a button combo then feeding it a C2 and a C4 (1v and 3v respectively). This I did using my Mobius sequencer, rather than a midi keyboard, although I CAN use mobius as a Midi/CV converter.

So my question, is this calibration so wide, that a 1 v error (maybe Mobius is putting out 2v rather than 1 - its not BTW I checked, but still theoretically) that it can adjust the pitch knob a whole octave?

I can of course just "try it". but was wondering if anyone knew the answer to this, before wasting some .. er minutes)

Mark
AlanP
When I calibrated mine, I took a baby ten sequencer, changed the output and checked with the multimeter until I got 1.00V, then calibrated with that (adjusting for the 3.00V part, of course.)
markfrancombe
Well thats what I did, except I just sent a C2 and a C4... AND I checked with a multimeter too.. but .. I dunno... I MAY have made a mistake, it wouldnt be the first time... but can that calibration set the unit a whole octave out? or is it just setting scale between the 2 volts?
livefreela
i think it's possible this is a result of the inconsistencies in midi designations to 88 key reference (this is why they're swappable in most daws to account for different master keyboard makers). just hit the module with 1v and 3v - measure your sequencer with a meter until you have the appropriate target voltage. be precise. if the mobius' output is floating around, use something else. braids is sensitive! the calibration routine allows for the use of nonstandard 1v/oct voltage sources which is super useful, but this allows some room for confusion. also make sure your frequency and fine tune pots are centered when you perform the calibration. they act as offsets, so if one was cranked when you calibrated that would explain your wonky tracking.
condor13
Hello my name is Teodor from Romania.
Well...it`s not working. I re-flowed all the pins, no bridges. I connect StLink/v2 via SWD. To be more precise:
Pin1 - 3.3v
Pin2-JTMS - SWDIO
Pin3-JTCK - GND
Pin4 - SWCLK.
The led`s lit, but the utility St-Link doesn't detect the chip thus unable to upload.

I tried powering the board via 12v still the same.
Installed the toolchain and vagrant enviroment for compile. Stlinkv2 driver and utility. updated firmware on dongle. Nothing detected on utility.

LOG :
ST-Link/V2 device detected
Target voltage detected: 3.329715
Error getting target IDCODE: if SWD, check SWD connection
Error (4) while initializing ST-Link in SWD mode



If you guys have any idea what i should try next it would be much help
Best regards, Teodor.
markfrancombe
livefreela wrote:
also make sure your frequency and fine tune pots are centered when you perform the calibration. they act as offsets, so if one was cranked when you calibrated that would explain your wonky tracking.


Actually this is clouds Im talking about not Braids, but if its the same for clouds then I think you might have hit the nail on the head!

I got Elements today, so I was "otherwise engaged" but will give it a go WITH THE PITCH KNOB CENTRAL this time..

thanks

Mark
markfrancombe
condor13 wrote:

If you guys have any idea what i should try next it would be much help
Best regards, Teodor.


Hi Teodor, Im that last person to be able to help really, having had so much trouble myself, All I can say is.

Check your work, mine was horrible, and really came down to "grunge". Flux that had gotten wedged hard under things with all manner of shit in it. For example, you sure you got all your caps in? You MCU pic looks like you missed some components around the edge... maybe it doesn't matter when uploading, but...

I never got the PC program STLink to work, but, unless you are a programmer the Vagrant/Virtual box thing is a mysterious load of weirdness... I just asked many many questions and bugged the hell out of this thread... do back and have a look, maybe theres something for you there?

However, if you ARE having trouble with Vagrant, I can say one thing, did you edit the make file? Theres instructions on the Mutable github, but for you delectation and enjoyment, I made a little "cheat sheet" of everything I did. Here it is, beware, it may not sty here for ever...

https://docs.google.com/document/d/1OmkvM9Ez9zEDEnzvH3NhHN9J4158vynXNF 8WfyeDm78/edit?usp=sharing

It assumes you are an idiot, you may not be, if not, Im sorry... but I am and I did get clouds to work in the end...

good luck.. PS bigger close pics would be better too...

Mark
livefreela
yup - the same applies to clouds thumbs up

markfrancombe wrote:
livefreela wrote:
also make sure your frequency and fine tune pots are centered when you perform the calibration. they act as offsets, so if one was cranked when you calibrated that would explain your wonky tracking.


Actually this is clouds Im talking about not Braids, but if its the same for clouds then I think you might have hit the nail on the head!

I got Elements today, so I was "otherwise engaged" but will give it a go WITH THE PITCH KNOB CENTRAL this time..

thanks

Mark
livefreela
@condor13 - your pics appear to show the board in two stages of completion. on one, many of your capacitors are missing. are those in place when you are attempting to to upload the firmware? also - this board needs a cleaning. it is very hard to troubleshoot with all that flux in place. it's hard to tell, but it looks like you may have a short on the jtag header as well - this would certainly interfere with programming the chip.
bennelong.bicyclist
I've spotted the problem: there's a ten-legged alien robo-spider attached to your miniJTAG connector.

Seriously, as livefreela says, clean all the flux off the PCB. You have no hope of being able to properly inspect the solder joints when they are covered in flux residue. And the flux residue itself can cause problems. Much better to clean all the flux off before you mount the pots, jack sockets, switches etc, of course.
condor13
@markfrancombe Hey mark! Thanks. Great to hear you got your`s working. No problem setting up environment (well there were some set-backs but i managed, and a week later Olivier released the vagrant environment witch was mind blow) I will make some macro pictures with a camera after i clean it smile.
BTW i`m trying to use st-link utility. using the Chinese clone of st-link/v2

@livefreela The photos are progressive, i took a picture when i soldered the mcu then another when i finished.

@bennelong.bicyclist That giant robot spider got a haircut, and now its only 4 nice legged 2.54 pin pitch for SWD (it seemed like a good idea then, now i hate it). The flux is not conductive thus i thought id would not interfere, will clean the residue and will check again for bridges on my miniJTAG.

Thank you very much and will keep you posted.
Best regards, Teodor
bennelong.bicyclist
condor13 wrote:

@bennelong.bicyclist That giant robot spider got a haircut, and now its only 4 nice legged 2.54 pin pitch for SWD (it seemed like a good idea then, now i hate it). The flux is not conductive thus i thought id would not interfere, will clean the residue and will check again for bridges on my miniJTAG.


You can't check the MPU soldering unless all the flux is thoroughly cleaned off. Then use a 10x jeweller's loupe or similar to inspect your soldering. It is amazing what you find under magnification.
condor13
bennelong.bicyclist wrote:
condor13 wrote:

@bennelong.bicyclist That giant robot spider got a haircut, and now its only 4 nice legged 2.54 pin pitch for SWD (it seemed like a good idea then, now i hate it). The flux is not conductive thus i thought id would not interfere, will clean the residue and will check again for bridges on my miniJTAG.


You can't check the MPU soldering unless all the flux is thoroughly cleaned off. Then use a 10x jeweller's loupe or similar to inspect your soldering. It is amazing what you find under magnification.


Ok. Will do so smile. Will be back soon with good news, i hope smile
magneticstripper
After weeks of fussing with uploading and wiping and calibrating and recalibrating , i discovered that R11 (4.7ohm) was trashed. Replaced it, and, properer functionality. For your sanity, check R11 if you are having trouble with the blend functions. All the Best!
condor13
condor13 wrote:
bennelong.bicyclist wrote:
condor13 wrote:

@bennelong.bicyclist That giant robot spider got a haircut, and now its only 4 nice legged 2.54 pin pitch for SWD (it seemed like a good idea then, now i hate it). The flux is not conductive thus i thought id would not interfere, will clean the residue and will check again for bridges on my miniJTAG.


You can't check the MPU soldering unless all the flux is thoroughly cleaned off. Then use a 10x jeweller's loupe or similar to inspect your soldering. It is amazing what you find under magnification.


Ok. Will do so smile. Will be back soon with good news, i hope smile


I cleaned everything with ip alcohol. Still no sign of detecting. Will try with ftdi asap, kill the giant robot spider, and hopefully it wouldn't reach the dumpster. smile
gbiz
condor13 wrote:
condor13 wrote:
bennelong.bicyclist wrote:
condor13 wrote:

@bennelong.bicyclist That giant robot spider got a haircut, and now its only 4 nice legged 2.54 pin pitch for SWD (it seemed like a good idea then, now i hate it). The flux is not conductive thus i thought id would not interfere, will clean the residue and will check again for bridges on my miniJTAG.


You can't check the MPU soldering unless all the flux is thoroughly cleaned off. Then use a 10x jeweller's loupe or similar to inspect your soldering. It is amazing what you find under magnification.


Ok. Will do so smile. Will be back soon with good news, i hope smile


I cleaned everything with ip alcohol. Still no sign of detecting. Will try with ftdi asap, kill the giant robot spider, and hopefully it wouldn't reach the dumpster. smile


Some fresh hi-resolution pics now the board has been cleaned would be useful.
BARE BONES
magneticstripper wrote:
After weeks of fussing with uploading and wiping and calibrating and recalibrating , i discovered that R11 (4.7ohm) was trashed. Replaced it, and, properer functionality. For your sanity, check R11 if you are having trouble with the blend functions. All the Best!


how did you discover that R11 was the issue?
magneticstripper
i measured the resistance across R11. it had no continuity at all (as in burned through). think this was the first time i have burned out a resistor. Strange how the unit worked 80%.
nsir
Can anyone please post a picture of his/her finished streams pcb's?

thanks!
Puzzler
Just fyi I fixed the noisy Clouds by fully replacing the ARM Chip.
(After i had replaced all the other ICs without success ofc MY ASS IS BLEEDING )
adam
sounds frustrating
condor13
gbiz wrote:
condor13 wrote:
condor13 wrote:
bennelong.bicyclist wrote:
condor13 wrote:

@bennelong.bicyclist That giant robot spider got a haircut, and now its only 4 nice legged 2.54 pin pitch for SWD (it seemed like a good idea then, now i hate it). The flux is not conductive thus i thought id would not interfere, will clean the residue and will check again for bridges on my miniJTAG.


You can't check the MPU soldering unless all the flux is thoroughly cleaned off. Then use a 10x jeweller's loupe or similar to inspect your soldering. It is amazing what you find under magnification.


Ok. Will do so smile. Will be back soon with good news, i hope smile


I cleaned everything with ip alcohol. Still no sign of detecting. Will try with ftdi asap, kill the giant robot spider, and hopefully it wouldn't reach the dumpster. smile


Some fresh hi-resolution pics now the board has been cleaned would be useful.


Hello, sorry for the delay i was rearranging the house and every thing was in boxes smile soo..i got some higher quality photos. Dont mind the short between mcu and c19 its the same thing. Personaly dindt spoted any issues except that short with c19. Any ideas what to try?
reflow? any help will be appraciated smile. Thanks




gbiz
There's a lot of components that aren't aligned on the pads, eg C17, C24, C25, R40, R41 etc etc, Some might be fine, some might not be ... The MCU looks like it's mis-aligned on two sides. Some of the solder joints look like the solder hasn't flowed onto the pad eg R18, C40. One side of the crystal looks like the solder hasn't flowed onto the tab.

As bennelong.bicyclist advised, you really need to inspect it with a 10x loupe. That's going to be tricky now you have the panel components on there. You don't need them installed to flash the firmware. If I were working on this, i'd start by removing the pots so i could get the loupe in there for a closer inspection. It'll make the job of removing the components that do need re-aligning easier.
funkyjunky
hi all
I successfully compiled the bootloader and trying to upload a clouds bootloader to the module via ftdi dongle but have a weird error on “make -f /clouds/makefile upload_combo_serial":

stmlib/makefile.inc:220: recipe for target ‘build/clouds/stft.o’ failed
make: *** [build/clouds/stft.o] Error 1


any ideas?
pichenettes
Mistake on my side - made a change to a file that broke the build.

git pull origin master to get the latest source.
funkyjunky
pichenettes wrote:
Mistake on my side - made a change to a file that broke the build.

git pull origin master to get the latest source.


great, it helped but got another error:

python stmlib/programming/serial/stm32loader.py \
-p /dev/ttyUSB0 \
-b 115200 \
-e -v \
-w build/clouds/clouds_bootloader_combo.bin
Can't init. Ensure that BOOT0 is enabled and reset device
Traceback (most recent call last):
File "stmlib/programming/serial/stm32loader.py", line 413, in <module>
bootversion = cmd.cmdGet()
File "stmlib/programming/serial/stm32loader.py", line 106, in cmdGet
if self.cmdGeneric(0x00):
File "stmlib/programming/serial/stm32loader.py", line 103, in cmdGeneric
return self._wait_for_ack(hex(cmd))
File "stmlib/programming/serial/stm32loader.py", line 69, in _wait_for_ack
raise CmdException("No response to %s" % info)
__main__.CmdException: No response to 0x0
stmlib/makefile.inc:352: recipe for target 'upload_combo_serial' failed
make: *** [upload_combo_serial] Error 1


tried it several times, when I issue the make -f upload_serial_combo command led on ftdi flashes two time and after that it drops this error.

i've double checked that:
1) I pressed button combination correctly
2) ftdi has 3.3 v solder joint and 5 v trace cut
3) rx to tx and vice versa, gnd to gnd
4) module is connected to power rail , power is turned on

if I have hardware issue I ll try to make the upload procedure on my friend's diy module
bennelong.bicyclist
That may indicate that the MPU isn't running, due to a hardware error, which on a DIY build, could be just about anywhere. First step: inspect every single solder joint under at least 5x magnification (10x is better) under very bright illumination. An old stereo dissecting microscope is ideal, but a 10x jeweller's loupe will do. Make sure the board is completely clean of all flux, and completely dry, before inspecting - residual flux can hide tiny problems. Clean repeatedly with a toothbrush and 100% isopropyl alcohol (isopropanol, IPA), wear eye protection in case of splatter. Do not re-use toothbrush on your teeth. Post in-focus close up photos of your board here if you like, shot without a flash, but only if you have cleaned your board. Photos useless if there is flux everywhere obscuring the details. They need to be very close, high-res photos to be useful.

If inspection is OK, then get out your multimeter and test probes and check there is the expected voltages on the various power rails on the board, according to the schematic. Probe very carefully! You don't want to short anything out.
Swahananda
I've undertaken helping troubleshoot a run of clouds that all have various maladies. The current and closest to being up and running has the issues of "pitch knob" not-responding and sometimes it will sound like like pure tone coming through the outputs and the whole device freezes with whatever LED was lit. Now I've checked that I've got 3.3 everywhere the schematic says I should and I can read the swinging values of turning that pot at pin 9 on the STM. I've followed my +/-12 volt lines as well. My entire day was spent doing this and my brain is kind of mush at this point so pardon me if I haven't posted some of the obvious tests. Thanks a ton folks, it's time for a break. Eating is a thing we should do, solder fumes aren't as nutritious as I'd like.
jackmattson
Had about 10 successful builds now but hit a bump on one Elements.
When the Pitch and Geometry result in low frequencies, i get a (pretty cool) bit reduction. Any ideas?

ps Adam I know you are going to tell me to feed guys at work beer and würst but been bugging them enough and want to try a little here first.


To be clear, it sounds like the even the tail of the reverb gets digital when I set the pitch and geometry low and I can neaten it back up again buy twisting the knobs to higher settings.
jackmattson
Any ideas where the bit reduction comes from? I measured all the pots and they have the correct input output. I think it's the ADC_POTS munging of the 4051PW's (IC3,5,8,11).
pichenettes
CPU overload, probably from an incorrect firmware build.
jackmattson
pichenettes wrote:
CPU overload, probably from an incorrect firmware build.


Great news! easiest fix. smile

BTW I know you get this a lot but really, YOU ARE A SAINT!

Hope to meet you at DAFx or something like that one day.
jh0n
Having a problem with my first braids - got it built, programmed, booted, and everything seems to work fine, except the output is ALMOST nonexistent. Measures just 5mV or so peak to peak, but it's there. I can see the output at pins 3 and 4 of the 8551, verified that it's got 3.3 (3.4actual) and 2.5 (2.6 actual) at VDD and Vref. Trace the output through to the output, and the gain doesn't measurably change, except for just a few mV of DC offset.

If I understand the datasheet right, shouldn't the 8551 be amplifying more than that? Any ideas of what to trace down? Have measured most components in the signal path from the DAC output thru to the output jack, and all seem to be correct. I assume the DAC is doing it's job, since I've got output... replace the 072?

Thanks in advance.
adam
i'd have thought the dac would be at unbalanced line level (so 1-2v), but haven't checked the datasheet
BARE BONES
my latest Braids took the firmware fine, it boots up and the menu works normally but the pitch is super high you can hear the waves changing and the Timbre and Colour pots having some effect but the pitch, fine and FM knobs don't do anything.
Has anyone else had this issue?
jackmattson
Yep. I have that issue too. Haven't solved it but think it might be a flash issue
livefreela
are you getting the appropriate voltage at the the pots? sounds like something might be askew on the "aref-10" line....
livefreela
sounds like the signal is shorting to ground somewhere between the dac and j6... are you getting audio somewhere you shouldn't? (i.e. on the shell of the output jack) i would double check around the ic10 neighborhood - in particular c22 - i would see where tidying up the soldering around there gets you....

jh0n wrote:
Having a problem with my first braids - got it built, programmed, booted, and everything seems to work fine, except the output is ALMOST nonexistent. Measures just 5mV or so peak to peak, but it's there. I can see the output at pins 3 and 4 of the 8551, verified that it's got 3.3 (3.4actual) and 2.5 (2.6 actual) at VDD and Vref. Trace the output through to the output, and the gain doesn't measurably change, except for just a few mV of DC offset.

Thanks in advance.
jackmattson
livefreela wrote:
are you getting the appropriate voltage at the the pots? sounds like something might be askew on the "aref-10" line....

I am. And from the jacks into the ICs. Been a while since I touched it.
djamsia
jackmattson wrote:
Had about 10 successful builds now but hit a bump on one Elements.
When the Pitch and Geometry result in low frequencies, i get a (pretty cool) bit reduction. Any ideas?

ps Adam I know you are going to tell me to feed guys at work beer and würst but been bugging them enough and want to try a little here first.


To be clear, it sounds like the even the tail of the reverb gets digital when I set the pitch and geometry low and I can neaten it back up again buy twisting the knobs to higher settings.


I had a similar problem with my elements, I updated the firmware for this new,
http://mutable-instruments.net/modules/elements/firmware
and everything works fine !!! ...
djamsia
I have a little problem with my Yarns.
Apparently this well programmed via JTAG, but I cant see on the screen the digits, but snake boot-mode if it works and i can see the snake running .. I think there are more people with the same problem. What's the trick?

Thanks
djamsia
[quote="djamsia"]
jackmattson wrote:
Had about 10 successful builds now but hit a bump on one Elements.
When the Pitch and Geometry result in low frequencies, i get a (pretty cool) bit reduction. Any ideas?

ps Adam I know you are going to tell me to feed guys at work beer and würst but been bugging them enough and want to try a little here first.


To be clear, it sounds like the even the tail of the reverb gets digital when I set the pitch and geometry low and I can neaten it back up again buy twisting the knobs to higher settings.


I had a similar problem with my elements, I updated the firmware for this new,
http://mutable-instruments.net/modules/elements/firmware
and everything works fine !!! ...
condor13
gbiz wrote:
condor13 wrote:
condor13 wrote:
bennelong.bicyclist wrote:
condor13 wrote:

@bennelong.bicyclist That giant robot spider got a haircut, and now its only 4 nice legged 2.54 pin pitch for SWD (it seemed like a good idea then, now i hate it). The flux is not conductive thus i thought id would not interfere, will clean the residue and will check again for bridges on my miniJTAG.


You can't check the MPU soldering unless all the flux is thoroughly cleaned off. Then use a 10x jeweller's loupe or similar to inspect your soldering. It is amazing what you find under magnification.


Ok. Will do so smile. Will be back soon with good news, i hope smile


I cleaned everything with ip alcohol. Still no sign of detecting. Will try with ftdi asap, kill the giant robot spider, and hopefully it wouldn't reach the dumpster. smile


Some fresh hi-resolution pics now the board has been cleaned would be useful.



Hello, i`m back with fresh pics. Still didnt manage to get it working, but i seemed to spot a problem. the lm1117 (between the pots, near wm8713) its getting preeeeeety hot. And another odd behavior (i posted a video) when i touch the back of the pcb near the shift register for the leds, the turn off on..etc. I gave up the jtag connection, and go with ftdi, but it doesnt seem to go in to "bootloader limbo"

>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>Video<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<




Sorry for the beeing the n00b :(
Have a great day.
jackmattson
Condor, hard (for me) to tell but might you have a short on the left bottom side in the middle where the three traces come in from the bottom? You can use the beep mode on your multimeter and touch adjacent pads to see.
jackmattson
Ok trying to flash Elements again. I'm using an FTDI in Pichenette's vagrant.
Is the firmware there the ringified one?

I was able to flash it before, but it had issues (as mentioned a while back and Pichenette suggested reflashing). Now when I flash it I get
Quote:
Write 256 bytes at 0x800BC00
Traceback (most recent call last):
File "stmlib/programming/serial/stm32loader.py", line 428, in <module>
cmd.writeMemory(conf['address'], data)
File "stmlib/programming/serial/stm32loader.py", line 307, in writeMemory
self.cmdWriteMemory(addr, data[offs:offs+256])
File "stmlib/programming/serial/stm32loader.py", line 175, in cmdWriteMemory
if self.cmdGeneric(0x31):
File "stmlib/programming/serial/stm32loader.py", line 103, in cmdGeneric
return self._wait_for_ack(hex(cmd))
File "stmlib/programming/serial/stm32loader.py", line 69, in _wait_for_ack
raise CmdException("No response to %s" % info)
__main__.CmdException: No response to 0x31
make: *** [upload_combo_serial] Error 1
vagrant@vagrant-ubuntu-trusty-64:/vagrant/eurorack-modules$

Any ideas? It's a brand new FTDI that flashed a frames just now.
But I get a similar error with clouds at line
Write 256 bytes at 0x8003F00
Edit:
On clouds I just used hot air to take off the chip and reset it. Same error.
condor13
Great news everyone! we're not worthy Another working semi-Clouds. I say semi-working because, its not getting audio in (i presume).
Thanks jackmattson for the quick response. I cheked, no bridge there.
There was a faulty resistor 4k7 between the filter 47uF caps on positive rail. Replaced it with a normal resistor.
Flashed via swd using a cheap St-Link-v2(as ultrashock mentioned in one post) and St-Link Utility. Pretty straight forword, no reset/system boot buttons. Connected JTMS and JTCK (on clouds) to SWDIO and SWCLK (on st-link), and 3.3v and GND (powerd from rack to).Started St-Link Utility and immediately detected the chip, puted on auto mode and flashed bootloader and firmware combo and finised in 8.3sec. (wasted all this time for no more than 10s very frustrating )
>>>>>>>>>>>>>>>>VIDEO<<<<<<<<<<<<<<<<<<
But i`m getting no audio in.
As you can see in video, the leds should act like a spectrum but they do not. Pots, leds, buttons work, freeze button works (input cv for freze works). There is a trace of audio out. Gain and volume on mixer turned all the way up. I thought there`s problem with OUT but the "spectrum" leds tell otherwise. The lm1117 near the codec is still getting pretty hot Dead Banana . Dont worry about the cables i fucked up the jtag connection and had to improvise. JTCK and JTMS i soldered directly on chip but now i removed them.
Should i be loking for a ground conection or signal?
Should i get a scope?
Anyway i`ll look into it. screaming goo yo


Best regards, Teodor.
I`ll keep you posted love

BARE BONES
I have a Clouds with this same issue, where did you get the board?
insula
condor13 wrote:
Great news everyone! we're not worthy Another working semi-Clouds. I say semi-working because, its not getting audio in (i presume).
Thanks jackmattson for the quick response. I cheked, no bridge there.
There was a faulty resistor 4k7 between the filter 47uF caps on positive rail. Replaced it with a normal resistor.
Flashed via swd using a cheap St-Link-v2(as ultrashock mentioned in one post) and St-Link Utility. Pretty straight forword, no reset/system boot buttons. Connected JTMS and JTCK (on clouds) to SWDIO and SWCLK (on st-link), and 3.3v and GND (powerd from rack to).Started St-Link Utility and immediately detected the chip, puted on auto mode and flashed bootloader and firmware combo and finised in 8.3sec. (wasted all this time for no more than 10s very frustrating )
>>>>>>>>>>>>>>>>VIDEO<<<<<<<<<<<<<<<<<<
But i`m getting no audio in.
As you can see in video, the leds should act like a spectrum but they do not. Pots, leds, buttons work, freeze button works (input cv for freze works). There is a trace of audio out. Gain and volume on mixer turned all the way up. I thought there`s problem with OUT but the "spectrum" leds tell otherwise. The lm1117 near the codec is still getting pretty hot Dead Banana . Dont worry about the cables i fucked up the jtag connection and had to improvise. JTCK and JTMS i soldered directly on chip but now i removed them.
Should i be loking for a ground conection or signal?
Should i get a scope?
Anyway i`ll look into it. screaming goo yo


Best regards, Teodor.
I`ll keep you posted love



double check DAC output, maybe you have a bad solder at DAC pin (dac ic or cpu ic)

thumbs up
condor13
BARE BONES wrote:
I have a Clouds with this same issue, where did you get the board?


Got the board from Rob. Hope is just a coincidence smile
Checking tonight the input op-amp and codec soldering.
Keep you posted BARE BONES

Thanks everyone
insula
condor13 wrote:
BARE BONES wrote:
I have a Clouds with this same issue, where did you get the board?


Got the board from Rob. Hope is just a coincidence smile
Checking tonight the input op-amp and codec soldering.
Keep you posted BARE BONES

Thanks everyone


the pcb should be ok, check the pins between DAC and the ARM IC.

should be there the issue.
condor13
insula wrote:
condor13 wrote:
BARE BONES wrote:
I have a Clouds with this same issue, where did you get the board?


Got the board from Rob. Hope is just a coincidence smile
Checking tonight the input op-amp and codec soldering.
Keep you posted BARE BONES

Thanks everyone


the pcb should be ok, check the pins between DAC and the ARM IC.

should be there the issue.


Sure screaming goo yo there seems to be a cold solder there. i didn't manage to buy a 10x Lupe, using multiple lens and i have to get really close smile
djamsia
jackmattson wrote:
Ok trying to flash Elements again. I'm using an FTDI in Pichenette's vagrant.
Is the firmware there the ringified one?

I was able to flash it before, but it had issues (as mentioned a while back and Pichenette suggested reflashing). Now when I flash it I get
Quote:
Write 256 bytes at 0x800BC00
Traceback (most recent call last):
File "stmlib/programming/serial/stm32loader.py", line 428, in <module>
cmd.writeMemory(conf['address'], data)
File "stmlib/programming/serial/stm32loader.py", line 307, in writeMemory
self.cmdWriteMemory(addr, data[offs:offs+256])
File "stmlib/programming/serial/stm32loader.py", line 175, in cmdWriteMemory
if self.cmdGeneric(0x31):
File "stmlib/programming/serial/stm32loader.py", line 103, in cmdGeneric
return self._wait_for_ack(hex(cmd))
File "stmlib/programming/serial/stm32loader.py", line 69, in _wait_for_ack
raise CmdException("No response to %s" % info)
__main__.CmdException: No response to 0x31
make: *** [upload_combo_serial] Error 1
vagrant@vagrant-ubuntu-trusty-64:/vagrant/eurorack-modules$

Any ideas? It's a brand new FTDI that flashed a frames just now.
But I get a similar error with clouds at line
Write 256 bytes at 0x8003F00
Edit:
On clouds I just used hot air to take off the chip and reset it. Same error.


You can try to upload the new firmware via audio.
condor13
condor13 wrote:
insula wrote:
condor13 wrote:
BARE BONES wrote:
I have a Clouds with this same issue, where did you get the board?


Got the board from Rob. Hope is just a coincidence smile
Checking tonight the input op-amp and codec soldering.
Keep you posted BARE BONES

Thanks everyone


the pcb should be ok, check the pins between DAC and the ARM IC.

should be there the issue.


Sure screaming goo yo there seems to be a cold solder there. i didn't manage to buy a 10x Lupe, using multiple lens and i have to get really close smile


Checked all soldering. Refluxed. same issue.
Anyone?
Bruce2008
Hi guys, first attmp to build braids diy,
i do all, put power and charge the fw, the led is ok i can change parameters but haven't sound out.
At first check i find ic8 and ic9 mount inverted, unmount and put 2 new in the right sense but no sound, and if i try to do the upload to 1.8 fw nbraids don't get the signal.

Any idea?

thanks in advance
Bruce2008
i check with oscilloscope and signal arrive on ic9 pin 6 and from 7 to pin 2 but after on pin 1 i have always 12 Vdc

help please
Bruce2008
solve the problem of audio i mount inverted diode d1 & d3, now sound come out but now have problem with modulation and timbre, i have always 12 Vdc on ic8 pin 14........
Altitude909
Bruce2008 wrote:
solve the problem of audio i mount inverted diode d1 & d3, now sound come out but now have problem with modulation and timbre, i have always 12 Vdc on ic8 pin 14........


are you sure you have the opamp orientated correctly? You may have damaged the other opamp, it's input range is only 3V max
Bruce2008
op-amp are oriented in the right way, only the timbre and modulation don't work, the rest is perfect

tomorrow i'll replace the tl074cd and the AD8534ARZ and let you know
Altitude909
blindly changing parts wont do anything other than tear up your board. What happens on pin 13 when you change the timbre pot?
Bruce2008
tension on pin 13 change from 0,200 V to 0,070V is take from gnd to pin 13
Altitude909
post a pic of your IC8, none of that makes any sense number wise
Bruce2008
This is the best i can do
Altitude909
short between pins 2 and 3?
Bruce2008
check with tester no short, i check ic7 pin 13 there are 0,7 V,
in out of ic8 pin 14 have 12V and on ic7 pin 13 0,7, little bit strange


is normal have 24V in power supply of ic8?
livefreela
be very careful of using the beep tester on these modules unless you know exactly where you're probing. the voltage from your meter can easily zotz the semis on the low voltage rails.
Bruce2008
hi, thanks in advance for all get time to reply,

here the part of schematics where i have problem....

i have btw in out of pin 14 of tl074 -12 Vdc checked with gnd, on pin 13 a value from 0,07V to 0,200 V depend from pot R35.

btw pin 13 and 14 of ad8534 i have 0,7V and on C13 12V

i check:
R46 = 240 K
R39 & 29 = 52 K

thanks in advance
bennelong.bicyclist
You can't measure resistors in-situ without taking into account the rest of the circuit, which is complex.
Bruce2008
bennelong.bicyclist wrote:
You can't measure resistors in-situ without taking into account the rest of the circuit, which is complex.


hi, thanks for reply, what i can do for try to understand where is the problem? measure on?
bennelong.bicyclist
Almost all build failures of these modules are do to soldering issues or parts around the wrong way. Follow the advice in this and other threads: clean the PCB thoroughly, inspect soldering with a microscope or 10x loupe, check parts and orientation. Reverse engineering the entire circuit is difficult and you shouldn't expect anyone here to have time or skill to do that for you.

If all else fails, start again with a fresh PCB and set of parts.
davehoec
I have an issue with a Yarns build.
Calibration for Channels 1,3,4 is fine, but Channel 2 is pretty wrong.
Right at the start, the negative voltages were higher than the upper voltages.
the 7V point was close to 0V, while the -3V point was near 2V.
Even after dialing it back, I can't get any of the negative voltages to be negative. They won't go past 0V.
Again, all the other channels are fine.

Any ideas?
bennelong.bicyclist
davehoec wrote:
I have an issue with a Yarns build.
Calibration for Channels 1,3,4 is fine, but Channel 2 is pretty wrong.
Right at the start, the negative voltages were higher than the upper voltages.
the 7V point was close to 0V, while the -3V point was near 2V.
Even after dialing it back, I can't get any of the negative voltages to be negative. They won't go past 0V.
Again, all the other channels are fine.

Any ideas?


It is almost certainly a build error. Wrong part in wrong place? Something reversed? Soldering? Solder bridges somewhere?

Clean your PCB throughly, inspect all soldering under magnification (a 10x loupe or equivalent). Fix joints that don't look right. Pay particular attention to solder bridges on the MPU and DAC chips.

If al that fails, trace the circuit for CV 2 backwards from the output in Eagle (use the schematic) and examine every component involved again, especially the pins involved on the DAC and opamps.

If it still doesn't work, then consider breaking out the hot air gun and selectively replacing relevant components.

Of course, if you bought the PCB from a commercial supplier of Mutable PCBs, you should be seeking after-sales support from that supplier for your build.
davehoec
Yeah, I didn't purchase the PCB from anyone so there's no one to blame but myself. I had the board made at OSHPark.

There's just not that much that's unique to this channel:
3 resistors, 1 capacitor and 3 pins on the shared 4171 where all the other channels are working. Nothing that can be reversed as far as I can tell. The only other thing is the DAC output itself.

More than just getting it to work, I'm trying to understand what would cause it to work partially but just fail to scale the voltages and completely fail on the negative ones. I thought maybe the VREF wasn't right, but it seems to be the same as the other channels.

I'll clean it up again, and re-re-inspect. Hopefully something will turn up!
davehoec
Replaced the 4171 and I think it's good now. Not sure if it just bad joints or a bad IC but whichever... Thanks for the help.
bennelong.bicyclist
davehoec wrote:
Replaced the 4171 and I think it's good now. Not sure if it just bad joints or a bad IC but whichever... Thanks for the help.


No problem, glad it is working. Which reminds me, I need to finish the Yarns I am building which will have a nice blue LED display on a bright blue PCB behind a transparent sky blue acrylic panel.
funkyjunky
hi all
I built a clouds module and I thought it was working just fine, but noticed that the module responses to the knobs only in mix blend mode, in other modes knobs and cv are not functional with the mix set to 100 percent. The blend knob works in all blend modes and the led changes color from blank to red but the effect only applies when I switch to the NEXT blend mode and it applies in a very rude momentary fashion like it remembers setting but doesn apply immediately (cv also doesn't work). Also there is blend signal adds when I switch to feedback or reverb mode with 0 blend before. For example I set mix blend to 100 percent than I switch to feedback mode and suddenly feedback added but it was set to 0 and I didn't touch blend knobs. After that all the knobs become unresponsive, blend knob changes the led color but feedback remains at a constant value. Then I switch to reverb mode and suddenly moderate amount of reverb appears but it was set to 0 before and I didn't touch blend knob as before. At the same time there is feedback appears and it is set to that level that corresponds to the amount of blend I set in feedback mode (but it only applies in the next, verb mode). Then in verb mode I turn blend knob but nothing happens, all the knobs and cv are not working. I can set verb to 0 and it didn't change but after switching to next mix blend mode it disappears.

https://youtu.be/XE4hlDMl5SY

https://www.youtube.com/watch?v=5JLwQTqpKqA&feature=youtu.be

https://youtu.be/97dA8Vi0hjY


looks like I am having a problem with the blend knob or blend cv ...
I would very appreciate any help from you guys, you are my last hope smile
BARE BONES
bennelong.bicyclist wrote:
davehoec wrote:
Replaced the 4171 and I think it's good now. Not sure if it just bad joints or a bad IC but whichever... Thanks for the help.


No problem, glad it is working. Which reminds me, I need to finish the Yarns I am building which will have a nice blue LED display on a bright blue PCB behind a transparent sky blue acrylic panel.


where can you get blue displays?
bennelong.bicyclist
BARE BONES wrote:
bennelong.bicyclist wrote:
davehoec wrote:
Replaced the 4171 and I think it's good now. Not sure if it just bad joints or a bad IC but whichever... Thanks for the help.


No problem, glad it is working. Which reminds me, I need to finish the Yarns I am building which will have a nice blue LED display on a bright blue PCB behind a transparent sky blue acrylic panel.


where can you get blue displays?


https://www.adafruit.com/products/1908

They have other colours too.
BARE BONES
thanks
funkyjunky
funkyjunky wrote:
hi all
I built a clouds module and I thought it was working just fine, but noticed that the module responses to the knobs only in mix blend mode, in other modes knobs and cv are not functional with the mix set to 100 percent. The blend knob works in all blend modes and the led changes color from blank to red but the effect only applies when I switch to the NEXT blend mode and it applies in a very rude momentary fashion like it remembers setting but doesn apply immediately (cv also doesn't work). Also there is blend signal adds when I switch to feedback or reverb mode with 0 blend before. For example I set mix blend to 100 percent than I switch to feedback mode and suddenly feedback added but it was set to 0 and I didn't touch blend knobs. After that all the knobs become unresponsive, blend knob changes the led color but feedback remains at a constant value. Then I switch to reverb mode and suddenly moderate amount of reverb appears but it was set to 0 before and I didn't touch blend knob as before. At the same time there is feedback appears and it is set to that level that corresponds to the amount of blend I set in feedback mode (but it only applies in the next, verb mode). Then in verb mode I turn blend knob but nothing happens, all the knobs and cv are not working. I can set verb to 0 and it didn't change but after switching to next mix blend mode it disappears.

https://youtu.be/XE4hlDMl5SY

https://www.youtube.com/watch?v=5JLwQTqpKqA&feature=youtu.be

https://youtu.be/97dA8Vi0hjY


looks like I am having a problem with the blend knob or blend cv ...
I would very appreciate any help from you guys, you are my last hope smile


please help anyone or explain why I am not deserving any help? on mutable forum people said that DIY modules are not supported, here also no help... seriously, i just don't get it
livefreela
funky - a few things: yes, posting for diy help on the mutable forum will get you nowhere - olivier has asked on many occasions that diy questions be asked elsewhere. keeping mind how generous he's been with open sourcing his entire business, i think it's appropriate we respect that request.

all that said - let's try to get to the bottom of this misbehaving module. 99% of the problems with these modules come down to soldering errors which can manifest in any manner of weird symptoms. something is likely shorting somewhere so have a check for a few things...

anything getting hot when the module is powered on?
are you getting the appropriate voltages at the various power regulators?
what about at the pots?
do you have any good photos of the board itself? - the vids illustrate an unquestionably malfunctioning module but don't help much with getting to the bottom of the problem...
funkyjunky
livefreela wrote:

anything getting hot when the module is powered on?


i am afraid to touch anything with my fat fingers...

livefreela wrote:
are you getting the appropriate voltages at the various power regulators?
what about at the pots?

same - don't have much expirience in using multimeter with smt... afraid to shortcut


livefreela wrote:
do you have any good photos of the board itself? - the vids illustrate an unquestionably malfunctioning module but don't help much with getting to the bottom of the problem...



here are some photos. unfortunately I dont have a magnifier since one that I used during the build was borrowed from my friend and now has been returned back. I am going to buy one soon and can upload better photos through magnifier....










[/img]
bennelong.bicyclist
funkyjunky wrote:

please help anyone or explain why I am not deserving any help? on mutable forum people said that DIY modules are not supported, here also no help... seriously, i just don't get it


The MI eurorack designs are intended to be built by robots in factories (true!). Humans can build them by hand, but they are not beginner projects, and there is no build guide or documentation other than the Eagle files and a BOM. It is not easy to get right, and it takes painstaking care with putting the right parts in the right places, good soldering technique, and proper tools for inspection of your soldering (and isopropyl alcohol or similar to clean your PCB before inspection). Access to and knowledge of how to use basic troubleshooting tools such as a multimeter is essential.

If you bought your PCB from someone who is selling Mutable PCBs on a commercial basis, then you need to seek help from that vendor, who should have warned you and other customers before you bought the PCB of the nature of the MI eurorack designs - that they are not intended for DIY, and thus you need at the very minimum to be able to do the things I mentioned above to succeed.

If you had the PCB made yourself by an online PCB fabricator, then you are even more on your own.

However, people here will help as best they can. livefreela has already provided good advice - follow it. Get some 99% IPA (isopropanol) and a toothbrush and clean your PCB really well, multiple times (don't get IPA in the pots, wear eye protection, don't use the toothbrush on your teeth afterwards). Then inspect your soldering with a 10x jeweller's eye loupe or equivalent. Post high-res photos taken with a macro camera lens here if you like (the photos you posted above aren't good enough to be useful).

Failing that, then you may have put the wrong part in the wrong place. Errors with the chips are easy to spot, but the wrong 0603 size resistor or cap in the wrong place is hard or impossible to spot - that's why extreme care needs to be taken when building to get parts placement right the first time - there's no real second chance when unlabelled 0603 parts are involved (and remember, it was designed for assembly by robots, who don't make mistakes - you need to be just as accurate).

You might be able to find an expert to troubleshoot it for you, in person, but it may be costly, and you may need to just write it off to experience and try again (or not). It is unrealistic to expect a 100% success rate when DIY building these designs. For DIY builders with little SMD experience, a 50% success rate is probably a more realistic expectation.
funkyjunky
bennelong.bicyclist wrote:
funkyjunky wrote:

please help anyone or explain why I am not deserving any help? on mutable forum people said that DIY modules are not supported, here also no help... seriously, i just don't get it


The MI eurorack designs are intended to be built by robots in factories (true!). Humans can build them by hand, but they are not beginner projects, and there is no build guide or documentation other than the Eagle files and a BOM. It is not easy to get right, and it takes painstaking care with putting the right parts in the right places, good soldering technique, and proper tools for inspection of your soldering (and isopropyl alcohol or similar to clean your PCB before inspection). Access to and knowledge of how to use basic troubleshooting tools such as a multimeter is essential.

If you bought your PCB from someone who is selling Mutable PCBs on a commercial basis, then you need to seek help from that vendor, who should have warned you and other customers before you bought the PCB of the nature of the MI eurorack designs - that they are not intended for DIY, and thus you need at the very minimum to be able to do the things I mentioned above to succeed.

If you had the PCB made yourself by an online PCB fabricator, then you are even more on your own.

However, people here will help as best they can. livefreela has already provided good advice - follow it. Get some 99% IPA (isopropanol) and a toothbrush and clean your PCB really well, multiple times (don't get IPA in the pots, wear eye protection, don't use the toothbrush on your teeth afterwards). Then inspect your soldering with a 10x jeweller's eye loupe or equivalent. Post high-res photos taken with a macro camera lens here if you like (the photos you posted above aren't good enough to be useful).

Failing that, then you may have put the wrong part in the wrong place. Errors with the chips are easy to spot, but the wrong 0603 size resistor or cap in the wrong place is hard or impossible to spot - that's why extreme care needs to be taken when building to get parts placement right the first time - there's no real second chance when unlabelled 0603 parts are involved (and remember, it was designed for assembly by robots, who don't make mistakes - you need to be just as accurate).

You might be able to find an expert to troubleshoot it for you, in person, but it may be costly, and you may need to just write it off to experience and try again (or not). It is unrealistic to expect a 100% success rate when DIY building these designs. For DIY builders with little SMD experience, a 50% success rate is probably a more realistic expectation.


Thank you for such detailed reply. I am definitely going to buy 99% IPA and eye 10-15x loupe. I am pretty sure that I didn't make a mistake with components since I double checked everything before soldering.
I ll try to clean the board and touch every suspicious components. Also I bought 2 pcbs since I knew that there is a chance for such issue as I got now. After cleaning and double checking I'll post good quality pictures in case kind people have some spare time to watch for some obvious mistakes that my newbie eye didn't notice.

Have a nice weekend!
le_palace
bennelong.bicyclist wrote:
funkyjunky wrote:



its funny because YOU probably provide the most support on muffs for mutable diy hihi

just wanted to say thanks all for posting and sharing your knowledge. you're often times helping multiple people lurking on the thread (take me for example!)
bennelong.bicyclist
le_palace wrote:
bennelong.bicyclist wrote:
funkyjunky wrote:



its funny because YOU probably provide the most support on muffs for mutable diy hihi

just wanted to say thanks all for posting and sharing your knowledge. you're often times helping multiple people lurking on the thread (take me for example!)


Well, perhaps a while ago, but not so much lately - others have been providing more advice than me. In any case, the advice for the hardware builds is always the same: be incredibly careful to put the right part in the right place, because there is no second chance when dealing with unlabelled 0603 passives when it comes to detecting mistakes, once they are are in-circuit on the PCB, it is very hard to test them reliably; use proper no-clean flux (gel and/or flux pens), use very fine sold <0.5mm), don't use rosin-core solder (too hard to clean), clean the no-clean flux and inspect every solder joint, as you go, and then re-clean and double and triple check, and use proper magnification to check - the naked eye is not good enough. Load firmware before soldering the jack sockets and pots and switches and LEDs, because re-inspection and desoldering is much easier at that stage. And be prepared to fail, so always buy two or three PCBs for each design and expect to need to use the second or even third one before you end up with a working module, especially at first (the corollary is that you should not expect to save money doing DIY builds of just one or two MI modules, compared to buying factory-built ones).

I must admit to feeling great irritation with people who have set up little businesses selling these Mutable PCBs, without providing proper advice about what is involved in building them, and without advising potential buyers of the PCBs what the realistic failure rate of such DIY builds is, and without providing any form of build guide or documentation, and without any form of regular or organised after-sales support, relying instead on the goodwill of others in this and related forums to help out their hapless customers. And that's just the hardware. Then there are the firmware flashing issues - same applies. I feel sorry for people buying such PCBs without realising what is involved due to insufficient pre-sales information. Obviously, if you have a Mutable PCB made yourself via OSH Park or similar online PCB fabricators, then it is up to you to research all these issues, but if someone is selling the PCBs commercially, then they have a duty of care to tell customers all these things, and to provide organised after-sales support, or at least make it very clear that there is no support.
jackmattson
Hey guys, moving on to my 12th or so build and doing Jtag for the first time.

I'm flashing (trying to) yarns, using a stlink v2 on my discovery with pattern agents adapter.
I'm using the official vagrant (which I've used successfully with FTDI before) and have successfully made the bootloader and hex with the default commands.

I'm getting an error when I upload. I just want to double check I'm doing it right.

Here is my physical setup

Here's my console readout:
Quote:
vagrant@vagrant-ubuntu-trusty-64:/vagrant/eurorack-modules$ PGM_INTERFACE=stlink-v2 make -f yarns/makefile upload
openocd -f stmlib/programming/jtag/interface_stlink-v2.cfg -f stmlib/programming/jtag/stm32f10x_jtag.cfg -f stmlib/programming/jtag/prelude_f10x.cfg -f stmlib/programming/jtag/erase_f10x.cfg -c "flash write_bank 0 build/yarns/yarns_bootloader_combo.bin 0x0" -c "verify_image build/yarns/yarns_bootloader_combo.bin" -f stmlib/programming/jtag/postlude.cfg || openocd -f stmlib/programming/jtag/interface_stlink-v2.cfg -f stmlib/programming/jtag/stm32f10x_jtag.cfg -f stmlib/programming/jtag/prelude_f10x.cfg -f stmlib/programming/jtag/erase_f10x.cfg -c "flash write_bank 0 build/yarns/yarns_bootloader_combo.bin 0x0" -c "verify_image build/yarns/yarns_bootloader_combo.bin" -f stmlib/programming/jtag/postlude.cfg
Open On-Chip Debugger 0.9.0 (2016-01-29-01:07)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
hla_jtag
adapter speed: 1000 kHz
adapter_nsrst_delay: 200
trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain connect_deassert_srst
stmlib/programming/jtag/stm32f10x_jtag.cfg:43: Error: invalid subcommand "newtap stm32 cpu -irlen 4 -ircapture 0x1 -irmask 0xf -expected-id 0x3ba00477"
in procedure 'script'
at file "embedded:startup.tcl", line 60
in procedure 'jtag' called at file "stmlib/programming/jtag/stm32f10x_jtag.cfg", line 43
Open On-Chip Debugger 0.9.0 (2016-01-29-01:07)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
hla_jtag
adapter speed: 1000 kHz
adapter_nsrst_delay: 200
trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain connect_deassert_srst
stmlib/programming/jtag/stm32f10x_jtag.cfg:43: Error: invalid subcommand "newtap stm32 cpu -irlen 4 -ircapture 0x1 -irmask 0xf -expected-id 0x3ba00477"
in procedure 'script'
at file "embedded:startup.tcl", line 60
in procedure 'jtag' called at file "stmlib/programming/jtag/stm32f10x_jtag.cfg", line 43
make: *** [upload_combo_jtag] Error 1

That first line I assumed following this link from Pinchenettes
mxmxmx
never used vagrant, so can't be of any help there...

but the adapter should probably go the other way round. the white dot next to the SWD header is VDD. on Yarns, VDD is pin 1, it also has a litte white indicator next to it.

and, to use the discovery board as a programmer/debugger you have to remove the two jumpers where it says ST link (CN3)
bennelong.bicyclist
jackmattson wrote:
Hey guys, moving on to my 12th or so build and doing Jtag for the first time.

I'm flashing (trying to) yarns, using a stlink v2 on my discovery with pattern agents adapter.
I'm using the official vagrant (which I've used successfully with FTDI before) and have successfully made the bootloader and hex with the default commands.

I'm getting an error when I upload. I just want to double check I'm doing it right.


You have three possible sources of error: 1) your previously untested DIY Yarns hardware build; 2) your previously untested JTAG interface via your STM32F4 Discovery board (you said you used FTDI previously); and 3) the build environment and scripts. Source 3 is possible but quite unlikely - I am pretty sure others have successfully flashed Yarns firmware using the vagrant VM. I am build a few Yarns myself, but am not yet ready to flash the firmware, so I can't personally confirm, but in general, a mistake by Olivier is the least likely cause, by far.

So why not eliminate source of error 2 by using your JTAG interface and vagrant VM to re-flash firmware on a known-to-be-good MI module? If that works, then source of error 1 is more likely. If it doesn't work, then you will need to do some research using google to find out what the OpenOCD newtap command does, and whether it is being called correctly by the make script.

You have correct specified your JTAG interface? I see that make knows to use an HLA interface, but have you also specified in your environment export PGM_INTERFACE=stlink-v2"?
bennelong.bicyclist
mxmxmx wrote:
never used vagrant, so can't be of any help there...

but the adapter should probably go the other way round. the white dot next to the SWD header is VDD. on Yarns, VDD is pin 1, it also has a litte white indicator next to it.

and, to use the discovery board as a programmer/debugger you have to remove the two jumpers where it says ST link (CN3)


D'oh! Max is 100% correct. With the jumpers on the Discovery board set as they are, you are currently trying to program the STM32F4 on the Discovery board, not the STM32F1 chip on your Yarns. No wonder it isn't working!

Also, check section 6.1.5 in this document: http://www.st.com/st-web-ui/static/active/en/resource/technical/docume nt/user_manual/DM00039084.pdf and then check the Yarns PCB and schematics in Eagle, to make sure you have the connectors around the right way.
jackmattson
Thanks mxmxmx.
I see now that on my particular board I need both jumpers off.
I think I was missing a step that the st link driver needs to be installed... struggling through that now.
Testing by trying to connect to the discovery arm...
le_palace
bennelong.bicyclist wrote:
...you should not expect to save money doing DIY builds of just one or two MI modules, compared to buying factory-built ones....


i think thats wise advice. theres a great difference in self motivation between those who are actually interested in the circuits vs. those who just want a cheap MI module
jackmattson
jackmattson wrote:
Thanks mxmxmx.
I see now that on my particular board I need both jumpers off.
I think I was missing a step that the st link driver needs to be installed... struggling through that now.
Testing by trying to connect to the discovery arm...

Well no luck.
I cloned and followed this (I'm on mac)
https://github.com/texane/stlink

I removed the jumpers.
I reversed the direction of the adapter.
I connected with redstripe on the outside of the yarns jtag (opposite side as the F4)

I did this in terminal:
Quote:
vagrant@vagrant-ubuntu-trusty-64:/vagrant/eurorack-modules$ PGM_INTERFACE=stlink-v2 make -f yarns/makefile upload
openocd -f stmlib/programming/jtag/interface_stlink-v2.cfg -f stmlib/programming/jtag/stm32f10x_jtag.cfg -f stmlib/programming/jtag/prelude_f10x.cfg -f stmlib/programming/jtag/erase_f10x.cfg -c "flash write_bank 0 build/yarns/yarns_bootloader_combo.bin 0x0" -c "verify_image build/yarns/yarns_bootloader_combo.bin" -f stmlib/programming/jtag/postlude.cfg || openocd -f stmlib/programming/jtag/interface_stlink-v2.cfg -f stmlib/programming/jtag/stm32f10x_jtag.cfg -f stmlib/programming/jtag/prelude_f10x.cfg -f stmlib/programming/jtag/erase_f10x.cfg -c "flash write_bank 0 build/yarns/yarns_bootloader_combo.bin 0x0" -c "verify_image build/yarns/yarns_bootloader_combo.bin" -f stmlib/programming/jtag/postlude.cfg
Open On-Chip Debugger 0.9.0 (2016-01-29-01:07)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
hla_jtag
adapter speed: 1000 kHz
adapter_nsrst_delay: 200
trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain connect_deassert_srst
stmlib/programming/jtag/stm32f10x_jtag.cfg:43: Error: invalid subcommand "newtap stm32 cpu -irlen 4 -ircapture 0x1 -irmask 0xf -expected-id 0x3ba00477"
in procedure 'script'
at file "embedded:startup.tcl", line 60
in procedure 'jtag' called at file "stmlib/programming/jtag/stm32f10x_jtag.cfg", line 43
Open On-Chip Debugger 0.9.0 (2016-01-29-01:07)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
hla_jtag
adapter speed: 1000 kHz
adapter_nsrst_delay: 200
trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain connect_deassert_srst
stmlib/programming/jtag/stm32f10x_jtag.cfg:43: Error: invalid subcommand "newtap stm32 cpu -irlen 4 -ircapture 0x1 -irmask 0xf -expected-id 0x3ba00477"
in procedure 'script'
at file "embedded:startup.tcl", line 60
in procedure 'jtag' called at file "stmlib/programming/jtag/stm32f10x_jtag.cfg", line 43
make: *** [upload_combo_jtag] Error 1
vagrant@vagrant-ubuntu-trusty-64:/vagrant/eurorack-modules$

I get the same output when the adapter is disconnected.
mxmxmx
jackmattson wrote:

I connected with redstripe on the outside of the yarns jtag (opposite side as the F4)


well, just make sure VDD is connected to VDD. pin 1 / white do < > pin 1 / white dot.

and as i said, i never used vagrant, so don't know the little tricks that might be involved to get SWD to work. looking at the output, this certainly looks odd:

stmlib/programming/jtag/stm32f10x_jtag.cfg

judging from the repo i think i'd expect to see

stmlib/programming/jtag/stm32f10x_hla.cfg

so i suspect you need to make some adjustments to makefile.inc ... at the very least.


since you have the hex, can't you just install openocd (via homebrew) and run things by hand? something like:


openocd -f interface/stlink-v2.cfg -f target/stm32f1x_stlink.cfg
jackmattson
so in terminal I ran this:
Quote:
Macintosh:eurorack-modules matthewjackson$ openocd -f interface/stlink-v2.cfg -f target/stm32f1x_stlink.cfg
Open On-Chip Debugger 0.9.0 (2015-11-15-05:39)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
WARNING: target/stm32f1x_stlink.cfg is deprecated, please switch to target/stm32f1x.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
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
in procedure 'init'
in procedure 'ocd_bouncer'

Macintosh:eurorack-modules matthewjackson$

Then in vagrant I ran this:
Quote:
vagrant@vagrant-ubuntu-trusty-64:/vagrant/eurorack-modules$ sudo PGM_INTERFACE=stlink-v2 make -f yarns/makefile upload
openocd -f stmlib/programming/jtag/interface_stlink-v2.cfg -f stmlib/programming/jtag/stm32f10x_jtag.cfg -f stmlib/programming/jtag/prelude_f10x.cfg -f stmlib/programming/jtag/erase_f10x.cfg -c "flash write_bank 0 build/yarns/yarns_bootloader_combo.bin 0x0" -c "verify_image build/yarns/yarns_bootloader_combo.bin" -f stmlib/programming/jtag/postlude.cfg || openocd -f stmlib/programming/jtag/interface_stlink-v2.cfg -f stmlib/programming/jtag/stm32f10x_jtag.cfg -f stmlib/programming/jtag/prelude_f10x.cfg -f stmlib/programming/jtag/erase_f10x.cfg -c "flash write_bank 0 build/yarns/yarns_bootloader_combo.bin 0x0" -c "verify_image build/yarns/yarns_bootloader_combo.bin" -f stmlib/programming/jtag/postlude.cfg
Open On-Chip Debugger 0.9.0 (2016-01-29-01:07)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
hla_jtag
adapter speed: 1000 kHz
adapter_nsrst_delay: 200
trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain connect_deassert_srst
stmlib/programming/jtag/stm32f10x_jtag.cfg:43: Error: invalid subcommand "newtap stm32 cpu -irlen 4 -ircapture 0x1 -irmask 0xf -expected-id 0x3ba00477"
in procedure 'script'
at file "embedded:startup.tcl", line 60
in procedure 'jtag' called at file "stmlib/programming/jtag/stm32f10x_jtag.cfg", line 43
Open On-Chip Debugger 0.9.0 (2016-01-29-01:07)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
hla_jtag
adapter speed: 1000 kHz
adapter_nsrst_delay: 200
trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain connect_deassert_srst
stmlib/programming/jtag/stm32f10x_jtag.cfg:43: Error: invalid subcommand "newtap stm32 cpu -irlen 4 -ircapture 0x1 -irmask 0xf -expected-id 0x3ba00477"
in procedure 'script'
at file "embedded:startup.tcl", line 60
in procedure 'jtag' called at file "stmlib/programming/jtag/stm32f10x_jtag.cfg", line 43
make: *** [upload_combo_jtag] Error 1
vagrant@vagrant-ubuntu-trusty-64:/vagrant/eurorack-modules$

I don't really understand what the error is, so therefore don't understand what I need to fix. Running outside of vagrant, I get the same output.

EDIT: I GET THE SIMILAR OUTPUT WHEN USB ISN'T EVEN CONNECTED.
Quote:
sudo PGM_INTERFACE=stlink-v2 make -f yarns/makefile upload
openocd -f stmlib/programming/jtag/interface_stlink-v2.cfg -f stmlib/programming/jtag/stm32f10x_jtag.cfg -f stmlib/programming/jtag/prelude_f10x.cfg -f stmlib/programming/jtag/erase_f10x.cfg -c "flash write_bank 0 build/yarns/yarns_bootloader_combo.bin 0x0" -c "verify_image build/yarns/yarns_bootloader_combo.bin" -f stmlib/programming/jtag/postlude.cfg || openocd -f stmlib/programming/jtag/interface_stlink-v2.cfg -f stmlib/programming/jtag/stm32f10x_jtag.cfg -f stmlib/programming/jtag/prelude_f10x.cfg -f stmlib/programming/jtag/erase_f10x.cfg -c "flash write_bank 0 build/yarns/yarns_bootloader_combo.bin 0x0" -c "verify_image build/yarns/yarns_bootloader_combo.bin" -f stmlib/programming/jtag/postlude.cfg
Open On-Chip Debugger 0.9.0 (2015-11-15-05:39)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
hla_jtag
adapter speed: 1000 kHz
adapter_nsrst_delay: 200
trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain connect_deassert_srst
stmlib/programming/jtag/stm32f10x_jtag.cfg:43: Error: invalid subcommand "newtap stm32 cpu -irlen 4 -ircapture 0x1 -irmask 0xf -expected-id 0x3ba00477"
in procedure 'script'
at file "embedded:startup.tcl", line 60
in procedure 'jtag' called at file "stmlib/programming/jtag/stm32f10x_jtag.cfg", line 43
Open On-Chip Debugger 0.9.0 (2015-11-15-05:39)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
hla_jtag
adapter speed: 1000 kHz
adapter_nsrst_delay: 200
trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain connect_deassert_srst
stmlib/programming/jtag/stm32f10x_jtag.cfg:43: Error: invalid subcommand "newtap stm32 cpu -irlen 4 -ircapture 0x1 -irmask 0xf -expected-id 0x3ba00477"
in procedure 'script'
at file "embedded:startup.tcl", line 60
in procedure 'jtag' called at file "stmlib/programming/jtag/stm32f10x_jtag.cfg", line 43
make: *** [upload_combo_jtag] Error 1
Macintosh:eurorack-modules matthewjackson$

I must be missing something so basic that I glossed over it.
mxmxmx
the first command should connect to your target, so that would suggest somethings wrong with your adapter and/or the way you connect it.

your attempts with vagrant will be futile either way; it is still using the wrong ,cfg file (jtag not hla). have you edited makefile.inc?
FingerTappin
Edited: Holding off on this for now. Going to see if I can troubleshoot it myself.
Altitude909
@jackmattson are you sure that discovery board works as an actual JTAG interface? All the ones I have come across only work as SWD devices so I am not sure it will work in the VM since openOCD expects a actual JTAG device
bennelong.bicyclist
Altitude909 wrote:
@jackmattson are you sure that discovery board works as an actual JTAG interface? All the ones I have come across only work as SWD devices so I am not sure it will work in the VM since openOCD expects a actual JTAG device


The STM32 Discovery boards are supposed to emulate the official STM STLINK/v2 interface. The official STLINK/v2 interfaces are known to work with the Mutable dev VM (I use one).

However:

a) the jumpers on the Discovery board need to be correctly set, as discussed above;

b) the correct environment variables need to be set in the dev VM - see https://github.com/pichenettes/mutable-dev-environment#customization - or the makefile.inc needs to be appropriately edited, as Max mentions, and finally;

c) the cable needs to be connected correctly. Each pin in the Discovery board header 2 needs to be traced through the adapter board and the ribbon cable to the miniJTAG header on the Yarns, to make sure the cable is oriented correctly and that the correct pins are connected (don't assume that the adapter board is doing the right thing).

d) the DIY Yarns module which is the target needs to actually work, at the hardware level. All DIY MI modules should be assumed to be faulty until proven to work. As I mentioned, one way of bypassing this variable would be to verify the entire MI dev VM/STM32 Discovery-as-STLINK/v2-ribbon cable adapter chain by connecting to and updating firmware on an existing, known-good MI module - doesn't have to be a Yarns.
Altitude909
From the spec sheet:

"6.1 Embedded ST-LINK/V2 (or V2-A)
ST-LINK/V2 on STM32F4DISCOVERY or ST-LINK/V2-A on STM32F407G-DISC1 is
embedded as programming and debugging tool.
The embedded ST-LINK/V2 (or V2-A) supports only SWD for STM32 devices"

He could just use the STlink utility and flash the binary using the JTag header with appropriate pins connected to the SWD header on the discovery board but I dont know if that will work with openOCD since that is probably expecting all the JTAG pins to be in play
av500
Altitude909 wrote:
@jackmattson are you sure that discovery board works as an actual JTAG interface? All the ones I have come across only work as SWD devices so I am not sure it will work in the VM since openOCD expects a actual JTAG device


OpenOCD works fine with the SWD type STLINK interfaces as provided on the Discovery or Nucleo boards
Altitude909
av500 wrote:
Altitude909 wrote:
@jackmattson are you sure that discovery board works as an actual JTAG interface? All the ones I have come across only work as SWD devices so I am not sure it will work in the VM since openOCD expects a actual JTAG device


OpenOCD works fine with the SWD type STLINK interfaces as provided on the Discovery or Nucleo boards


You've sucessfully flashed the hex in vagrant with a discovery board connected to the JTAG header?
av500
Altitude909 wrote:
av500 wrote:
Altitude909 wrote:
@jackmattson are you sure that discovery board works as an actual JTAG interface? All the ones I have come across only work as SWD devices so I am not sure it will work in the VM since openOCD expects a actual JTAG device


OpenOCD works fine with the SWD type STLINK interfaces as provided on the Discovery or Nucleo boards


You've sucessfully flashed the hex in vagrant with a discovery board connected to the JTAG header?


ah, I misread. as you said the Disco/Nucleo boards only offers SWD, not full JTAG. And openOCD does support SWD. but if the openOCD configuration in the vagrant environment expects a real STLINK (which can do JTAG) then it won't work. in this case changing from transport select hla_jtag to transport select hla_swd in some config file should make it work.
gbiz
I've flashed quite a few MI modules using openocd & the SWD interface on a Discovery, using my own cable*. That was on a bare metal USB interface though, not passthrough on a VM. Fedora, not Ubuntu, not that that should matter.

* the cable only needed 4 wires, 1-1, 2-4, 3-3, 4-2.
Altitude909
^
I'm sure that works but what I am doubting is that it's set up in the Vagrant VM to use SWD as the programming interface
mxmxmx
here's some unknown unknowns out of the way ...

- the adapter in question, if used correctly, works (i use it all the time); it simply maps the 6 pin SWD header to the 2x5 cortex debug header.

- all this works with openocd, of course; so it should work with vagrant, provided vagrant is set up to use the correct .cfg file (as noted above). as per the instructions:

Quote:

export PGM_INTERFACE=stlink-v2
export PGM_INTERFACE_TYPE=hla


- jackmattson's MCU is healthy (i know, because he came over to my place the other day and it flashed the Yarns code alright; it didn't like the bootloader_combo hex, however. i don't know why .. and then it was dinner time. i suspect it was either because 1) i compiled the code with a too recent gcc version (the F103-based MI modules can be a bit picky, i vaguely remember?). or 2), and more likely, because it was dinner time and no time to trouble shoot)


all that being said, i have no clue why jackmattson is running into problems, apart from the jumpers that shouldn't be there and so on.
av500
looking at the pasted error messages, I think the openOCD config used is HLA+JTAG instead of HLA+SWD.

inside the file "stmlib/programming/jtag/interface_stlink-v2.cfg" it says:

interface hla and transport select hla_jtag

but what we need is: transport select hla_swd

so export PGM_INTERFACE_TYPE=hla seems not enough to get openOCD to use SWD mode...
mxmxmx
av500 wrote:
looking at the pasted error messages, I think the openOCD config used is HLA+JTAG instead of HLA+SWD.


yeah, but it doesn't look though as if jackmattson ever even specifies PGM_INTERFACE_TYPE.

that's the command he pasted above:

sudo PGM_INTERFACE=stlink-v2 make -f yarns/makefile upload

Quote:
but what we need is: transport select hla_swd


maybe, though according to this discussion, it's transport select hla_swd that didn't work.
av500
mxmxmx wrote:

maybe, though according to this discussion, it's transport select hla_swd that didn't work.


that I cannot comment on, but clearly there is the distinction between hla_jtag and hla_swd in the OpenOCD configuration. and using the Disco and Nucleo stlink interfaces with hla_swd works (here)
mxmxmx
av500 wrote:

that I cannot comment on, but clearly there is the distinction between hla_jtag and hla_swd in the OpenOCD configuration. and using the Disco and Nucleo stlink interfaces with hla_swd works (here)


sure, but noone was in doubt about there being no difference between jtag and swd. see the previous page.

though i see now what you're saying. the last line in interface_stlink-v2.cfg does look odd.

then we don't know if mattjackson ever followed those instructions completely. (and running openocd manually should have worked, as far as i can see, ... unless he installed it without --enable st-link, ... though i'm not even sure that's still necessary?)
livefreela
funky - methinks i see a solder bridge on the mcu adjacent to the "ic 5" legend on the silk. pins nearest to the "s" by the stm32 engrave....
condor13
condor13 wrote:
condor13 wrote:
insula wrote:
condor13 wrote:
BARE BONES wrote:
I have a Clouds with this same issue, where did you get the board?


Got the board from Rob. Hope is just a coincidence smile
Checking tonight the input op-amp and codec soldering.
Keep you posted BARE BONES

Thanks everyone


the pcb should be ok, check the pins between DAC and the ARM IC.

should be there the issue.


Sure screaming goo yo there seems to be a cold solder there. i didn't manage to buy a 10x Lupe, using multiple lens and i have to get really close smile


Checked all soldering. Refluxed. same issue.
Anyone?



OK. Finally , after a while, managed to get my Clouds up and running normally. There was a cold solder on pin 1 for INPUT on 072.
the board is a bit damaged cause of my not so trusty de-soldering skills, and lack of proper tools. I destroyed some pot traces, but managed to reconnect.
Thanks everybody for the help and patients. Good thing i bought a telescope and used the lens to inspect the soldering. Pretty crazy at 17x magnification smile. Basic things i learned:
1. Use a lot of Flux
2. Use thin solder with core flux
3. Solder all components BUT NO jacks, pots!
4. CLEAN FLUX with isop. alcohol and inspect with 10x lupe or greater. Re-flow if necessary.
5. Try to flash, if not working repeat step 4. Check components, bridges. Open eagle and using the Show tool check signal path on board.
Most of i read unsuccessful builds are due to bad soldering or component misplacement.
Guinness ftw! Guinness ftw! Guinness ftw!
Now getting ready to build again smile



frozenkore
Hey, has anyone built a Peaks? This is my first Mutable module. When I power it up, nothing happens (well, the LEDs do nothing). I'm using the ST-LINKv2 and one of these connectors. I'm running the link software on a Windows 10 VM (I don't have a dedicated Windows box... well my wife does, but I'm trying to avoid using her computer). So I'm trying to connect directly to the chip.

When I turn it all on and hit the connect on the program, I get, "connect under reset". Then I go to the settings and change to that. When I do that and try connect, it says "if you're connecting to a STM32... use normal or hotplug." If change to either of those two, it goes back to the original message to connect under reset.

Right now I'm looking for a place to start troubleshooting. I've read people having issues with the ST-LINK, but then it works on some modules. I'm sure it's a build error and I'll check for any bridges, but I'm not sure I'm even using the software correctly (I've never flashed a chip before).

Thanks!
Brian
bennelong.bicyclist
frozenkore wrote:
Hey, has anyone built a Peaks? This is my first Mutable module. When I power it up, nothing happens (well, the LEDs do nothing). I'm using the ST-LINKv2 and one of these connectors. I'm running the link software on a Windows 10 VM (I don't have a dedicated Windows box... well my wife does, but I'm trying to avoid using her computer). So I'm trying to connect directly to the chip.

When I turn it all on and hit the connect on the program, I get, "connect under reset". Then I go to the settings and change to that. When I do that and try connect, it says "if you're connecting to a STM32... use normal or hotplug." If change to either of those two, it goes back to the original message to connect under reset.

Right now I'm looking for a place to start troubleshooting. I've read people having issues with the ST-LINK, but then it works on some modules. I'm sure it's a build error and I'll check for any bridges, but I'm not sure I'm even using the software correctly (I've never flashed a chip before).

Thanks!
Brian


Yes, I have built several Peaks and used an official STM STLINKv2 to program them. However I have only used Olivier's build system, installed under OS X, and Olivier's vagrant VM environment. Both work fine. I can't provide any advice about flashing under Windows using the STM software.

Troubleshooting: bad soldering and/or incorrect parts placement are the usual culprits. This thread is full of advice on how to tackle those.
frozenkore
I might try out the vagrant VM system. Thanks for the help, I'll comb back over the module.
le_palace
Note: make sure your placed capacitors are not upside down resistors razz

Took me a while to notice that on my Riddles.
tonymatte
I've got some (what seem to me) curious issues with the timbre control on my DIY braids. The issues have been there since the beginning (few months ago) but I always just dealt with it. I've confirmed it isn't software related as it occurs in both the original software, as well as in the bees-in-the-trees alternative.

Basically my timbre knob does nothing on it's own, totally unresponsive. But, when I patch a control voltage into timbre it does respond..

I dealt with this by patching +5 v from my triatt into timbre, and then the knob would work, albeit in reverse WITH the timbre attenuverter at 7 o'clock (full counter clockwise). If both those conditions weren't true, then it was no dice.
(could also patch in -5v and turn attenuator to 5 o'clock). This was fine until I realized I wasn't getting the full range under any 'workaround' I thought of..

So, I've read this thread and got some good starting points, but I've got some strange info.

-confirmed timbre knob swings -12 to +12 to center pin.
-voltage across R45 is +12 v with knob fully clockwise.
-voltage across R45 is dead 0v with knob fully counter.
-voltage across R39 (knob fully clockwise) is about +2.5 v

The last part really confuses me. If I've got +12v going into an inverting buffer then how can I be reading a positive voltage at the output?

Any help appreciated we're not worthy
note : I have checked for solder bridges EXTENSIVELY. I can't exclude the possibility, but I highly doubt that is the issue at this point.
livefreela
tony, are you missing your reference voltage at the timbre pot?

- edit

disregard, just saw that you did. double-check r28 maybe? are you getting voltage from the pot rotations at the junction of r28/r30?
tonymatte
Should mention I'm using a version 0.3 board. But looking at the board file, there doesn't appear to be a junction between r28 and r30.. hmmm..... I checked them anyway, and both are reading 0v across, no matter which way the pot is turned.
funkyjunky
bennelong.bicyclist wrote:


The MI eurorack designs are intended to be built by robots in factories (true!). Humans can build them by hand, but they are not beginner projects, and there is no build guide or documentation other than the Eagle files and a BOM. It is not easy to get right, and it takes painstaking care with putting the right parts in the right places, good soldering technique, and proper tools for inspection of your soldering (and isopropyl alcohol or similar to clean your PCB before inspection). Access to and knowledge of how to use basic troubleshooting tools such as a multimeter is essential.

If you bought your PCB from someone who is selling Mutable PCBs on a commercial basis, then you need to seek help from that vendor, who should have warned you and other customers before you bought the PCB of the nature of the MI eurorack designs - that they are not intended for DIY, and thus you need at the very minimum to be able to do the things I mentioned above to succeed.

If you had the PCB made yourself by an online PCB fabricator, then you are even more on your own.

However, people here will help as best they can. livefreela has already provided good advice - follow it. Get some 99% IPA (isopropanol) and a toothbrush and clean your PCB really well, multiple times (don't get IPA in the pots, wear eye protection, don't use the toothbrush on your teeth afterwards). Then inspect your soldering with a 10x jeweller's eye loupe or equivalent. Post high-res photos taken with a macro camera lens here if you like (the photos you posted above aren't good enough to be useful).

Failing that, then you may have put the wrong part in the wrong place. Errors with the chips are easy to spot, but the wrong 0603 size resistor or cap in the wrong place is hard or impossible to spot - that's why extreme care needs to be taken when building to get parts placement right the first time - there's no real second chance when unlabelled 0603 parts are involved (and remember, it was designed for assembly by robots, who don't make mistakes - you need to be just as accurate).

You might be able to find an expert to troubleshoot it for you, in person, but it may be costly, and you may need to just write it off to experience and try again (or not). It is unrealistic to expect a 100% success rate when DIY building these designs. For DIY builders with little SMD experience, a 50% success rate is probably a more realistic expectation.


I bought a 30x magnifier glass and 300ml IPA and a special anti static brush. Cleaning at first didn't help. So I used Eagle's "show" button to trace everything on the board coming from and into the blend cv/potentiomter. I used a lot of flux and solder-touched everything on my way. Spent a few evenings with the magnifier glass and soldering iron and finally made it working!

Thanks everyone here for support! Now I am a happy clouds user. Now we are making a group buy of MI PCBs locally in russia. Will report soon on how its going on. I am going for brachnes, elements, peaks, ripples, shades, warps and streams. Rockin' Banana!
fluffymuff
Hello all.

I have been attempting a Braids build as my first serious SMD project after about 40 successful through-hole builds and I have come a bit unstuck! I managed to solder every small component ok and (hopefully) all the IC's except for the last one I had to solder to the board - IC7 - where I ended up with a 3 pin bridge that required some desoldering braid. I had to do this with a couple of other IC's with no issues but for some reason this time its taken some of the solder mask with it and now the 3 pads are exposed to each other. See pic below:



Does this mean my PCB is toast or is there something I can do to remedy it?

Thanks in advance
adam
i'd say it's ok if it's just the mask thats come off and you've already soldered the joints - you'd have problems if the solder was bridging - if you need to redo any of those you'll need to take care

if any of the traces have come off you'll need to repair those or just do a fresh build.

i do have some much higher quality pcb's than this one available which are nowhere near as prone to this kind of problem, i haven't had any reports of lifted solder mask and only a few lifted pads after nearly a year of people putting them together
fluffymuff
Thanks for the reply Adam. Sorry for not understanding how PCBs are put together but if I leave it as is aren't pins 3, 4 and 5 all shorting each other out? Or is there something under the solder mask that prevents the conductivity between the pads?

If this one is toast I might take you up your offer thumbs up
adam
basically the pcb is fibreglass base with copper on top, then the solder mask

the mask is just to stop solder going to places where it shouldn't

the pcb traces are etched into the copper (well, the parts that shouldn't conduct are etched away, the traces remain) - if the coppers been stripped off too then the pins won't connect, you'd need to check the pcb layout file to see roughly what the traces should look like, they won't look exactly the same as in eagle but you'll be able to tell what pin should have each trace going to it

edit - all that said, the area looks blue - could be the mask is there still and it's just the silkscreen thats been removed - you'd have to check the eagle file
le_palace
Currently running into a problem with Tides. I successfully flashed the chip but still can't get any lights.

I flashed the chip via FTDI just fine (apparently..)

Quote:
...
...
Read 256 bytes at 0x8015100
Read 256 bytes at 0x8015200
Read 256 bytes at 0x8015300
Read 256 bytes at 0x8015400
Read 256 bytes at 0x8015500
Verification OK


3 LEDs not on but I'm not sure how that's possible if I were able to successfully flash the chip.. seriously, i just don't get it [/quote]
adam
have you tried switching it off and on again?
condor13
I have a clouds. with a little problem.
At the maximum point and minimal point of rotation it screws up the "value". I measured the volts are correct on middle pin of the pot. But for example on blend when i turn it max cw (full blend) it goes to greenish from almost red. It happens on texture pot too.
They work but not at max and min.
CV`s work just fine
What do you guys think i should check?
Thanks
Rockin' Banana!
le_palace
adam wrote:
have you tried switching it off and on again?


haha thanks for the suggestion but this was definitely tried

seems a little strange no to be unresponsive after successful flashing...
adam
ok, the tech support classic didn't work wink

and you flashed both bootloader and main firmware?
le_palace
adam wrote:
ok, the tech support classic didn't work wink

and you flashed both bootloader and main firmware?


I worked as a QA engineer previously and 'power off/on' is always the go-to hihi

i ran the following commands successfully

make -f tides/bootloader/makefile hex
make -f tides/makefile upload_combo_serial
adam
how about the calibration procedure? can you get the leds to light when you press the mode switch (not sure if you have to plug the cables in etc to make it do this)
Quote:

CV input calibration

This automatic procedure calibrates the V/Oct input (scale and offset), the FM input (offset), and the level input (offset).

Set the FREQUENCY knob to its center position.
Connect a patch cable to the FM input. Leave the other end of the cable unplugged (this prevents the normalling to ~1 semitone to be activated).
Connect a patch cable to the Level input. Leave the other end of the cable unplugged (this prevents the normalling to full scale to be activated).
Connect a MIDI>CV interface or precision voltage source to the V/Oct input.
Hold the Mode switch (A) for one second. All LEDs are lit in yellow.
Play a C2 note, or send a 1V voltage from your CV source.
Press the mode switch (A). All LEDs are lit in green.
Play a C4 note, or send a 3V voltage from your CV source.
Press the mode switch (A).

The module is now calibrated for accurate V/Oct operation!
Bipolar output offset calibration

Remove any patch cable from the trigger input.
Set the mode to AD or AR (mode LED is red or green).
Set the range to medium (range LED is off).
Measure the voltage on the bipolar output. Adjust the trimmer on the back of the board so that this voltage reaches 0V.
midirobot
hello all and thanks for your help=)

i tried to build a peaks,everything about led and button seems to work fine,
but my problem is from the output side it s outputting always 7.7v,
in any mode,i check all soldering nothing appers to me...

i got a doubt on ic4 and ic5 orientation,pin 1 must be on which side?

cheers

Romain
adam
you need to look at the eagle file for the ic orientation - the ic will have a line on one side in the file, and the physical ic will have one side that looks like the corner was cut off

pin one is the top pin on this side of the ic
midirobot
thanks for the hint!

so they are well oriented...

anybody have an idea to where i can take a look?
adam
are both outputs continuously outputting 7.7v or just one?
midirobot
both outs are at 7.7v,
and 20k trimmer does nothing.

don t know from where to start...

cheers=)
livefreela
are you missing your -10v supply? what's the voltage at IC6?
midirobot
yo,i

i ve got. -9.97 at ic6 what else i could test?


cheers:)
cannonball swandive
Hey guys, I have a streams with channel one the works perfect. Channel 2 I'm having trouble with. There seems to be a positive voltage sent to the output of channel 2 even with a dummy cable plugged into the input. I realize that positive voltage is normaled to the input with nothing patched but both channels should drop to zero when a dummy cable is patched. I've checked my Mcu and the 6004. Any thoughts?
adam
i'd meant to ask if anyone had compiled streams using the vm and got a working firmware from it? (not just compiles ok, but makes channel 2 behave properly)

edit (i know olivier changed the code, just want to eliminate this as a possibility)
flts
cannonball swandive wrote:
Hey guys, I have a streams with channel one the works perfect. Channel 2 I'm having trouble with. There seems to be a positive voltage sent to the output of channel 2 even with a dummy cable plugged into the input. I realize that positive voltage is normaled to the input with nothing patched but both channels should drop to zero when a dummy cable is patched. I've checked my Mcu and the 6004. Any thoughts?


silly and obvious: does the switching jack on channel 2 work correctly mechanically?

or is this a possible known issue with uploading / compiling the firmware for diy or something like that? didn't browse the thread for clues.
cannonball swandive
I've replaced the jacks. They were working fine. Still unsure where to go from here seriously, i just don't get it
adam
this could be a firmware issue - though it sounds different to the previous one - there are some test points on each channel if you look at the schematic - you could try measuring channel 2 to see if there is a positive voltage all the time
cannonball swandive
There is definitely a positive voltage all the time coming from the output of channel 2. Even with a dummy cable plugged into the input of channel 2. My problem is I'm not sure what would be the cause of this. I've replaced the switching jacks and rechecked the mcu. It is fine. I'm getting -10v from the r24. Not sure what would be the next possible cause
adam
sorry, i was getting confused with positive cv all the time, is it the same in all modes?
cannonball swandive
In all modes I have 5.24 v hanging out on the output of channel 2.
geh2oman
I've tried to do a bit of sleuthing so far, but I haven't quite found the answer here on Muffs or elsewhere, so I figured I would give it a shot to ask.

I've been trying to learn as much as I can about this digital side of the realm here. Currently I'm getting extremely stuck in the process of building the toolchain in order to compile everything for a Braids module. I've followed the JSnyder instructions through and through (multiple attempts of each suggestion in their readme), up and down the Mac Tutorial in the MI forum. The crux of the issue seems to be that GCC/G++ are not locating themselves in the bin folder of arm-cs-tools. Everything else shows up, but the arm-none-eabi-g++.

Maybe it would have been easier to ask after the first time it failed, because it's possible that all of the workarounds that I've now tried have mucked it up, but I consider myself absolutely stuck. Thanks for any and all help.
gbiz
geh2oman wrote:
I've tried to do a bit of sleuthing so far, but I haven't quite found the answer here on Muffs or elsewhere, so I figured I would give it a shot to ask.

I've been trying to learn as much as I can about this digital side of the realm here. Currently I'm getting extremely stuck in the process of building the toolchain in order to compile everything for a Braids module. I've followed the JSnyder instructions through and through (multiple attempts of each suggestion in their readme), up and down the Mac Tutorial in the MI forum. The crux of the issue seems to be that GCC/G++ are not locating themselves in the bin folder of arm-cs-tools. Everything else shows up, but the arm-none-eabi-g++.

Maybe it would have been easier to ask after the first time it failed, because it's possible that all of the workarounds that I've now tried have mucked it up, but I consider myself absolutely stuck. Thanks for any and all help.


You don't actually say how the problem is manifesting itself. Are you first seeing this when you run make* ?.

Where you say "Everything else shows up, but the arm-none-eabi-g++", are you saying that the rest of the toochain components such as nm, ar, ld, etc etc are built correctly & moved in the bin directory, just g++ isn't ?. If that's the case cut'n'paste the output of the build (or rerun it & tee the output into a file), & search through that for where g++ is built or copied into the bin directory.

If you're happy just following bash scripts, a possibly more up2date method to build the environment would be to use the install script Olivier uses for his vagrant image. It's for umbongo, but if you're OK with scripts, should be able to tailor it for any other Linux/Unix.
https://github.com/pichenettes/mutable-dev-environment/blob/master/0_i nstall-toolchain.sh

* the reason i ask this, for some odd reason, the $TOOLCHAIN_PATH environment variable needs a trailing /. If you leave that off (as i've probably done more times than i've not), make won't find the toolchain as all the paths to the toolchain components etc built on that $TOOLCHAIN_PATH are incorrect.
adam
cannonball swandive wrote:
In all modes I have 5.24 v hanging out on the output of channel 2.


makes me wonder how it's getting there - if you measure the voltages on the outputs of each opamp and vca (ic's 9 & 10), can you find the point where it appears?
geh2oman
Thanks gbiz! Sorry, I definitely left the exact issue amidst a jumble of words. You're exactly correct, all of the other toolchain components are there in the bin directory after making the toolchain and exporting it. The first I noticed g++ was missing was when I ran make for the bootloader hex and it told me that it wasn't there, then I looked in the bin folder and… it wasn't there. I'll try this script action, but also I can throw Ubuntu on my netbook and see if I can get something going that route too. Thanks gbiz!
gbiz
geh2oman thats wierd. I'd go back through the compilation output looking for errors.

Do you have arm-none-eabi-c++ in your bin directory ?. That's in bin on my system here. arm-none-eabi-g++ is an identical file to it, with the same size & checksum, but it's not linked (as i'd expect). If that's there you could link or copy+chmod it.

Edit: another system i just looked at, those binaries are linked in the bin directory.
midirobot
hi there,

finally i sorted out my problem with my peaks,as said in this tread,
i reflow stfm and it made the job!!

glad it s working finally,

thanks for your advice also indirectly=)

see you
adam
i'm glad you sorted it out smile
midirobot
thx me too,let s start elements now=)
Conjure
Figured it out smile
cannonball swandive
The side with the line is the side with pin 1
koerby
Hi

has someone alreday build a MI Clouds with PCB ver3? This is the latest Version with the two Crystals?

I finished mine and run into the problem that Q4 does not swing.
Q4 is the 12.288 Mhz Crystal for the codec-Chip.

Follow things I tried:
-Replace Q4
-Replace Codec-Chip
-Replace Crystal Capacitors
-Repplace MCU
-All voltages of the WM8731 are Ok
-Resoldering

All the controls/Pots are working fine, just no Sound regrading the "dead" Codec -Chip

any Ideas?


EDIT: It works, after rebuiling the Firmware Rockin' Banana! It's peanut butter jelly time! nanners
Conjure
Not really an "unsuccessful" build, but has anyone setup the STLink/v2 in Linux outside of the Vagrant? I'm running my own distro, everything works fine and has for months (via FTDI). Built myself a Streams which is JTAG-only.

For now, I moved the Streams and Bootloader hex over to Windows and flashed them that way (works fine), but I'd like to get it working completely in Linux so I don't have to do that.

-OpenOCD won't take the STLink/v2 cfg file.
-QStlink works in discovering the STM32 but cannot read or write to it.


EDIT: Seems to work now smile Think I just had to reset my udev rules.
gbiz
I've built a fair few of these modules & all have been flashed using either a genuine STLink v2 or a Discovery in STLink mode, using Fedora with the native version of openocd with the config files shipped with the package.

# openocd -f interface/stlink-v2.cfg -f target/stm32f1x_stlink.cfg -c init -c halt -c "flash write_bank 0 build/streams/streams_bootloader_combo.bin 0x0"
# openocd -f interface/stlink-v2.cfg -f target/stm32f1x_stlink.cfg -c init -c halt -c "verify_image build/streams/streams_bootloader_combo.bin"

You need to create a udev rule that makes the device node when the STLink is hotplugged. You also need to give yourself read/write permission on the device by adding your id to the group the device node is created with. IIRC, on Fedora it's "dialout".
adam
same on ubuntu - so probably all debian variants too
gbiz
Those openocd commands were cut & pasted from my notes that i wrote some time back. Something i just remembered that i should probably add. I flashed a tides a few days ago & openocd suggested that target config file is deprecated & provided a path for a newer file. I used that & the board flashed fine. I suspect it's the first time i've run openocd since upgrading to F23. Unfortunately I've closed the terminal window i ran that ssh session from, so i don't have that output from openocd available now.
Conjure


Got QSTLink2 working smile Think I just had to reset my udev rules.

I dig the GUI over the long openocd commands.
Conjure
Having the weirdest issue with my DIY Ripples. Plugging a cable (regardless of if it's plugged in elsewhere or not) into the Gain input on Ripples *sometimes* restarts my Clouds and Elements. It's the strangest thing ever. Like a power surge or something?

Everything else works fine and has for months. I love the filter. I rarely ever use the gain CV as it is, but I'd still like to fix it.

Any ideas?
pichenettes
Looks like you built something that never went into production (wrong PCB, or BOM and PCB mismatched).

Check for one of the supply rail getting into the normalization of the GAIN jack. Cut the trace or add a resistor there.
jensu
Remember to make sure that the BOM you are building from is made from the pcb version you are building. If you have bought/fabbed boards some time ago, there's a risk that the current bom on the mutable github is not for that board. But both boardss and boms are versioned, so it's easy to check.
Conjure
jensu wrote:
Remember to make sure that the BOM you are building from is made from the pcb version you are building. If you have bought/fabbed boards some time ago, there's a risk that the current bom on the mutable github is not for that board. But both boardss and boms are versioned, so it's easy to check.


Yeah I know this. I always match BOM to PCB revision, that's rookie razz

Thanks Olivier! I'll look into it. It's a Ripples v2.
adam
does your pcb say v0.1 on one side and v0.2 on the other?
Conjure
adam wrote:
does your pcb say v0.1 on one side and v0.2 on the other?


It does, actually.
adam
i think it's a 0.1 then
Conjure
adam wrote:
i think it's a 0.1 then


Interesting, thanks. Are those non-production units then?
adam
have you got a v2 bom? i thought the files on github jumped from 0.1 to 0.4?
Conjure
adam wrote:
have you got a v2 bom? i thought the files on github jumped from 0.1 to 0.4?


I edited it. It wasn't the v0.2, it was just the corrected values to 0.1.

I verified that all values were correct. I did figure out more to the issue though. When I put a cable half way into the GAIN jack, and angle it upwards, the power cuts out to the +12V on my uZeus completely. The blue light on the uZeus goes out completely. Very strange. When I remove the cable, power comes back. Seems like a short?

I'll have to figure out what Olivier was talking about in cutting the trace. Other than this one issue, the filter works perfectly.
adam
there is an issue with using 4000 cmos connected straight to minijacks - because the jack shorts when you plug it in or something - sounds like a short but strange that it only happens on this input, presumably all the jacks ground pins are connected to ground
Conjure
adam wrote:
there is an issue with using 4000 cmos connected straight to minijacks - because the jack shorts when you plug it in or something - sounds like a short but strange that it only happens on this input, presumably all the jacks ground pins are connected to ground


Interesting.
cannonball swandive
If I go from clouds version 2 boards to version 3 do the old hex files still work. Some of the components are different on version 3
Conjure
....
BARE BONES
you need new firmware for the new pcb
piccl
I just completed my first braids. It all works except for the color and timbre pots. From reading posts from other people who had similar problems, I know the problem is likely somewhere near IC 7 or 8. I have the correct voltages when measuring the pins on the two pot. What are some things I should check?
thanks!
slo
Quote:
you need new firmware for the new pcb

You have me worried here because I just flashed a Clouds the lazy way with a hex from the files on the Facebook PCB page. If there are different firmwares then that is probably the latest and I have a v.2 board, but on the Mutable site it states
Quote:
Clouds’ firmware has not received any update following the release of the module."

So I'm thinking there is only one official firmware
koerby
Quote:

If I go from clouds version 2 boards to version 3 do the old hex files still work. Some of the components are different on version 3


On the ver3 Boards is an additional crystal for the Codec-Chip.
You need a Firmware based on the latest files in the Git Repository, otherwise you will have no audion output caused by the non working codec chip.

Trust me, it took me aged to figure out why my clouds clone does not work.

Marcus
cannonball swandive
Yup, got it sorted. Thanks guys.
tonymatte
using the mutable dev environment on my macbook pro trying to upload clouds firmware via st-link v2, keep getting this readout.

Open On-Chip Debugger 0.9.0 (2016-03-17-22:16)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
hla_jtag
adapter speed: 2000 kHz
adapter_nsrst_delay: 100
trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain connect_deassert_srst
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
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 v25 API v2 SWIM v4 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 3.234233
Info : stm32f4xxx.cpu: hardware has 6 breakpoints, 4 watchpoints
target state: halted
target halted due to debug-request, current mode: Handler HardFault
xPSR: 0x01000003 pc: 0xfffffffe msp: 0xffffffd8
Info : device id = 0x10076413
Info : flash size = 1024kbytes
erased address 0x08000000 (length 16384) in 0.421654s (37.946 KiB/s)
auto erase enabled
Error: Target not halted
Error: failed erasing sectors 0 to 5

make: *** [upload_combo_jtag_erase_first] Error 1
bennelong.bicyclist
tonymatte wrote:

make: *** [upload_combo_jtag_erase_first] Error 1


What happens if you do:

make -f clouds/makefile upload_combo_jtag

rather than

make -f clouds/makefile upload_combo_jtag_erase_first
tonymatte
MY ASS IS BLEEDING works like a charm! w00t

Weird thing is that I was only running make -f clouds/makefile upload
before, and still getting that error. I had already specified my st-link in the makefile too. Oh well, one perfectly functioning clouds here applause

Thank you bennelong.bicyclist, for making that stupidly easy we're not worthy we're not worthy
slo
I've got an almost working Clouds. All function do as expected, The inputs are working the LED's in Vu fashion and I have sound on the L. side, non on the R.side. Major problem is the output is mangled like feedback. I'd like to try flashing with a v.02 version first because that is what I have and I flashed it with v.03 firmware. I'm getting mixed answers on whether there is a difference between the 2 firmwares.
So has anyone a Clouds v.02 hex they can share?
slo
Got a hex from hadesbox that I'm satisfied with, it's likely v.2 as the repo is a year old. Troubleshooting continues....
midirobot
hello guys,

i am back here to bother you with little questions,i ve built a grids a little time ago,it's seems working well,but if i set the density pot before 12' o clock,it doesn t generate any triggers..
is it a normal behavior or i am missing something?
HipDestroyer
I just finished my first MI build after a hellish process, but the trouble doesn't seem to end. When I try to flash this Braids I get the following. I'm using Oliviers Vagrant thing and an original st-link v2. I checked all IC's including the stm32 and they all receive their supply voltage so that isn't the problem. I tried resoldering the stm32, still no luck.

Anyone?

Quote:
Open On-Chip Debugger 0.9.0 (2016-04-18-21:04)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
hla_jtag
adapter speed: 1000 kHz
adapter_nsrst_delay: 200
trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain connect_deassert_srst
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
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
Error: open failed
in procedure 'init' called at file "stmlib/programming/jtag/prelude_f10x.cfg", line 23
in procedure 'ocd_bouncer'

make: *** [upload_combo_jtag] Error 1
midirobot
EDIT : problem resolved
HipDestroyer
HipDestroyer wrote:
I just finished my first MI build after a hellish process, but the trouble doesn't seem to end. When I try to flash this Braids I get the following. I'm using Oliviers Vagrant thing and an original st-link v2. I checked all IC's including the stm32 and they all receive their supply voltage so that isn't the problem. I tried resoldering the stm32, still no luck.

Anyone?

Quote:
Open On-Chip Debugger 0.9.0 (2016-04-18-21:04)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
hla_jtag
adapter speed: 1000 kHz
adapter_nsrst_delay: 200
trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain connect_deassert_srst
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
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
Error: open failed
in procedure 'init' called at file "stmlib/programming/jtag/prelude_f10x.cfg", line 23
in procedure 'ocd_bouncer'

make: *** [upload_combo_jtag] Error 1


So, I'm starting to narrow this down. Apparantly my Mac osx won't see the stlinkv2 inside the mutable dev env. I tried reinstalling with sudo, didn't help, anyone have any idea what to do next?
bennelong.bicyclist
HipDestroyer wrote:
HipDestroyer wrote:
I just finished my first MI build after a hellish process, but the trouble doesn't seem to end. When I try to flash this Braids I get the following. I'm using Oliviers Vagrant thing and an original st-link v2. I checked all IC's including the stm32 and they all receive their supply voltage so that isn't the problem. I tried resoldering the stm32, still no luck.

Anyone?

Quote:
Open On-Chip Debugger 0.9.0 (2016-04-18-21:04)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
hla_jtag
adapter speed: 1000 kHz
adapter_nsrst_delay: 200
trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain connect_deassert_srst
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
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
Error: open failed
in procedure 'init' called at file "stmlib/programming/jtag/prelude_f10x.cfg", line 23
in procedure 'ocd_bouncer'

make: *** [upload_combo_jtag] Error 1


So, I'm starting to narrow this down. Apparantly my Mac osx won't see the stlinkv2 inside the mutable dev env. I tried reinstalling with sudo, didn't help, anyone have any idea what to do next?


Have you installed the VirtualBox extensions which allow USB pass-through, as per the instructions? If you have, check that USB pass-through is enabled for that VM.
HipDestroyer
bennelong.bicyclist wrote:
HipDestroyer wrote:
HipDestroyer wrote:
I just finished my first MI build after a hellish process, but the trouble doesn't seem to end. When I try to flash this Braids I get the following. I'm using Oliviers Vagrant thing and an original st-link v2. I checked all IC's including the stm32 and they all receive their supply voltage so that isn't the problem. I tried resoldering the stm32, still no luck.

Anyone?

Quote:
Open On-Chip Debugger 0.9.0 (2016-04-18-21:04)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
hla_jtag
adapter speed: 1000 kHz
adapter_nsrst_delay: 200
trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain connect_deassert_srst
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
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
Error: open failed
in procedure 'init' called at file "stmlib/programming/jtag/prelude_f10x.cfg", line 23
in procedure 'ocd_bouncer'

make: *** [upload_combo_jtag] Error 1


So, I'm starting to narrow this down. Apparantly my Mac osx won't see the stlinkv2 inside the mutable dev env. I tried reinstalling with sudo, didn't help, anyone have any idea what to do next?


Have you installed the VirtualBox extensions which allow USB pass-through, as per the instructions? If you have, check that USB pass-through is enabled for that VM.


Alright, this took me 3 days to figure out. My mac osx 10.11.4 el capitan would not let me pass through the usb no matter what I tried – and believe me, I've tried everything. I tried the dev env, with and without sudo, I tried virtual box, with extensions, with all sorts of usb filters etc etc, but it just wouldn't work.

Then finally I downloaded a trial of Parallels, installed Windows 10 on there along with the st link utility software+drivers and BOOOOOM! It works!

Everyone who suffers similar problems on Mac OSX: Just download Parallels, install windows on it, install the st link utility software+drivers and then upload the hex files from this dropbox: https://www.dropbox.com/sh/z7p2epcbigvl57c/AADl-A8MvFatvBTd0IGirK2ha?d l=0

Holy shit this was hard MY ASS IS BLEEDING MY ASS IS BLEEDING MY ASS IS BLEEDING MY ASS IS BLEEDING MY ASS IS BLEEDING MY ASS IS BLEEDING MY ASS IS BLEEDING

[/img]But it was kind of worth it when this greeted me:

HipDestroyer
I've run into a weird problem. My Peaks flashed fine but now whenever I turn it on it just continually blinks the top LED (SPLIT). Anyone have an idea what that might mean?



HipDestroyer
HipDestroyer wrote:
I've run into a weird problem. My Peaks flashed fine but now whenever I turn it on it just continually blinks the top LED (SPLIT). Anyone have an idea what that might mean?





Fixed. I had installed the mom switch the wrong way around (dot has to point towards edge of pcb) and then for good measure resoldered every pin on the stm and now it works perfectly Rockin' Banana!
Conjure
EDIT: Double post.
Conjure
Having a Hell of a time trying to figure out why my Frames isn't passing audio to the Mix output, or at all really. Everything else works 100%. Modulation, LED, etc. Replaced the CoolAudio V2164M, reseated the STM32. Nothing.
Pin 2 of the V2164M is outputting audio when the audio is coming through Input 1.

Trying to trace this back on the schematic but can't figure it out. Could it be one of the million TL072s (IC7)? The DAC?


EDIT: Got it. D2 was backwards razz
a.b.o.z.
finished three modules, grids, clouds and warps. non of them work grin

grids has all voltages at right places, it is not generating nothing at any setting, even with external clock. trigger outputs are always high. bench psu didnt meter any current consumption on it..like it wasnt hooked on at all..but regulators give +5 and -5

warps after flashing had only red LED lit (for internal oscillator), mode led dead, and i could change frequency with input1 level knob and some modulation going on but really weird. later found one pin lifted on stm and after reflowing it module was dead completly (no red LED, int osc button doing nothing, mode led is also dead.

clouds only have dry signal on outputs, i can change modes but non controls are working. also has voltages on mcu and audio chip.

it is really weird that all 3 are non working. my first smd was braids before those and it worked on first boot ;-/

any nudge in right direction is more than welcome. oh, I have reflowed every component and double checked orientation aswell.

cheers Guinness ftw!
HipDestroyer
a.b.o.z. wrote:
finished three modules, grids, clouds and warps. non of them work grin

grids has all voltages at right places, it is not generating nothing at any setting, even with external clock. trigger outputs are always high. bench psu didnt meter any current consumption on it..like it wasnt hooked on at all..but regulators give +5 and -5

warps after flashing had only red LED lit (for internal oscillator), mode led dead, and i could change frequency with input1 level knob and some modulation going on but really weird. later found one pin lifted on stm and after reflowing it module was dead completly (no red LED, int osc button doing nothing, mode led is also dead.

clouds only have dry signal on outputs, i can change modes but non controls are working. also has voltages on mcu and audio chip.

it is really weird that all 3 are non working. my first smd was braids before those and it worked on first boot ;-/

any nudge in right direction is more than welcome. oh, I have reflowed every component and double checked orientation aswell.

cheers Guinness ftw!


When I, rarely, have success with troubleshooting MI builds these are the two main problems to deal with (for me, maybe not for you):

1. Check orientation of all polarised components.
2. Check/reflow all pins on the stm. Whenever I've had problems with MI builds this has usually solved it.

Also, post some closeups of your boards so we can see the nitty gritty smile
Conjure
Well shit. I made my first rookie mistake building Mutable modules.

Built a Peaks, clean build as I always do, and I plugged the red stripe in backwards. Hadn't even flashed it yet, I was just going to do that.

Now with Peaks plugged in it makes my uZeus (and all modules connected to it) flash continuously.

I replaced the LM1117, no dice. What else could it be? :( I thought Mutable modules had reverse power protection.

EDIT: Nevermind. Fixed it somehow. Reflowed everything. Hm.
tommy.york
I soldered a DIY MI Branches and have been trying to use an FTDIFriend to program it. I got all the software working, but I'm not getting any response from the Branches. But my first guess here is that I'm going to need to a full AVR programmer, instead of the FTDIFriend. Can someone confirm this for me?
koerby
tommy.york wrote:
I soldered a DIY MI Branches and have been trying to use an FTDIFriend to program it. I got all the software working, but I'm not getting any response from the Branches. But my first guess here is that I'm going to need to a full AVR programmer, instead of the FTDIFriend. Can someone confirm this for me?


You need an AVR programmer like AVRISP
http://www.exptech.de/catalogsearch/result/___store=en&q=avrisp&___fro m_store=de

FTDIFriend works only if you have an bootloader on the chip
tommy.york
koerby wrote:
tommy.york wrote:
I soldered a DIY MI Branches and have been trying to use an FTDIFriend to program it. I got all the software working, but I'm not getting any response from the Branches. But my first guess here is that I'm going to need to a full AVR programmer, instead of the FTDIFriend. Can someone confirm this for me?


You need an AVR programmer like AVRISP
http://www.exptech.de/catalogsearch/result/___store=en&q=avrisp&___fro m_store=de

FTDIFriend works only if you have an bootloader on the chip

Your link seems broken, I'm guessing this AVR ISP Mk2 will work?
Mouser link because I'm basically making an order a week at this point, might as well add it on. Dead Banana
adam
that should be fine - the atmel one is more trouble free but this one works with a bit more tweaking, depends on whether you're trying to get it working with atmels ide or avrdude
tommy.york
adam wrote:
that should be fine - the atmel one is more trouble free but this one works with a bit more tweaking, depends on whether you're trying to get it working with atmels ide or avrdude

I was going to use avrdude! How much tweaking will it require?
adam
you need to install new firmware for avrdude - this is detailed in the manual (pretty straightforward)

i would check compatibility with your os on google, for instance this works with (ubuntu) linux but only with version 5.11 of avrdude not the newest one

you could check compatibility with the similarly named avrispmkII as well (official atmel version) and choose the one which works best

if you're feeling intrepid you can try using an arduino as isp instead

as long as you aren't setting fuses you won't brick your chip, so experimenting with flashing the hex file only until you're sure everything works properly is the way to go
AlanP
Be very careful not to feed 5V from the FTDI-Friend into your board, like I did. These 3v3 chips don't like that.
tommy.york
adam wrote:
you need to install new firmware for avrdude - this is detailed in the manual (pretty straightforward)
i would check compatibility with your os on google, for instance this works with (ubuntu) linux but only with version 5.11 of avrdude not the newest one

Yeah, installed avrdude 6.3 using Brew and got the following error messages. I built 5.11.1 from source and got a different error message - involving the function ser_open - and I didn't want to dive too deeply into how to compile it with the right drivers for Mac OS X. Anyway:

Quote:
Thomass-MBP:branches tyork$ avrdude -c avrisp2 -p m88p -nv branches.hex

avrdude: Version 6.3, compiled on Mar 15 2016 at 21:26:45
Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
Copyright (c) 2007-2014 Joerg Wunsch

System wide configuration file is "/usr/local/Cellar/avrdude/6.3/etc/avrdude.conf"
User configuration file is "/Users/tyork/.avrduderc"
User configuration file does not exist or is not a regular file, skipping

Using Port : usb
Using Programmer : avrisp2
avrdude: usbdev_open(): Found AVRISP mkII, serno: 000200212345
AVR Part : ATmega88P
Chip Erase delay : 9000 us
PAGEL : PD7
BS2 : PC2
RESET disposition : dedicated
RETRY pulse : SCK
serial program mode : yes
parallel program mode : yes
Timeout : 200
StabDelay : 100
CmdexeDelay : 25
SyncLoops : 32
ByteDelay : 0
PollIndex : 3
PollValue : 0x53
Memory Detail :

Block Poll Page Polled
Memory Type Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
eeprom 65 20 4 0 no 512 4 0 3600 3600 0xff 0xff
flash 65 6 64 0 yes 8192 64 128 4500 4500 0xff 0xff
lfuse 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
hfuse 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
efuse 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
lock 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
calibration 0 0 0 0 no 1 0 0 0 0 0x00 0x00
signature 0 0 0 0 no 3 0 0 0 0 0x00 0x00

Programmer Type : STK500V2
Description : Atmel AVR ISP mkII
Programmer Model: AVRISP mkII
Hardware Version: 0
Firmware Version Master : 1.23
Vtarget : 3.3 V
SCK period : 8.00 us

avrdude: stk500v2_command(): command failed
avrdude: stk500v2_program_enable(): bad AVRISPmkII connection status: Target not detected
avrdude: initialization failed, rc=-1


Can someone confirm that this is what a successful connection to the olimex avr-isp-mk2, but no successful connection to the (in the case,) DIY MI branches looks like?

This was my first SMD DIY and the soldering around the atmega chip looks messed up. I wanted to confirm that it wasn't working before I gave it another go.
adam
there is a message in there about no config file, but yes, looks like it's found the isp but not the chip, the module needs to be powered on and the 5v jumper on the olimex set to off - this is the default i think

i'm surprised you're having to use brew for avrdude - arduino ide uses it for instance so there are native osx versions

crosspack avr includes avrdude - you can probably just flash hex files with it too

https://www.obdev.at/products/crosspack/index.html
tommy.york
adam wrote:
there is a message in there about no config file, but yes, looks like it's found the isp but not the chip, the module needs to be powered on and the 5v jumper on the olimex set to off - this is the default i think

i'm surprised you're having to use brew for avrdude - arduino ide uses it for instance so there are native osx versions

crosspack avr includes avrdude - you can probably just flash hex files with it too

https://www.obdev.at/products/crosspack/index.html

Well, I did initially try without any power at all d'oh!, but tried again powering the module from my uzeus, same results.

Yeah, the defaut position for the olimex was not to power the target from the olimex.

I actually just jumped for brew before anything else. I don't mind brew! I used to run debian in the past and don't mind the command prompt love .
adam
ok, looks like avrdude is working anyway, so i don't know if theres any advantage in using the native version, you still get to command line

the no target error often displays when the power isn't plugged in, you could look at solder joints on the power pins on the avr chip

there are sometimes issues with avrdude - you could look at the adafruit avrdude tutorials if you haven't already, there are a bunch of arguments to tweak but i would clean off the flux and check soldering first
d.simon
Conjure wrote:

I'll have to figure out what Olivier was talking about in cutting the trace. Other than this one issue, the filter works perfectly.


did you ever figure that out? I compared versions and it looks like the newer version has a resistor between the normal input and vcc on that jack. So probably cut that trace and install a resistor?
Lars71
Regarding that Olimex AVR ISP programmer - note that the 6 pin connector on it is not for programming the ATmega type chip on the Branches - the connector you should use is actually the 10 pin one. How to connect it to a 6 pin ISP is described in the data sheet (and Olimex sells an adapter I think).
adam
i used breadboard jumpers instead of an adaptor
tommy.york
Lars71 wrote:
Regarding that Olimex AVR ISP programmer - note that the 6 pin connector on it is not for programming the ATmega type chip on the Branches - the connector you should use is actually the 10 pin one. How to connect it to a 6 pin ISP is described in the data sheet (and Olimex sells an adapter I think).

edit: found!
horstronic
HipDestroyer wrote:
bennelong.bicyclist wrote:
HipDestroyer wrote:
HipDestroyer wrote:
I just finished my first MI build after a hellish process, but the trouble doesn't seem to end. When I try to flash this Braids I get the following. I'm using Oliviers Vagrant thing and an original st-link v2. I checked all IC's including the stm32 and they all receive their supply voltage so that isn't the problem. I tried resoldering the stm32, still no luck.

Anyone?

Quote:
Open On-Chip Debugger 0.9.0 (2016-04-18-21:04)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
hla_jtag
adapter speed: 1000 kHz
adapter_nsrst_delay: 200
trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain connect_deassert_srst
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
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
Error: open failed
in procedure 'init' called at file "stmlib/programming/jtag/prelude_f10x.cfg", line 23
in procedure 'ocd_bouncer'

make: *** [upload_combo_jtag] Error 1


So, I'm starting to narrow this down. Apparantly my Mac osx won't see the stlinkv2 inside the mutable dev env. I tried reinstalling with sudo, didn't help, anyone have any idea what to do next?


Have you installed the VirtualBox extensions which allow USB pass-through, as per the instructions? If you have, check that USB pass-through is enabled for that VM.


Alright, this took me 3 days to figure out. My mac osx 10.11.4 el capitan would not let me pass through the usb no matter what I tried – and believe me, I've tried everything. I tried the dev env, with and without sudo, I tried virtual box, with extensions, with all sorts of usb filters etc etc, but it just wouldn't work.

Then finally I downloaded a trial of Parallels, installed Windows 10 on there along with the st link utility software+drivers and BOOOOOM! It works!

Everyone who suffers similar problems on Mac OSX: Just download Parallels, install windows on it, install the st link utility software+drivers and then upload the hex files from this dropbox: https://www.dropbox.com/sh/z7p2epcbigvl57c/AADl-A8MvFatvBTd0IGirK2ha?d l=0

Holy shit this was hard MY ASS IS BLEEDING MY ASS IS BLEEDING MY ASS IS BLEEDING MY ASS IS BLEEDING MY ASS IS BLEEDING MY ASS IS BLEEDING MY ASS IS BLEEDING

[/img]But it was kind of worth it when this greeted me:



I tried it with windows 10 but the program keeps crashing all the time.
Does anybody have an idea how to flash my braids with a st-link v2 on mac os x? I'm working on it for 2 days now but none of the options I tried worked so far...
gbiz
Have you tried openocd ?.

$ openocd -f interface/stlink-v2.cfg -f target/stm32f1x.cfg -c init -c reset -c halt -c "flash write_bank 0 braids_bootloader_combo.bin 0x0"
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 v21 API v2 SWIM v4 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 3.239843
Info : stm32f1x.cpu: hardware has 6 breakpoints, 4 watchpoints
target state: halted
target halted due to debug-request, current mode: Handler HardFault
xPSR: 0x01000003 pc: 0xfffffffe msp: 0xffffffdc
Info : device id = 0x20036410
Info : flash size = 128kbytes
target state: halted
target halted due to breakpoint, current mode: Handler HardFault
xPSR: 0x61000003 pc: 0x2000003a msp: 0xffffffdc
wrote 121992 bytes from file braids_bootloader_combo.bin to flash bank 0 at offset 0x00000000 in 3.674148s (32.425 KiB/s)

Just worked for me on OSX here. I had to erase the flash on that Braids first as it was already flashed & running. You probably won't need to do that with a fresh MCU.

Thats openocd version 0.9.0 installed with macports, BTW.
HipDestroyer
horstronic wrote:
HipDestroyer wrote:
bennelong.bicyclist wrote:
HipDestroyer wrote:
HipDestroyer wrote:
I just finished my first MI build after a hellish process, but the trouble doesn't seem to end. When I try to flash this Braids I get the following. I'm using Oliviers Vagrant thing and an original st-link v2. I checked all IC's including the stm32 and they all receive their supply voltage so that isn't the problem. I tried resoldering the stm32, still no luck.

Anyone?

Quote:
Open On-Chip Debugger 0.9.0 (2016-04-18-21:04)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
hla_jtag
adapter speed: 1000 kHz
adapter_nsrst_delay: 200
trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain connect_deassert_srst
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
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
Error: open failed
in procedure 'init' called at file "stmlib/programming/jtag/prelude_f10x.cfg", line 23
in procedure 'ocd_bouncer'

make: *** [upload_combo_jtag] Error 1


So, I'm starting to narrow this down. Apparantly my Mac osx won't see the stlinkv2 inside the mutable dev env. I tried reinstalling with sudo, didn't help, anyone have any idea what to do next?


Have you installed the VirtualBox extensions which allow USB pass-through, as per the instructions? If you have, check that USB pass-through is enabled for that VM.


Alright, this took me 3 days to figure out. My mac osx 10.11.4 el capitan would not let me pass through the usb no matter what I tried – and believe me, I've tried everything. I tried the dev env, with and without sudo, I tried virtual box, with extensions, with all sorts of usb filters etc etc, but it just wouldn't work.

Then finally I downloaded a trial of Parallels, installed Windows 10 on there along with the st link utility software+drivers and BOOOOOM! It works!

Everyone who suffers similar problems on Mac OSX: Just download Parallels, install windows on it, install the st link utility software+drivers and then upload the hex files from this dropbox: https://www.dropbox.com/sh/z7p2epcbigvl57c/AADl-A8MvFatvBTd0IGirK2ha?d l=0

Holy shit this was hard MY ASS IS BLEEDING MY ASS IS BLEEDING MY ASS IS BLEEDING MY ASS IS BLEEDING MY ASS IS BLEEDING MY ASS IS BLEEDING MY ASS IS BLEEDING

[/img]But it was kind of worth it when this greeted me:



I tried it with windows 10 but the program keeps crashing all the time.
Does anybody have an idea how to flash my braids with a st-link v2 on mac os x? I'm working on it for 2 days now but none of the options I tried worked so far...


Did you use Virtual Box or Parallels? Parallals worked far better for me than VirtualBox. If you don't have it already you can just download a trial. I use Parallels, ST Link and Windows 10 to flash my MI Modules and I never have any trouble with it after figuring out this magic trio was the business for us poor mac users
tommy.york
Hey, on the 6 pin ICSP on the PCB, which pin does the line next to the box denote?

Lars71
That's pin no 1.
horstronic
HipDestroyer wrote:

Did you use Virtual Box or Parallels? Parallals worked far better for me than VirtualBox. If you don't have it already you can just download a trial. I use Parallels, ST Link and Windows 10 to flash my MI Modules and I never have any trouble with it after figuring out this magic trio was the business for us poor mac users


That's exactly the setup I tried. And I don't know why but somehow it just worked today seriously, i just don't get it
I didn't change anything so I don't know what's going on but I'm not going to complain about it hihi
I finally have a working braids! What a great module applause applause applause
a.b.o.z.
So yeah, Clouds and Warps now works! Clouds had one lifted pin on STM...even after reflowing it three times!!! Warps needed jacks to work...inputs are normalised grin
Grits gives no life...gonna change all semis..
tonymatte
non-working Elements here. I've gotten a braids and a clouds built and flashed and working so I'm not a TOTAL newb.

Anyway, it's been about 3 months now of picking at this thing (scouring for solder bridges, looking for board defects, checking polarity, making sure it's the right part!) and have turned up dry every time.

My STM32 looks in good shape as well as all the other IC's. Here are the symptoms: when plugged into a power source the module emits a very harsh (cap charging/ wrong polarity of something) noise into my ground line (you can hear the noise even with sound card is off, with no output from the module present.) along with this my IC2 gets finger-meltingly hot when powered only for a second or two. no other IC exhibits this behavior.

Please, any ideas welcome. Thanks in advance. we're not worthy
adam
someone had a clouds with a similar noise, it went away after he replaced the mcu

but your ic2 is getting hot, which sounds like a short or part the wrong way round, have you checked in the vias for bridges?
gbiz
tonymatte wrote:
my IC2 gets finger-meltingly hot when powered only for a second or two. no other IC exhibits this behavior.


As no other component gets hot, it sounds like you've got a short on the 3V3_A rail. Resistance from the large tab of IC2 to 0V should be roughly 600 ohms iirc.

Open up the brd file in Eagle & follow the 3V3_A trace for a guide where to start looking.
tonymatte
Thank you adam and gbiz,

So I've already managed to provide poor information, returning my attention to my elements today I realized that BOTH lm1117's get very very hot. They cool so quickly, that I missed it the first couple times, but my currently red fingertip says otherwise eek!

Been on the board file though, chasing the rails around to all my pots, J3, and some op-amp IC3 then to the STM32.

adam- I checked all vias front and back, no bridges there.

gbiz- I'm getting about 220ohm from my cheap, yet relatively consistent multimeter.

So I might as well throw this out there, perhaps you can enlighten me; The big tab on the SOT lm1117, from what I gather, simply mirrors the output from pin 2. So why does it appear on the board file to be soldered to ground? or is this some sort of 3-layer board...
av500
tonymatte wrote:

So I might as well throw this out there, perhaps you can enlighten me; The big tab on the SOT lm1117, from what I gather, simply mirrors the output from pin 2. So why does it appear on the board file to be soldered to ground? or is this some sort of 3-layer board...


IC2, LM1117 on Elements, the large tab is not connected to ground, it is isolated on the PCB:



so when you measure resistance from the LM1117 middle tab to ground, what do you get?
gbiz
Actually, i just checked, it's the middle pin on the LM1117's on elements that's used/supplies 3.3V, not the tab. Sorry.

It's still connected internally in the devce though.
tonymatte
Ah that clears up that head scratcher, thanks av500.

So checking resistance from IC2's pin 2 to ground, I'm still getting 220ohms.
funkymogli
i got a problem with almost finished shelves, all seems to work except of band #2 which just emits feedback. or something like a sine wave..its better with high q settings and even worse with low q . any ideas? i dint see solder bridges and i compared all components to band #3 where everything is working as expected.. could it be a fried chip`? how to find out? thanks!!
funkymogli
problem solved. was a cold solder joint razz
polyot
Here's one:

Working on a Rings at the moment. Got the last parts in this weekend, soldered up. No connection with STLink. Look over everything very closely, touch up the pins on the STM to make sure everything is soldered right. Still nada. Go over everything a third time, go to power on and try again, instant smoke. Quickly turn it off and R2 (the larger resistor) has broken in half. I'm guessing that's by design to protect the rest of the circuit? I'm just not sure what the problem could be. Maybe bad soldering on C2? I didn't observe any heat on any of the caps or anywhere else near the power supply following the resistor blowout. Either way, I'm not placing a Mouser order for a single resistor so it's going to be tabled for some time.

After minor issues with my Braids and Peaks builds, I'm throwing in the towel after this one. Dead Banana
jensu
polyot wrote:

Quickly turn it off and R2 (the larger resistor) has broken in half.


What do you mean by "the larger one"? R2 is a 0603 1k right?
polyot
jensu wrote:
polyot wrote:

Quickly turn it off and R2 (the larger resistor) has broken in half.


What do you mean by "the larger one"? R2 is a 0603 1k right?


No? It's a 4.7R 1206. Rings.
jensu
polyot wrote:
jensu wrote:
polyot wrote:

Quickly turn it off and R2 (the larger resistor) has broken in half.


What do you mean by "the larger one"? R2 is a 0603 1k right?


No? It's a 4.7R 1206. Rings.


Oh crap, sorry. My brain made that into elements for some reason. Blergh, it's getting late here razz
polyot
jensu wrote:
polyot wrote:
jensu wrote:
polyot wrote:

Quickly turn it off and R2 (the larger resistor) has broken in half.


What do you mean by "the larger one"? R2 is a 0603 1k right?


No? It's a 4.7R 1206. Rings.


Oh crap, sorry. My brain made that into elements for some reason. Blergh, it's getting late here razz


Not a problem. I quick ran to make sure didn't mix up boms or something
squarewavesurfer
I have a connection between C7 and C8 on Branches (as tested with a multimeter). According to the PCB file it looks like they shouldn't be connected. I found this after using solder wick to remove a solder bridge. It looks like some of the PCB masking has come off between the pads revealing a trace between the pads.

Can anyone confirm if this is a problem or not?
sixty_n
@squarewave you are ok, I have a branches board here and they are connected. Your diagram is just one side of the board or those capacitors would be just sitting there connected to nothing
ilya.n
I have just finished building Grids and have an issue. Maybe someone has ideas?

I flashed the mpu ok.
But the LEDs always blink with the highest possible speed at given clock tempo. Triggers also fire in unison with the LEDs. The button works and the clock rate pot works. No other pots make any change. Voltages on opamps are OK.
very frustrating
squarewavesurfer
Just tried to program my DIY Braids v5.0 and before programming, on eurorack powerup, the R49 resistor went up in smoke and broke in half. Everything else looks okay.

I had the Olimex ARM-USB-OCD-H with adapter hooked up to the usb2.0 port on my laptop, and the JP2 on braids. I had the power connector (red stripe connected properly to the move 104 case and braids. As soon as I turned on the move 104 power, the R49 resistor went up in smoke.

Any ideas? Do I just need to replace this resistor or is there more needed?


And is there any step by step guide to how to connect everything for programming. I wasn't 100% sure which was to connect the jtag adapter to the braids jp2.
polyot
squarewavesurfer wrote:
Just tried to program my DIY Braids v5.0 and before programming, on eurorack powerup, the R49 resistor went up in smoke and broke in half. Everything else looks okay.

I had the Olimex ARM-USB-OCD-H with adapter hooked up to the usb2.0 port on my laptop, and the JP2 on braids. I had the power connector (red stripe connected properly to the move 104 case and braids. As soon as I turned on the move 104 power, the R49 resistor went up in smoke.

Any ideas? Do I just need to replace this resistor or is there more needed?


I can't offer any help as of yet, but this is very similar to what happened with my Rings build. It has a similar 1206(?) resistor in the power supply area of the board. I have replacements (several) in but did not get a chance to replace and try again yet. My attempt at preventing it from happening again was simply to reflow pretty much everything in the power supply section like the electrolytics and diodes. Might give it another go tonight. Fingers crossed.
av500
squarewavesurfer wrote:
Just tried to program my DIY Braids v5.0 and before programming, on eurorack powerup, the R49 resistor went up in smoke and broke in half. Everything else looks okay.

I had the Olimex ARM-USB-OCD-H with adapter hooked up to the usb2.0 port on my laptop, and the JP2 on braids. I had the power connector (red stripe connected properly to the move 104 case and braids. As soon as I turned on the move 104 power, the R49 resistor went up in smoke.

Any ideas? Do I just need to replace this resistor or is there more needed?

And is there any step by step guide to how to connect everything for programming. I wasn't 100% sure which was to connect the jtag adapter to the braids jp2.


you can always measure the resistance between the +12V and -12V lines to ground before powering up. if you measure something <100 Ohm, don't power it up...
adam
exploding resistors is normally a short

has been a structural issue in the pcb before, not one of mine i might add wink
squarewavesurfer
av500 wrote:
squarewavesurfer wrote:
Just tried to program my DIY Braids v5.0 and before programming, on eurorack powerup, the R49 resistor went up in smoke and broke in half. Everything else looks okay.

I had the Olimex ARM-USB-OCD-H with adapter hooked up to the usb2.0 port on my laptop, and the JP2 on braids. I had the power connector (red stripe connected properly to the move 104 case and braids. As soon as I turned on the move 104 power, the R49 resistor went up in smoke.

Any ideas? Do I just need to replace this resistor or is there more needed?

And is there any step by step guide to how to connect everything for programming. I wasn't 100% sure which was to connect the jtag adapter to the braids jp2.


you can always measure the resistance between the +12V and -12V lines to ground before powering up. if you measure something <100 Ohm, don't power it up...


forgive my lack of pcb troubleshooting knowledge but when measuring resistance from the +12 and -12V where is the ground i measure to?

I tried measuring from the 12V pin on the euro power to a jp ground pin but the resistance seemed to be constantly decreasing.
HipDestroyer
squarewavesurfer wrote:
av500 wrote:
squarewavesurfer wrote:
Just tried to program my DIY Braids v5.0 and before programming, on eurorack powerup, the R49 resistor went up in smoke and broke in half. Everything else looks okay.

I had the Olimex ARM-USB-OCD-H with adapter hooked up to the usb2.0 port on my laptop, and the JP2 on braids. I had the power connector (red stripe connected properly to the move 104 case and braids. As soon as I turned on the move 104 power, the R49 resistor went up in smoke.

Any ideas? Do I just need to replace this resistor or is there more needed?

And is there any step by step guide to how to connect everything for programming. I wasn't 100% sure which was to connect the jtag adapter to the braids jp2.


you can always measure the resistance between the +12V and -12V lines to ground before powering up. if you measure something <100 Ohm, don't power it up...


forgive my lack of pcb troubleshooting knowledge but when measuring resistance from the +12 and -12V where is the ground i measure to?

I tried measuring from the 12V pin on the euro power to a jp ground pin but the resistance seemed to be constantly decreasing.


Measure between ground and +12, then ground and -12v thumbs up
squarewavesurfer
Does anyone know which way to connect the olimex arm-jtag-20-10 to the jtag header?

Also, with the Olimex arm-usb-ocd-h, do you need to power the braids module via the eurorack power header in order to program it?
mikecameron
I've recently built a couple warps pcbs and I can get the boards to program via serial, but they do nothing. They pass no audio, and the OSC led doesn't light when you push the button. However, if you power up the system with the osc button pressed, it does blink. So the boot loader seems to be working, which makes me think maybe I have an issue compiling the code. I get no error codes when building firmware, or when programming.

Does anyone have a known working warps hex i can put on this thing to see if it's my build environment or a potential hardware issue?


fwiw i've built braids, elements, clouds, tides, streams building my own firmware and have had success on all attempts. When my first warps failed, I figured it was a hardware problem which is why i built a second and got the same behavior. These are OSHPark boards ordered when the files were originally posted.
jensu
squarewavesurfer wrote:
Does anyone know which way to connect the olimex arm-jtag-20-10 to the jtag header?

Also, with the Olimex arm-usb-ocd-h, do you need to power the braids module via the eurorack power header in order to program it?


If you open the board file, you can see that "Reset" is top left connector on the braids. Match that to the pinout of your programmer.

And yes, you need to power the module.
mikecameron
mikecameron wrote:
I've recently built a couple warps pcbs and I can get the boards to program via serial, but they do nothing. They pass no audio, and the OSC led doesn't light when you push the button. However, if you power up the system with the osc button pressed, it does blink. So the boot loader seems to be working, which makes me think maybe I have an issue compiling the code. I get no error codes when building firmware, or when programming.

Does anyone have a known working warps hex i can put on this thing to see if it's my build environment or a potential hardware issue?


fwiw i've built braids, elements, clouds, tides, streams building my own firmware and have had success on all attempts. When my first warps failed, I figured it was a hardware problem which is why i built a second and got the same behavior. These are OSHPark boards ordered when the files were originally posted.


Anyone? Any help is appreciated.
squarewavesurfer
I am still trying to track down the problems that are blowing up the r49 resistor on braids v5. I found one short between two pins on the uc1 chip but fixed that up. I also found a short between two pins on the topside for jp2 (see picture). Ive tried to remove the solder bridge with no success. it seems designed to have a bridge based on the look once i removed the solder with a wick but the schematic doesnt seem to show this to confirm it. Anyone know if the jp2 pins solder connection is supposed to be like this?
Altitude909
Yes, those two are connected. You really need to start turning on the ratsnest in eagle, you wont see any connections to the ground plane without it
squarewavesurfer
Altitude909 wrote:
Yes, those two are connected. You really need to start turning on the ratsnest in eagle, you wont see any connections to the ground plane without it
. Yes, I've watched some videos on using eagle and have played around with turning on and off different pieces, but still lots to learn.
HipDestroyer
squarewavesurfer wrote:
I am still trying to track down the problems that are blowing up the r49 resistor on braids v5. I found one short between two pins on the uc1 chip but fixed that up. I also found a short between two pins on the topside for jp2 (see picture). Ive tried to remove the solder bridge with no success. it seems designed to have a bridge based on the look once i removed the solder with a wick but the schematic doesnt seem to show this to confirm it. Anyone know if the jp2 pins solder connection is supposed to be like this?


Also, you have to clean your board before testing. Flux might cause problems in the testing phase
polyot
av500 wrote:
you can always measure the resistance between the +12V and -12V lines to ground before powering up. if you measure something <100 Ohm, don't power it up...


I assume this also would apply to my similar 1206 Resistor burnout on my Rings build? I got ~130k -12V to ground, but can't seem to get a good reading at all +12V to ground. Maybe out of range of my crummy multimeter (upgrade much needed). But since I'm not reading <100 (this meant less than, right?), I might be okay? I replaced the 1206, reflowed some things, but have been reluctant to plug it back in. I'll also try to give it a good cleaning before continuing.

Sorry for sounding like a bit of a noob.

Edit: After some messing about looking for any shorts/bridges, I now have different results. Approx. 71k -12V to ground and +12V to ground rises until it goes beyond what my multimeter can measure, but this time I can actually see it. So I either fixed something or made it worse This is fun!
squarewavesurfer
HipDestroyer wrote:
Also, you have to clean your board before testing. Flux might cause problems in the testing phase


Thanks! I didn't consider that. I plan to clean it up.


It turns out that the solder bridge on two of the uc1 chip's pins was causing the resistor to blow up. Once I fixed that up and replaced the resistor, braids powered up without smoke and I was able to upload the code.

Thanks to all those that helped me along the way! I am very excited to have it working now!



quailquillz
Hello all. Not sure if this belongs in the unsuccessful builds. I am using an stlink-v2 to program my Frames with the Mutable development/ vagrant environment. It eventually worked and the module seems to be working fine but I'm not 100% sure how, so here is my 2-part question:

#1 - What message should I see in the terminal if the firmware was flashed successfully?

(I was able to get it working but only after several tries at programming it. The messages were the same whether the module powered on or not.)

#2 - Is there a reset command from the stlink to the micro after the programming is complete?
satori
I'm working at flashing my completed Peaks build tonight but am not having much luck. The environment set up fine, compiled the code and bootloader all good and vagrant recognises my FTDI Adapter, Ipowered up and flashed the module and after about 2 minutes of writing and sending in vagrant a message said 'verification ok'.

But the leds on the module don't light up when plugged into my modular power supply, and nothing happens, module won't boot up, is that indicative of a build error?

I've reflowed everything, my solder work looks good. The MPU must be working if it accepted the upload right?

Any ideas where I should begin trouble shooting?
quailquillz
Hi Satori. Looks like we had similar problems, (see above post.) My Frames seemed to take the firmware. I received a message to the effect of "verified 43,000 bytes, etc.." but no activity on the LEDs even when cycling power and or hitting the reset, and sysboot buttons.

I checked and re-checked the soldering and retouched some stuff. Finally, I just retried the programming again several times and when I looked down, that big beautiful RGB LED was glowing.

I actually built 2 Frames and the same thing happened both times. I have tested one for a couple hours and everything seems to be working properly. I have a microscope on order to get a better look at the 0.5mm stuff. Will keep you posted when I get it.
satori
Thanks for your reply, that is encouraging!
I think I will just keep re-flashing until it works because the build is fine for sure.
satori
man, i've done it about 60 times and sometimes I get errors, sometimes it flashes but the module never lights up.
satori
Made a video, not sure if anyone can help me shed some light on this?

https://www.youtube.com/watch?v=8xgYPvM9dIs
quailquillz
Satori. What did it do after the end of that video. Shouldnt it go back to the prompt when it's done? Seemed like there was more stuff about to happen in the terminal. Just curious.
satori
It goes back to the command line where you can type things in.... I'm a total noob with all this stuff, but it seemed like it wasn't going to do anything else. So you think maybe it's not fully flashing?
quailquillz
Complete noob here too. I was flashing a different module, but it did pause a few times during programming (maybe a few seconds). There was a bunch of messages scrolling then a pause then more messages etc...

Sorry i dont know enough to help you with the programming portion. Maybe if you post the complete output you are seeing and what steps you took, someone more experienced could help you.

Do you have access to a microscope? The extremely fine pitch stuff is hard to see without one. What looks like a good joint through a magnifier can look totally different though a scope. Just a suggestion. It can really help.
cannonball swandive
What are the DNP's on warps? hmmm.....
Altitude909
cannonball swandive wrote:
What are the DNP's on warps? hmmm.....

do not place
cannonball swandive
Thank you
satori
Still had no luck getting this Peaks to come to life. Here are some close ups, anyone out there see anything suspicious?

Thanks!!





[/img]
jensu
satori wrote:
Still had no luck getting this Peaks to come to life. Here are some close ups, anyone out there see anything suspicious?

Thanks!!


It's really blurry and hard to see, but is your diode on d1 the right way around? It looks to me like the blurry line is in the wrong side.
bonjourmyfriends
Has anyone had any trouble or success with Rings? I've only seen a post or two around the DIY forum. I'm about to print some boards and just curious what to look out for...
satori
I was confused with the orientation of the diodes. Here is a picture of another Peaks pcb which is the same as the populated one.
On the populated, problematic board I have placed the diodes with the line to the left side. Is that correct?

jensu
satori wrote:
I was confused with the orientation of the diodes. Here is a picture of another Peaks pcb which is the same as the populated one.
On the populated, problematic board I have placed the diodes with the line to the left side. Is that correct?


Yup, that is correct. So that's not the problem then.
av500
satori wrote:
Still had no luck getting this Peaks to come to life. Here are some close ups, anyone out there see anything suspicious?


do you see 3.3V at the middle pin of IC1?
satori
^ next step for me is to learn how to use a multimeter smile
If I don't get 3.3v on that middle pin what would that indicate?
av500
satori wrote:
^ next step for me is to learn how to use a multimeter smile
If I don't get 3.3v on that middle pin what would that indicate?


that the CPU has no power. usually they sulk and do nothing in such a situation smile
satori
Great, will learn a bit about my multimeter tonight and start poking around. I've done about a dozen different builds and had 100% success so the troubleshooting process is very new to me. Thanks for your help!
satori
Ok, so I had the leds the wrong way around. I'm an idiot, all is working now, carry on.....
squarewavesurfer
Can anyone assist me in getting my branches programmed? I am using windows 10 with a USBtinyISP programmer v2.0. I have installed WinAVR and USBtinyISP driver.


I have edited both the the path to the avrlib makefile toolchain path and programmer name:

    AVRLIB_TOOLS_PATH = C:\WinAVR-20100110\utils\bin/

    PROGRAMMER ?= usbtiny


I am also to detect the ATmega88 chip from the command prompt (as seen below).

    c:\>avrdude -c usbtiny -p m88

    avrdude: AVR device initialized and ready to accept instructions

    Reading | ################################################## | 100% 0.02s

    avrdude: Device signature = 0x1e930f

    avrdude: safemode: Fuses OK

    avrdude done. Thank you.




When I try to upload the firmware I get an error message saying avrdude: command not found:


    vagrant@vagrant-ubuntu-trusty-64:/vagrant/eurorack-modules$ make -f branches/makefile upload
    C:\WinAVR-20100110\utils\bin/avrdude -V -p m88p -c usbtiny -P usb \
    -B 1 -U flash:w:build/branches/branches.hex:i -U lock:w:0x2f:m
    make: C:WinAVR-20100110utilsbin/avrdude: Command not found
    make: *** [upload] Error 127
    vagrant@vagrant-ubuntu-trusty-64:/vagrant/eurorack-modules$
adam
looks like you're using the mutable dev environment which is linux - it won't like windows software, there should be avrdude installed within the dev environment, should work if you use that one (looks like you're trying to use the avrdude installed in win 10)

or if you have a binary of the branches firmware you can flash that under windows
squarewavesurfer
adam wrote:
looks like you're using the mutable dev environment which is linux - it won't like windows software, there should be avrdude installed within the dev environment, should work if you use that one (looks like you're trying to use the avrdude installed in win 10)

or if you have a binary of the branches firmware you can flash that under windows


Would I need to modify the avrlib makefile to include usbtiny for the programmer name? Do i have to modify the toolchain path to the local avrlib toolpath i cloned to my hard drive from the mutable github?
adam
i'm not sure if the makefile includes invoking avrdude plus arguments, if it does, then yes.

at the moment it looks like you're using the dev environment and calling to the win installations copy of avrdude

you need to check where you cloned the avrlib toolchain to - if you're using the vm you need to clone avrlib using the vm, i have no idea if you need to do this, but all the software etc needs to be installed inside the vm's filesystem (and linux versions), for it to work, you can use apt-get to install software if you need to
sleepgardens
Hello guys, I'm building a Shades and I need a valid alternative to the Texas Instruments LME49720MA/NOPB. There is a minimum order limit of 190 and I just need 4 so...
Mouser suggests me the LME49720MAX/NOPB but I can't seem to find which are the differencies between the two. Is this a suitable replacement?

Thank you for the help.
squarewavesurfer
adam wrote:
i'm not sure if the makefile includes invoking avrdude plus arguments, if it does, then yes.

at the moment it looks like you're using the dev environment and calling to the win installations copy of avrdude

you need to check where you cloned the avrlib toolchain to - if you're using the vm you need to clone avrlib using the vm, i have no idea if you need to do this, but all the software etc needs to be installed inside the vm's filesystem (and linux versions), for it to work, you can use apt-get to install software if you need to


I think I have the avr folders cloned from github now and the avrdude command seems to be fine but it cant find the usbtiny. I have ordered an olimex avr isp mkii hoping that will solve the problem.

I see a lot of posts regarding setting fuses before uploading. Is this only necessary if you are programming outside of the virtual mutable environment?
adam
setting fuses tells the mcu whether to use it's internal clock or a crystal etc, i don't think branches uses a crystal anyway so i think you could do it either way
Altitude909
adam wrote:
setting fuses tells the mcu whether to use it's internal clock or a crystal etc, i don't think branches uses a crystal anyway so i think you could do it either way


No. Fuses MUST be set. It's baked into the makefile so you dont need to program them. Simply make -f branches/makefile bootstrap_all in the VM

You probably need to edit the avrlib/makefile.mk to accommodate the USBtiny and/or path to tools
inlifeindeath
I'm having an issue with a Yarns, hoping someone can help.
Programmed just fine, all seems to work except the CV outs with MIDI input.
All Gate outs work fine and the CV jacks work with the internal oscillators and track great with MIDI input.
Any ideas?
Digitek
Hello people i just build braids didnt solder the pot yeat but my question is if i turn it on the display has to show something or it will show until i program the chip??
what shut i do next...?

thanks
squarewavesurfer
Digitek wrote:
Hello people i just build braids didnt solder the pot yeat but my question is if i turn it on the display has to show something or it will show until i program the chip??
what shut i do next...?

thanks


It will only display something "CSAW" once you program it successfully. Until then, even with eurorack power, the display will be blank.

If you have everything but the pots soldered, power it and then program it.
squarewavesurfer
I got an Olimex avr isp mkII programmer and adapted the ICSP10 to the Mutable Branches 6 pin jtag header.

I get "error in USB receive" when running "make -f branches/makefile bootstrap_all " Any ideas on how to fix?


    c:\Users\xxxxx\.vagrant.d\mutable-dev-environment-master>vagrant up
    Bringing machine 'default' up with 'virtualbox' provider...
    ==> default: Checking if box 'ubuntu/trusty64' is up to date...
    ==> default: A newer version of the box 'ubuntu/trusty64' is available! You currently
    ==> default: have version '20160621.0.0'. The latest is version '20160801.0.0'. Run
    ==> default: `vagrant box update` to update.
    ==> default: Machine already provisioned. Run `vagrant provision` or use the `--provision`
    ==> default: flag to force provisioning. Provisioners marked to run always will still run.

    c:\Users\xxxxx\.vagrant.d\mutable-dev-environment-master>vagrant ssh
    Welcome to Ubuntu 14.04.4 LTS (GNU/Linux 3.13.0-88-generic x86_64)

    * Documentation: https://help.ubuntu.com/

    System information as of Wed Aug 3 17:22:23 UTC 2016

    System load: 0.03 Processes: 90
    Usage of /: 6.6% of 39.34GB Users logged in: 0
    Memory usage: 11% IP address for eth0: 10.0.2.15
    Swap usage: 0%

    Graph this data and manage this system at:
    https://landscape.canonical.com/

    Get cloud support with Ubuntu Advantage Cloud Guest:
    http://www.ubuntu.com/business/services/cloud

    New release '16.04.1 LTS' available.
    Run 'do-release-upgrade' to upgrade to it.


    *** System restart required ***
    Last login: Wed Aug 3 17:22:24 2016 from 10.0.2.2
    vagrant@vagrant-ubuntu-trusty-64:/vagrant/eurorack-modules$ make -f branches/makefile bootstrap_all
    make -f branches/makefile
    make[1]: Entering directory `/vagrant/eurorack-modules'
    make[1]: Nothing to be done for `all'.
    make[1]: Leaving directory `/vagrant/eurorack-modules'
    make -f branches/bootloader/makefile
    make[1]: Entering directory `/vagrant/eurorack-modules'
    make[1]: Nothing to be done for `all'.
    make[1]: Leaving directory `/vagrant/eurorack-modules'
    make -f branches/bootloader/makefile fuses
    make[1]: Entering directory `/vagrant/eurorack-modules'
    /usr/local/CrossPack-AVR/bin/avrdude -V -p m88p -c avrispmkII -P usb -B 10 -e -u \
    -U efuse:w:0xf8:m \
    -U hfuse:w:0xdd:m \
    -U lfuse:w:0xe2:m \
    -U lock:w:0x2f:m
    avrdude: stk500v2_recv_mk2: error in USB receive
    avrdude: stk500v2_recv_mk2: error in USB receive
    avrdude: stk500v2_recv_mk2: error in USB receive
    avrdude: stk500v2_recv_mk2: error in USB receive
    avrdude: stk500v2_recv_mk2: error in USB receive
    avrdude: stk500v2_recv_mk2: error in USB receive
    avrdude: stk500v2_getsync(): timeout communicating with programmer
adam
have you changed the firmware on the olimex to the one for avrdude?
squarewavesurfer
adam wrote:
have you changed the firmware on the olimex to the one for avrdude?


I have not. Can that be done over usb?
adam
yes, it's in the manual
squarewavesurfer
adam wrote:
yes, it's in the manual


I did the firmware update. but still error in usb receive. I noticed that it says "avrdude: stk500_recv_mk2". Shouldn't it be using "avrispmkII" not "stk500" as this is a different programmer?
adam
yes, it's avrispmkII

the other interesting complication is that on ubuntu and variants, versions of avrdude newer than 5.11 don't like this programmer, so you'll have to uninstall avrdude 6, and compile and install v5.11 (using checkinstall is easiest so you can remove it again)
squarewavesurfer
so I moved on to Tides and have soldered all but the pots and jacks. I uploaded the makefile and got some errors and end up with the two lower LEDs lit up red. Any ideas what went wrong?

    vagrant@vagrant-ubuntu-trusty-64:/vagrant/eurorack-modules$ make -f tides/makefile upload_combo_jtag
    openocd -f stmlib/programming/jtag/interface_arm-usb-ocd-h.cfg -f stmlib/programming/jtag/stm32f10x_jtag.cfg -f stmlib/programming/jtag/prelude_f10x.cfg -f stmlib/programming/jtag/erase_f10x.cfg -c "flash write_bank 0 build/tides/tides_bootloader_combo.bin 0x0" -c "verify_image build/tides/tides_bootloader_combo.bin" -f stmlib/programming/jtag/postlude.cfg || openocd -f stmlib/programming/jtag/interface_arm-usb-ocd-h.cfg -f stmlib/programming/jtag/stm32f10x_jtag.cfg -f stmlib/programming/jtag/prelude_f10x.cfg -f stmlib/programming/jtag/erase_f10x.cfg -c "flash write_bank 0 build/tides/tides_bootloader_combo.bin 0x0" -c "verify_image build/tides/tides_bootloader_combo.bin" -f stmlib/programming/jtag/postlude.cfg
    Open On-Chip Debugger 0.9.0 (2016-08-03-15:58)
    Licensed under GNU GPL v2
    For bug reports, read
    http://openocd.org/doc/doxygen/bugs.html
    Info : only one transport option; autoselect 'jtag'
    adapter speed: 1000 kHz
    adapter_nsrst_delay: 200
    jtag_ntrst_delay: 200
    trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain connect_deassert_srst
    Warn : Using DEPRECATED interface driver 'ft2232'
    Info : Consider using the 'ftdi' interface driver, with configuration files in interface/ftdi/...
    Info : max TCK change to: 30000 kHz
    Info : clock speed 1000 kHz
    Info : JTAG tap: stm32.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3)
    Info : JTAG tap: stm32.bs tap/device found: 0x16410041 (mfg: 0x020, part: 0x6410, ver: 0x1)
    Info : stm32.cpu: hardware has 6 breakpoints, 4 watchpoints
    target state: halted
    target halted due to debug-request, current mode: Thread
    xPSR: 0x01000000 pc: 0x08004c66 msp: 0x20000668
    Info : device id = 0x20036410
    Info : ignoring flash probed value, using configured bank size
    Info : flash size = 256kbytes
    stm32x mass erase complete
    Info : JTAG tap: stm32.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3)
    Info : JTAG tap: stm32.bs tap/device found: 0x16410041 (mfg: 0x020, part: 0x6410, ver: 0x1)
    Error: stm32.cpu -- clearing lockup after double fault
    target state: halted
    target halted due to debug-request, current mode: Handler HardFault
    xPSR: 0x01000003 pc: 0xfffffffe msp: 0xffffffdc
    Polling target stm32.cpu failed, trying to reexamine
    Info : stm32.cpu: hardware has 6 breakpoints, 4 watchpoints
    wrote 87392 bytes from file build/tides/tides_bootloader_combo.bin to flash bank 0 at offset 0x00000000 in 3.050093s (27.981 KiB/s)
    verified 87392 bytes in 1.479719s (57.676 KiB/s)
    Info : JTAG tap: stm32.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3)
    Info : JTAG tap: stm32.bs tap/device found: 0x16410041 (mfg: 0x020, part: 0x6410, ver: 0x1)
    Error: DP initialisation failed
    in procedure 'reset' called at file "stmlib/programming/jtag/postlude.cfg", line 24
    in procedure 'ocd_bouncer'


    Open On-Chip Debugger 0.9.0 (2016-08-03-15:58)
    Licensed under GNU GPL v2
    For bug reports, read
    http://openocd.org/doc/doxygen/bugs.html
    Info : only one transport option; autoselect 'jtag'
    adapter speed: 1000 kHz
    adapter_nsrst_delay: 200
    jtag_ntrst_delay: 200
    trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain connect_deassert_srst
    Warn : Using DEPRECATED interface driver 'ft2232'
    Info : Consider using the 'ftdi' interface driver, with configuration files in interface/ftdi/...
    Info : max TCK change to: 30000 kHz
    Info : clock speed 1000 kHz
    Info : JTAG tap: stm32.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3)
    Info : JTAG tap: stm32.bs tap/device found: 0x16410041 (mfg: 0x020, part: 0x6410, ver: 0x1)
    Info : stm32.cpu: hardware has 6 breakpoints, 4 watchpoints
    target state: halted
    target halted due to debug-request, current mode: Handler External Interrupt(25)
    xPSR: 0x41000029 pc: 0x08005478 msp: 0x200006a8
    Info : device id = 0x20036410
    Info : ignoring flash probed value, using configured bank size
    Info : flash size = 256kbytes
    stm32x mass erase complete
    Info : JTAG tap: stm32.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3)
    Info : JTAG tap: stm32.bs tap/device found: 0x16410041 (mfg: 0x020, part: 0x6410, ver: 0x1)
    Error: stm32.cpu -- clearing lockup after double fault
    target state: halted
    target halted due to debug-request, current mode: Handler HardFault
    xPSR: 0x01000003 pc: 0xfffffffe msp: 0xffffffdc
    Polling target stm32.cpu failed, trying to reexamine
    Info : stm32.cpu: hardware has 6 breakpoints, 4 watchpoints
    wrote 87392 bytes from file build/tides/tides_bootloader_combo.bin to flash bank 0 at offset 0x00000000 in 3.024476s (28.218 KiB/s)
    verified 87392 bytes in 1.559886s (54.712 KiB/s)
    Info : JTAG tap: stm32.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3)
    Info : JTAG tap: stm32.bs tap/device found: 0x16410041 (mfg: 0x020, part: 0x6410, ver: 0x1)
    Error: DP initialisation failed
    in procedure 'reset' called at file "stmlib/programming/jtag/postlude.cfg", line 24
    in procedure 'ocd_bouncer'


    make: *** [upload_combo_jtag] Error 1
    vagrant@vagrant-ubuntu-trusty-64:/vagrant/eurorack-modules$


Update: I tried using the module despite getting the error during programming and yet the module seems to function properly. I now have Sheep running on it and all seems very well.
squarewavesurfer
I had a crazy time trying to program Branches but with the help of adam, I was able to program it using Atmel Studio rather than the virtual mutable dev environment.

My setup: I used an Olimex AVR ISP MKII on windows 10. I use windows cmd prompt and have downloaded git bash to allow me to use ssh commands.

Note: the instructions for code compiling may not be 100% correct as I compiled it weeks ago. It was the uploading of the code I couldn't do until today.



Here is how I got it to work:


    1. Use virtual mutable environment to compile the bootloader and code. This will create the build folders: Branches and Branches_Bootloader in \.vagrant.d\mutable-dev-environment-master\eurorack-modules\build
    - make -f branches/bootloader/makefile hex
    - make -f branches/makefile

    2. Install Atmel Studio 7.0 (may not be able to detech Olimex avr isp mkii at first): To fix this error (thanks to Ant2N on the Olimex forums) https://www.olimex.com/forum/index.php?topic=4065.0):

    - Download Zadig: http://zadig.akeo.ie/. Zadig is a USB driver manager for Windows, and saved me a hundred times this year. The last version comes with the libusb-win32 (v1.2.6.0) driver embedded.

    - Open Zadig, Options, List All Devices. The AVRISP mkII device should appear in the list.
    - Replace its current driver by libusb-win32 (v1.2.6.0)

    3. Use Atmel Studio 7.0 to flash the chip:

    - Select Tools -> device programmer
    - Select IVR isp mkii from Tool list
    - select device (select the exact chip: ATmega88PA)
    - select apply
    - program fuses:
    - extended fuse: 0xF8
    - high fuse: 0xDD
    - low fuse: 0xE2
    - program lock bit:
    - lockbit: 0x2F
    - under program file, program device from ELF production file: open bootloader ELF file: /builds/branches_bootloader/branches_bootloader.elf, check flash, then select program
    - under program file, program device from ELF production file: open firmware ELF file: /builds/branches/branches.elf, check flash, then select program


    DONE!
lasesentaysiete
hey all,

I have a Clouds here that seems fully operational. Lights, inputs, outputs all exhibit normal behaviour. Problem is both regulators get hot to the touch, despite both reading 3.3v on the large tabs

Is the excessive heat being caused by a short to ground?
jensu
lasesentaysiete wrote:
hey all,

I have a Clouds here that seems fully operational. Lights, inputs, outputs all exhibit normal behaviour. Problem is both regulators get hot to the touch, despite both reading 3.3v on the large tabs

Is the excessive heat being caused by a short to ground?


How hot. Too hot to touch, or hot enough that you can feel the heat?
lasesentaysiete
jensu wrote:
lasesentaysiete wrote:
hey all,

I have a Clouds here that seems fully operational. Lights, inputs, outputs all exhibit normal behaviour. Problem is both regulators get hot to the touch, despite both reading 3.3v on the large tabs

Is the excessive heat being caused by a short to ground?


How hot. Too hot to touch, or hot enough that you can feel the heat?


I can touch and leave my finger there for a bit. But it doesn't seem normal. Maybe it is?
jensu
lasesentaysiete wrote:
jensu wrote:
lasesentaysiete wrote:
hey all,

I have a Clouds here that seems fully operational. Lights, inputs, outputs all exhibit normal behaviour. Problem is both regulators get hot to the touch, despite both reading 3.3v on the large tabs

Is the excessive heat being caused by a short to ground?


How hot. Too hot to touch, or hot enough that you can feel the heat?


I can touch and leave my finger there for a bit. But it doesn't seem normal. Maybe it is?



It's converting 12V all the way down to 3.3V, so it's alot of energy it needs to get rid of.
It's rated up to 125 C, so if the module is acting like it should (a short would most likely make it not) i wouldn't worry about it.

EDIT: Of cause if someone with DIY clouds can say that theirs is not hot at all, you might want to worry about it confused
lasesentaysiete
jensu wrote:
lasesentaysiete wrote:
jensu wrote:
lasesentaysiete wrote:
hey all,

I have a Clouds here that seems fully operational. Lights, inputs, outputs all exhibit normal behaviour. Problem is both regulators get hot to the touch, despite both reading 3.3v on the large tabs

Is the excessive heat being caused by a short to ground?


How hot. Too hot to touch, or hot enough that you can feel the heat?


I can touch and leave my finger there for a bit. But it doesn't seem normal. Maybe it is?




It's converting 12V all the way down to 3.3V, so it's alot of energy it needs to get rid of.
It's rated up to 125 C, so if the module is acting like it should (a short would most likely make it not) i wouldn't worry about it.

EDIT: Of cause if someone with DIY clouds can say that theirs is not hot at all, you might want to worry about it confused


So if voltages are good, and sound is good, its A OK?

How hot SHOULD it get? (if anyone actually knows).
lasesentaysiete
EDIT 2: RESOLVED. SEE BELOW

I have a Rings that seems fine except that the left LED (polyphony) does not change color. It has 3 modes:
1. Green
2. Green
3. Off
It blinks for triggers as well.

Has anyone seen this? Where do I look?


EDIT: the led itself is functional.

EDIT 2: The Problem was a non-functional via (damaged?) situated along the signal path between the ARM and the LED. I repaired the via and voilà.

***Not sure if this was a board problem or a me problem. Probably the latter but FYI***
taichber
I've built the last two days a braids and a yarns module. The braids worked right away perfectly.

i could program the yarns successfully but the display or led does not show anything.

I checked everything with a magnifier but couldn't find anything.

Any ideas what I could check?

Here is the output after the firmware update:

    openocd -f stmlib/programming/jtag/interface_arm-usb-ocd-h.cfg -f stmlib/programming/jtag/stm32f10x_jtag.cfg -f stmlib/programming/jtag/prelude_f10x.cfg -f stmlib/programming/jtag/erase_f10x.cfg -c "flash write_bank 0 build/yarns/yarns_bootloader_combo.bin 0x0" -c "verify_image build/yarns/yarns_bootloader_combo.bin" -f stmlib/programming/jtag/postlude.cfg || openocd -f stmlib/programming/jtag/interface_arm-usb-ocd-h.cfg -f stmlib/programming/jtag/stm32f10x_jtag.cfg -f stmlib/programming/jtag/prelude_f10x.cfg -f stmlib/programming/jtag/erase_f10x.cfg -c "flash write_bank 0 build/yarns/yarns_bootloader_combo.bin 0x0" -c "verify_image build/yarns/yarns_bootloader_combo.bin" -f stmlib/programming/jtag/postlude.cfg
    Open On-Chip Debugger 0.8.0 (2014-10-20-22:02)
    Licensed under GNU GPL v2
    For bug reports, read
    http://openocd.sourceforge.net/doc/doxygen/bugs.html
    Info : only one transport option; autoselect 'jtag'
    adapter speed: 1000 kHz
    adapter_nsrst_delay: 200
    jtag_ntrst_delay: 200
    trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain connect_deassert_srst
    Info : clock speed 1000 kHz
    Info : JTAG tap: stm32.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3)
    Info : JTAG tap: stm32.bs tap/device found: 0x16410041 (mfg: 0x020, part: 0x6410, ver: 0x1)
    Info : stm32.cpu: hardware has 6 breakpoints, 4 watchpoints
    target state: halted
    target halted due to debug-request, current mode: Handler HardFault
    xPSR: 0x41000003 pc: 0x0800010c msp: 0xffffffe0
    Info : device id = 0x20036410
    Info : ignoring flash probed value, using configured bank size
    Info : flash size = 256kbytes
    stm32x mass erase complete
    Info : JTAG tap: stm32.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3)
    Info : JTAG tap: stm32.bs tap/device found: 0x16410041 (mfg: 0x020, part: 0x6410, ver: 0x1)
    Error: stm32.cpu -- clearing lockup after double fault
    target state: halted
    target halted due to debug-request, current mode: Handler HardFault
    xPSR: 0x01000003 pc: 0xfffffffe msp: 0xffffffdc
    Polling target stm32.cpu failed, GDB will be halted. Polling again in 100ms
    Polling target stm32.cpu succeeded again
    wrote 62264 bytes from file build/yarns/yarns_bootloader_combo.bin to flash bank 0 at offset 0x00000000 in 2.003412s (30.351 KiB/s)
    verified 62264 bytes in 0.940455s (64.655 KiB/s)
    Info : JTAG tap: stm32.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3)
    Info : JTAG tap: stm32.bs tap/device found: 0x16410041 (mfg: 0x020, part: 0x6410, ver: 0x1)
    shutdown command invoked


Just a guess. Is the white bar pin 1 on the CD74HC595?

HipDestroyer
taichber wrote:
I've built the last two days a braids and a yarns module. The braids worked right away perfectly.

i could program the yarns successfully but the display or led does not show anything.

I checked everything with a magnifier but couldn't find anything.

Any ideas what I could check?

Here is the output after the firmware update:

    openocd -f stmlib/programming/jtag/interface_arm-usb-ocd-h.cfg -f stmlib/programming/jtag/stm32f10x_jtag.cfg -f stmlib/programming/jtag/prelude_f10x.cfg -f stmlib/programming/jtag/erase_f10x.cfg -c "flash write_bank 0 build/yarns/yarns_bootloader_combo.bin 0x0" -c "verify_image build/yarns/yarns_bootloader_combo.bin" -f stmlib/programming/jtag/postlude.cfg || openocd -f stmlib/programming/jtag/interface_arm-usb-ocd-h.cfg -f stmlib/programming/jtag/stm32f10x_jtag.cfg -f stmlib/programming/jtag/prelude_f10x.cfg -f stmlib/programming/jtag/erase_f10x.cfg -c "flash write_bank 0 build/yarns/yarns_bootloader_combo.bin 0x0" -c "verify_image build/yarns/yarns_bootloader_combo.bin" -f stmlib/programming/jtag/postlude.cfg
    Open On-Chip Debugger 0.8.0 (2014-10-20-22:02)
    Licensed under GNU GPL v2
    For bug reports, read
    http://openocd.sourceforge.net/doc/doxygen/bugs.html
    Info : only one transport option; autoselect 'jtag'
    adapter speed: 1000 kHz
    adapter_nsrst_delay: 200
    jtag_ntrst_delay: 200
    trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain connect_deassert_srst
    Info : clock speed 1000 kHz
    Info : JTAG tap: stm32.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3)
    Info : JTAG tap: stm32.bs tap/device found: 0x16410041 (mfg: 0x020, part: 0x6410, ver: 0x1)
    Info : stm32.cpu: hardware has 6 breakpoints, 4 watchpoints
    target state: halted
    target halted due to debug-request, current mode: Handler HardFault
    xPSR: 0x41000003 pc: 0x0800010c msp: 0xffffffe0
    Info : device id = 0x20036410
    Info : ignoring flash probed value, using configured bank size
    Info : flash size = 256kbytes
    stm32x mass erase complete
    Info : JTAG tap: stm32.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3)
    Info : JTAG tap: stm32.bs tap/device found: 0x16410041 (mfg: 0x020, part: 0x6410, ver: 0x1)
    Error: stm32.cpu -- clearing lockup after double fault
    target state: halted
    target halted due to debug-request, current mode: Handler HardFault
    xPSR: 0x01000003 pc: 0xfffffffe msp: 0xffffffdc
    Polling target stm32.cpu failed, GDB will be halted. Polling again in 100ms
    Polling target stm32.cpu succeeded again
    wrote 62264 bytes from file build/yarns/yarns_bootloader_combo.bin to flash bank 0 at offset 0x00000000 in 2.003412s (30.351 KiB/s)
    verified 62264 bytes in 0.940455s (64.655 KiB/s)
    Info : JTAG tap: stm32.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3)
    Info : JTAG tap: stm32.bs tap/device found: 0x16410041 (mfg: 0x020, part: 0x6410, ver: 0x1)
    shutdown command invoked


First thing to check is if IC2+IC3 are installed correctly. The double line in Eagle board file should match the slanted side of the chip:

taichber
HipDestroyer wrote:

First thing to check is if IC2+IC3 are installed correctly. The double line in Eagle board file should match the slanted side of the chip:


Thanks.
The slanted side is not easy to find. used magnifiers. IC2+IC3 look like installed correctly.

Any other ideas?
taichber
HipDestroyer wrote:
taichber wrote:
I've built the last two days a braids and a yarns module. The braids worked right away perfectly.

i could program the yarns successfully but the display or led does not show anything.

I checked everything with a magnifier but couldn't find anything.

Any ideas what I could check?

Here is the output after the firmware update:

    openocd -f stmlib/programming/jtag/interface_arm-usb-ocd-h.cfg -f stmlib/programming/jtag/stm32f10x_jtag.cfg -f stmlib/programming/jtag/prelude_f10x.cfg -f stmlib/programming/jtag/erase_f10x.cfg -c "flash write_bank 0 build/yarns/yarns_bootloader_combo.bin 0x0" -c "verify_image build/yarns/yarns_bootloader_combo.bin" -f stmlib/programming/jtag/postlude.cfg || openocd -f stmlib/programming/jtag/interface_arm-usb-ocd-h.cfg -f stmlib/programming/jtag/stm32f10x_jtag.cfg -f stmlib/programming/jtag/prelude_f10x.cfg -f stmlib/programming/jtag/erase_f10x.cfg -c "flash write_bank 0 build/yarns/yarns_bootloader_combo.bin 0x0" -c "verify_image build/yarns/yarns_bootloader_combo.bin" -f stmlib/programming/jtag/postlude.cfg
    Open On-Chip Debugger 0.8.0 (2014-10-20-22:02)
    Licensed under GNU GPL v2
    For bug reports, read
    http://openocd.sourceforge.net/doc/doxygen/bugs.html
    Info : only one transport option; autoselect 'jtag'
    adapter speed: 1000 kHz
    adapter_nsrst_delay: 200
    jtag_ntrst_delay: 200
    trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain connect_deassert_srst
    Info : clock speed 1000 kHz
    Info : JTAG tap: stm32.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3)
    Info : JTAG tap: stm32.bs tap/device found: 0x16410041 (mfg: 0x020, part: 0x6410, ver: 0x1)
    Info : stm32.cpu: hardware has 6 breakpoints, 4 watchpoints
    target state: halted
    target halted due to debug-request, current mode: Handler HardFault
    xPSR: 0x41000003 pc: 0x0800010c msp: 0xffffffe0
    Info : device id = 0x20036410
    Info : ignoring flash probed value, using configured bank size
    Info : flash size = 256kbytes
    stm32x mass erase complete
    Info : JTAG tap: stm32.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3)
    Info : JTAG tap: stm32.bs tap/device found: 0x16410041 (mfg: 0x020, part: 0x6410, ver: 0x1)
    Error: stm32.cpu -- clearing lockup after double fault
    target state: halted
    target halted due to debug-request, current mode: Handler HardFault
    xPSR: 0x01000003 pc: 0xfffffffe msp: 0xffffffdc
    Polling target stm32.cpu failed, GDB will be halted. Polling again in 100ms
    Polling target stm32.cpu succeeded again
    wrote 62264 bytes from file build/yarns/yarns_bootloader_combo.bin to flash bank 0 at offset 0x00000000 in 2.003412s (30.351 KiB/s)
    verified 62264 bytes in 0.940455s (64.655 KiB/s)
    Info : JTAG tap: stm32.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3)
    Info : JTAG tap: stm32.bs tap/device found: 0x16410041 (mfg: 0x020, part: 0x6410, ver: 0x1)
    shutdown command invoked


First thing to check is if IC2+IC3 are installed correctly. The double line in Eagle board file should match the slanted side of the chip:


The display is working! It looks like a problem with the firmware transfer.
I pressed Yarns’ encoder at power on.

It shows the snake pattern (first character).
This shows at least the boot loader is working.

I tried a sysex transfer with Elektron C6. After starting the transfer both characters start cycling. The cycling does not stop after the sysex transfer is complete. No "OK" no "ER".

After power off/power on no display. With encoder pressed the snake pattern is on the second character ... strange. A new sysex transfer has no impact on the display - still snake pattern on the right character.

Any ideas? Maybe my hex file is wrong??
taichber
taichber wrote:

The display is working! It looks like a problem with the firmware transfer.
I pressed Yarns’ encoder at power on.

It shows the snake pattern (first character).
This shows at least the boot loader is working.

I tried a sysex transfer with Elektron C6. After starting the transfer both characters start cycling. The cycling does not stop after the sysex transfer is complete. No "OK" no "ER".


RESOLVED!
Firmware update with hex file did not work. Only boot loader.
Transfer of sysex worked, but with slower transfer speed.

Now I need to check the module functions.

Thanks.
satori
Hi all smile
I just finished my Braids and turned it on for the first time. Module flashed fine, menu is coming up and behaving as expected.
Only trouble is there is no sound coming out the output!
Any ideas on where I should start troubleshooting?
Thanks!
satori
All good, solder bridge on the DAC. All working now! smile
lasesentaysiete
satori wrote:
All good, solder bridge on the DAC. All working now! smile


I was going to suggest to check/reflow the dac (and any other suspect ics), but you beat me to it. Ususally when it's half-working, there's just a bridge somewhere.
squarewavesurfer
I have encountered a problem with the Branches I built.

Channel 1 works perfectly but Channel two does not. Channel 2 will either output all output 2 trigs (green LED) in one mode and will output alternating green/red trigs (not random, just 50/50 red/green) in the other mode. The potentiometer does not seem to affect the output in either mode.

Any help troubleshooting would be great!
lasesentaysiete
squarewavesurfer wrote:
I have encountered a problem with the Branches I built.

Channel 1 works perfectly but Channel two does not. Channel 2 will either output all output 2 trigs (green LED) in one mode and will output alternating green/red trigs (not random, just 50/50 red/green) in the other mode. The potentiometer does not seem to affect the output in either mode.

Any help troubleshooting would be great!


to quote myself
Quote:
Ususally when it's half-working, there's just a bridge somewhere.


quite a few times now I've felt hopeless only to break through the threshhold by reflowing cool
billieblaze
@squarewavesurfer: I had the same problem, and further investigation found r7 / r8 were mounted wrong. they should be vertically on the board, not horizontal.
squarewavesurfer
billieblaze wrote:
@squarewavesurfer: I had the same problem, and further investigation found r7 / r8 were mounted wrong. they should be vertically on the board, not horizontal.


Yes! I have two horizontal resistors when they should be vertical. I am going to see if I can undo this error tomorrow. Thanks a lot!!!


Update: this was the problem. R7 and R8 were soldered wrong. I was able to desolder and correct this. My Branches now works perfectly!
kfraser
Hello, I recently built a Frames and Braids and was wondering before flashing should I see lights on Frames and screen on Braids light up when I power it on? I have tried pushing over the bootloader and firmware and I get this error when doing so...
hla_jtag
adapter speed: 1000 kHz
adapter_nsrst_delay: 200
trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain connect_deassert_srst
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
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 v25 API v2 SWIM v4 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 0.003158
Error: target voltage may be too low for reliable debugging
Error: init mode failed (unable to connect to the target)
in procedure 'init' called at file "stmlib/programming/jtag/prelude_f10x.cfg", line 23
in procedure 'ocd_bouncer'

make: *** [upload_combo_jtag] Error 1


This error and not seeing any activity on the modules when powering up makes me believe that there's something wrong with the component placement/soldering, just wanted to make sure first before I begin troubleshooting. Thanks.
HipDestroyer
kfraser wrote:
Hello, I recently built a Frames and Braids and was wondering before flashing should I see lights on Frames and screen on Braids light up when I power it on? I have tried pushing over the bootloader and firmware and I get this error when doing so...
hla_jtag
adapter speed: 1000 kHz
adapter_nsrst_delay: 200
trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain connect_deassert_srst
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
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 v25 API v2 SWIM v4 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 0.003158
Error: target voltage may be too low for reliable debugging
Error: init mode failed (unable to connect to the target)
in procedure 'init' called at file "stmlib/programming/jtag/prelude_f10x.cfg", line 23
in procedure 'ocd_bouncer'

make: *** [upload_combo_jtag] Error 1


This error and not seeing any activity on the modules when powering up makes me believe that there's something wrong with the component placement/soldering, just wanted to make sure first before I begin troubleshooting. Thanks.


It looks like a hardware problem to me. Check the orientation of your power diodes and that all ic's get the proper supply voltage
kfraser
Thanks HipDestroyer , that is what I suspected. I will take a look at those this evening.
taichber
djamsia wrote:
I have a little problem with my Yarns.
Apparently this well programmed via JTAG, but I cant see on the screen the digits, but snake boot-mode if it works and i can see the snake running .. I think there are more people with the same problem. What's the trick?

Thanks


Did you find a solution?
I had the same problem with yarns. The transfer was sucessful but no display. Only the snake pattern (-> shows the the bootloader works).

I finally solved the problem with a sysex transfer. Yarns is working perfectly.
jimi23
Having issues with this afternoons builds, Tides and Peaks. I've programmed with the .hex files on the mutable with binaries github, using a STLINK V2 adaptor.
I'm getting positive feedback from STLINK utility that the firmware has taken, and I programmed a braids and elements this way too which worked.

But im getting nothing from the module, only a constant voltage out of Tides and Peaks outputs. I know I could've messed up the DAC, but not even the LED's light. Looking at the schematic on both of these modules I should be able to get LED feedback regardless of errors in the output circuitry as the LED's only connect to the micro.

Granted I don't have the correct LED's installed (they're coming on a separate order). I've cleaned the board with isopropyl alcohol and inspected under x12 and there are no bridges on the MCU

Next step is to invest time in getting vagrant working and compile my own code I guess seriously, i just don't get it
HipDestroyer
jimi23 wrote:
Having issues with this afternoons builds, Tides and Peaks. I've programmed with the .hex files on the mutable with binaries github, using a STLINK V2 adaptor.
I'm getting positive feedback from STLINK utility that the firmware has taken, and I programmed a braids and elements this way too which worked.

But im getting nothing from the module, only a constant voltage out of Tides and Peaks outputs. I know I could've messed up the DAC, but not even the LED's light. Looking at the schematic on both of these modules I should be able to get LED feedback regardless of errors in the output circuitry as the LED's only connect to the micro.

Granted I don't have the correct LED's installed (they're coming on a separate order). I've cleaned the board with isopropyl alcohol and inspected under x12 and there are no bridges on the MCU

Next step is to invest time in getting vagrant working and compile my own code I guess seriously, i just don't get it


Sounds like a hardware problem. Whip out your flux, reflow all ic's and double-quadruple check the orientation of all components that need proper orientation
nevetsokyeron
Altitude909 wrote:
adam wrote:
setting fuses tells the mcu whether to use it's internal clock or a crystal etc, i don't think branches uses a crystal anyway so i think you could do it either way


No. Fuses MUST be set. It's baked into the makefile so you dont need to program them. Simply make -f branches/makefile bootstrap_all in the VM

You probably need to edit the avrlib/makefile.mk to accommodate the USBtiny and/or path to tools


Could you explain this? What does it mean to "set the fuses"? Is this something you have to do on a first time flash of a blank chip?

Would I need to do that on a Warps (which has a crystal I believe)?
jimi23
HipDestroyer wrote:
jimi23 wrote:
Having issues with this afternoons builds, Tides and Peaks. I've programmed with the .hex files on the mutable with binaries github, using a STLINK V2 adaptor.
I'm getting positive feedback from STLINK utility that the firmware has taken, and I programmed a braids and elements this way too which worked.

But im getting nothing from the module, only a constant voltage out of Tides and Peaks outputs. I know I could've messed up the DAC, but not even the LED's light. Looking at the schematic on both of these modules I should be able to get LED feedback regardless of errors in the output circuitry as the LED's only connect to the micro.

Granted I don't have the correct LED's installed (they're coming on a separate order). I've cleaned the board with isopropyl alcohol and inspected under x12 and there are no bridges on the MCU

Next step is to invest time in getting vagrant working and compile my own code I guess seriously, i just don't get it


Sounds like a hardware problem. Whip out your flux, reflow all ic's and double-quadruple check the orientation of all components that need proper orientation


Seems it was actually firmware. Got vagrant working in around an hour, which was pretty easy for someone with no vm, ssh or terminal knowledge. Built and flashed the firmware and now have got a working tides!

Will try and stick with the vagrant dev environment from now on. Actually dont have much of a choice, installing it seems to have altered ST-LINK usb drivers, ST-LINK utility won't recognise the device anymore.
taconium
So...

Having a really bizarre issue with a Peaks build.

Everything looks good, flashed successfully, and the module basically works correctly.

But if I turn pot 3 up all the way, the module locks up. Any running LFO continues (and in my testing so far, so do drums, with external triggers), but all controls become non-responsive. LEDs stay lit (as they were), but no buttons work, the trigger buttons don't respond and no pot values are tracked.

Adding to the strangeness, I can sometimes turn pot 3 up all the way, if pot two is most of the way ccw.

Hitting reset clears the issue, assuming I dial pot 3 back a bit.

Anyone have any suggestions as to where I should focus my troubleshooting? I've tried checking every joint on the board, and I'm just not seeing the issue.

I've attached the last flash (via JTAG), just in case something looks fishy there.
lasesentaysiete
Have you tried re-flashing to see if you get the same issue?
taconium wrote:
So...

Having a really bizarre issue with a Peaks build.

Everything looks good, flashed successfully, and the module basically works correctly.

But if I turn pot 3 up all the way, the module locks up. Any running LFO continues (and in my testing so far, so do drums, with external triggers), but all controls become non-responsive. LEDs stay lit (as they were), but no buttons work, the trigger buttons don't respond and no pot values are tracked.

Adding to the strangeness, I can sometimes turn pot 3 up all the way, if pot two is most of the way ccw.

Hitting reset clears the issue, assuming I dial pot 3 back a bit.

Anyone have any suggestions as to where I should focus my troubleshooting? I've tried checking every joint on the board, and I'm just not seeing the issue.

I've attached the last flash (via JTAG), just in case something looks fishy there.
taconium
lasesentaysiete wrote:
Have you tried re-flashing to see if you get the same issue?


I have tried reflashing a few times, but the issue persists.
lasesentaysiete
if you've compiled the code using Olivier's dev env it should be ok. Have you checked orientation of the components? I'd reflow ecerything just in case.
taconium wrote:
lasesentaysiete wrote:
Have you tried re-flashing to see if you get the same issue?


I have tried reflashing a few times, but the issue persists.
taconium
Yup, am using the mutable dev environment. And I've reflowed any joints that looked suspicious, don't think there's any orientation issues, have gone back over the cpu a few times, even found a faulty resistor (reading 3k instead of 3.3k) and replaced it. If it's a problem on the board, I'm just not seeing it.

I think my next step is to get some sleep and comb back over everything tomorrow.

lasesentaysiete wrote:
if you've compiled the code using Olivier's dev env it should be ok. Have you checked orientation of the components? I'd reflow ecerything just in case.
taconium wrote:
lasesentaysiete wrote:
Have you tried re-flashing to see if you get the same issue?


I have tried reflashing a few times, but the issue persists.
lasesentaysiete
some high res photos would help as well.
taconium wrote:
Yup, am using the mutable dev environment. And I've reflowed any joints that looked suspicious, don't think there's any orientation issues, have gone back over the cpu a few times, even found a faulty resistor (reading 3k instead of 3.3k) and replaced it. If it's a problem on the board, I'm just not seeing it.

I think my next step is to get some sleep and comb back over everything tomorrow.

taconium
Actually, I think I got it! It's peanut butter jelly time!

Dumped a ton of flux on the cpu pins, heated up each pin, and focused on a couple spots that looked like they may have been bridged (hard to tell, I need a better loupe).

Thoroughly cleaned up the flux and couldn't repro the issue after testing for a half hour or so.

So that's my third victory after Yarns and Branches! Treble yay!

Thanks for the tips!

lasesentaysiete wrote:
some high res photos would help as well.
taconium wrote:
Yup, am using the mutable dev environment. And I've reflowed any joints that looked suspicious, don't think there's any orientation issues, have gone back over the cpu a few times, even found a faulty resistor (reading 3k instead of 3.3k) and replaced it. If it's a problem on the board, I'm just not seeing it.

I think my next step is to get some sleep and comb back over everything tomorrow.

lasesentaysiete
taconium wrote:
Actually, I think I got it! It's peanut butter jelly time!

Dumped a ton of flux on the cpu pins, heated up each pin, and focused on a couple spots that looked like they may have been bridged (hard to tell, I need a better loupe).

Thoroughly cleaned up the flux and couldn't repro the issue after testing for a half hour or so.


yeah, a good loupe and lighting. I find natural (sun) light works best for me.
wavefold
https://www.amazon.it/STAZIONE-SALDANTE-DISSALDANTE-SALDATORE-DISSALDA TORE/dp/B007H1U1YK/ref=pd_sim_sbs_60_4?ie=UTF8&psc=1&refRID=GNV96APXC6 NXYACYNQT8

speaking of hot air, could this be a decent cheapo solution?
nevetsokyeron
Warps question:

For the two DNP (do not place) spots near the jacks on the Warps pcb - does this require a jumper between those pads, or just leave them unpopulated?

Thanks!
taconium
Well, the problem came back after a while. I'm thinking there's still got to be an mcu pin issue and cooling back down brought the iffy connection back.

Very frustrating. I'll clean things up and try getting some pictures up later, in case anyone has any thoughts.

The good news is, everything works perfectly, so long as I remember to never turn pot 3 up all the way. Yay?

lasesentaysiete wrote:
taconium wrote:
Actually, I think I got it! It's peanut butter jelly time!

Dumped a ton of flux on the cpu pins, heated up each pin, and focused on a couple spots that looked like they may have been bridged (hard to tell, I need a better loupe).

Thoroughly cleaned up the flux and couldn't repro the issue after testing for a half hour or so.


yeah, a good loupe and lighting. I find natural (sun) light works best for me.
ZZ Ardoz
Anyone had any joy with ST-Link V2 and El Capitan? Built both Rings and Streams, and both check out as far as voltages, etc, just no luck uploading from my mac. Always the same ocd error. 2 days of searching and trying solutions has lead nowhere

Any clues?
lasesentaysiete
don't remember what error 2 is, but when you run lsusb, does the stlink show up? And is the computer recognizing it through usb? (system report or whatever its called).

I had a similar problem, but it was the computer, no the os. I ended up having to use a different computer. If you have access to another, try it.
ZZ Ardoz wrote:
Anyone had any joy with ST-Link V2 and El Capitan? Built both Rings and Streams, and both check out as far as voltages, etc, just no luck uploading from my mac. Always the same ocd error. 2 days of searching and trying solutions has lead nowhere

Any clues?
ZZ Ardoz
lasesentaysiete wrote:
don't remember what error 2 is, but when you run lsusb, does the stlink show up? And is the computer recognizing it through usb? (system report or whatever its called).

I had a similar problem, but it was the computer, no the os. I ended up having to use a different computer. If you have access to another, try it.
ZZ Ardoz wrote:
Anyone had any joy with ST-Link V2 and El Capitan? Built both Rings and Streams, and both check out as far as voltages, etc, just no luck uploading from my mac. Always the same ocd error. 2 days of searching and trying solutions has lead nowhere

Any clues?


2 was the number of days looking for a solution. The error was the same reported by a few others - the one ending with
Quote:
in procedure 'init' called at file "stmlib/programming/jtag/prelude_f4xx.cfg", line 23
in procedure 'ocd_bouncer'


Tried 2 different macs, same problem. Thanks though
lasesentaysiete
what about this?
lasesentaysiete wrote:
when you run lsusb, does the stlink show up? And is the computer recognizing it through usb?
okuhtfesa
Hey guys,

I'm actually having exactly the same problem under OS X Mavericks 10.9.5 :

Quote:
Open On-Chip Debugger 0.9.0 (2016-09-08-13:07)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
hla_jtag
adapter speed: 2000 kHz
adapter_nsrst_delay: 100
trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain connect_deassert_srst
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
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
Error: open failed
in procedure 'init' called at file "stmlib/programming/jtag/prelude_f4xx.cfg", line 23
in procedure 'ocd_bouncer'

make: *** [upload_combo_jtag] Error 1


Indeed, it may comes from the St-link V2 not being recognized, "lsusb" command gives :
Quote:

Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub


STLink USB VirtualBox is set up with both IDs 0483 ; 3748 which seems correct.

I tried to update STLink V2 firmware, but still no clue. I'm gonna try on a PC Windows OS but if you have ideas with OS X please let us know !
lasesentaysiete
this means its not seeing it. Are you using the mutable dev env? Have you entered this?:
export PGM_INTERFACE=stlink-v2
export PGM_INTERFACE_TYPE=hla

I had this problem then switched computers and the new one saw the stlink right away. I've since tried it on a pc successfully as well.

I'm kind of annoyed at having to use my girlfriend's computer to flash modules, though (so is she) so I'm looking into a straightforward fix for this. I'll report back if I find anything.
okuhtfesa wrote:


Indeed, it may comes from the St-link V2 not being recognized, "lsusb" command gives :
Quote:

Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub


okuhtfesa
Quote:
Are you using the mutable dev env? Have you entered this?:
export PGM_INTERFACE=stlink-v2
export PGM_INTERFACE_TYPE=hla


Yes, but do you get any feedback from Terminal then, cause I don't.

Quote:
I'm kind of annoyed at having to use my girlfriend's computer to flash modules


Haha, I know exactly how it feels d'oh!
lasesentaysiete
when it works, running this command and the lsusb, the stlink will show up in terminal. when it doesn't, well, you know what that looks like.
okuhtfesa wrote:
Quote:
Are you using the mutable dev env? Have you entered this?:
export PGM_INTERFACE=stlink-v2
export PGM_INTERFACE_TYPE=hla


Yes, but do you get any feedback from Terminal then, cause I don't.

ZZ Ardoz
lasesentaysiete wrote:
what about this?
lasesentaysiete wrote:
when you run lsusb, does the stlink show up? And is the computer recognizing it through usb?


Yes to both

Also using fresh install of the VM and issued the export PGM commands
ZZ Ardoz
okuhtfesa wrote:
Quote:
Are you using the mutable dev env? Have you entered this?:
export PGM_INTERFACE=stlink-v2
export PGM_INTERFACE_TYPE=hla


Yes, but do you get any feedback from Terminal then, cause I don't.

Quote:
I'm kind of annoyed at having to use my girlfriend's computer to flash modules


Haha, I know exactly how it feels d'oh!


try this in terminal

Quote:
system_profiler SPUSBDataType


it should show up in that response
lasesentaysiete
if the stlink shows up in terminal, and you're using the mutable dev env, I'd say hardware. Assuming the basic stuff is right, like cable orientation, module is powered, etc.
Do the compiled codes appear in the "build" folder?
Pictures?
ZZ Ardoz wrote:
lasesentaysiete wrote:
what about this?
lasesentaysiete wrote:
when you run lsusb, does the stlink show up? And is the computer recognizing it through usb?


Yes to both

Also using fresh install of the VM and issued the export PGM commands
okuhtfesa
Thx ZZ Ardoz for the tip. It looks like OSX can read my STLink device, but is my USB filter OK ?



Also, did you try to upgrade Vagrant ? IDK if it's necessary, but I get this message first :

Quote:
==> default: Checking if box 'ubuntu/trusty64' is up to date...
==> default: A newer version of the box 'ubuntu/trusty64' is available! You currently
==> default: have version '20160830.0.0'. The latest is version '20160906.0.0'. Run
==> default: `vagrant box update` to update.
ZZ Ardoz
lasesentaysiete wrote:
if the stlink shows up in terminal, and you're using the mutable dev env, I'd say hardware. Assuming the basic stuff is right, like cable orientation, module is powered, etc.
Do the compiled codes appear in the "build" folder?
Pictures?
ZZ Ardoz wrote:
lasesentaysiete wrote:
what about this?
lasesentaysiete wrote:
when you run lsusb, does the stlink show up? And is the computer recognizing it through usb?


Yes to both

Also using fresh install of the VM and issued the export PGM commands


Compiled codes are all fine, and where they should be. I can upload pictures later, but as it is happening in two modules the same, and it is the same if they are connected to the ST-Link or not, and the fact that both meter as they should at all the chips and no shorts and no smoke yet (!) I think this might be a similar problem as I've seen around while searching. I have an FTDI Friend showing up today - I'll test with that - anyone know if there is a way to do FTDI for Streams?
ZZ Ardoz
okuhtfesa wrote:
Thx ZZ Ardoz for the tip. It looks like OSX can read my STLink device, but is my USB filter OK ?



Also, did you try to upgrade Vagrant ? IDK if it's necessary, but I get this message first :



Looks OK to me, but I'm wondering if it wants a serial number.

Quote:
==> default: Checking if box 'ubuntu/trusty64' is up to date...
==> default: A newer version of the box 'ubuntu/trusty64' is available! You currently
==> default: have version '20160830.0.0'. The latest is version '20160906.0.0'. Run
==> default: `vagrant box update` to update.


Did that update, but no difference
lasesentaysiete
ok, just one thing: when I asked if the stlink shows up in terminal, I should have asked if it shows up in the virtual environment. Running that command you posted above outside of the environment is like checking "rapport système" (system report in english?) in the "about this mac" section. It tells you that your computer sees the stlink, but thats it. I THINK!
ZZ Ardoz wrote:


Compiled codes are all fine, and where they should be. I can upload pictures later, but as it is happening in two modules the same, and it is the same if they are connected to the ST-Link or not, and the fact that both meter as they should at all the chips and no shorts and no smoke yet (!) I think this might be a similar problem as I've seen around while searching. I have an FTDI Friend showing up today - I'll test with that - anyone know if there is a way to do FTDI for Streams?
ZZ Ardoz
One thing - is anyone using the Olimex 20-10 arm-jtag adapter? Success?
okuhtfesa
I guess many do, with success

https://medium.com/music-thing-modular-notes/how-to-get-started-writin g-your-own-firmware-for-mutable-instruments-clouds-a08173cec317#.f130v z5br
lasesentaysiete
me. works fine.
ZZ Ardoz wrote:
One thing - is anyone using the Olimex 20-10 arm-jtag adapter? Success?
ZZ Ardoz
lasesentaysiete wrote:
me. works fine.
ZZ Ardoz wrote:
One thing - is anyone using the Olimex 20-10 arm-jtag adapter? Success?


I misspoke earlier - it is in fact not showing up when I run lsusb - just this

Quote:
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub


I have a filter set up in the VM, so that seems fine

Can't find anything relating to this and El Capitan - will report back if I do, as I'm sure others will want to know - have no option to use a PC
lasesentaysiete
I feel your pain. I was on Mavericks and it didn't work. Now I'm running El Capitan, and it doesn't work.

FWIW, it works on my girlfriends mac which runs Yosemite.
ZZ Ardoz wrote:


Quote:
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub


ZZ Ardoz
lasesentaysiete wrote:
I feel your pain. I was on Mavericks and it didn't work. Now I'm running El Capitan, and it doesn't work.

FWIW, it works on my girlfriends mac which runs Yosemite.
ZZ Ardoz wrote:


Quote:
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub




Can I borrow your girlfriend for a couple of hours so I can get these flashed? oops
lasesentaysiete
ZZ Ardoz wrote:


Can I borrow your girlfriend for a couple of hours so I can get these flashed? oops


get your own hihi
lasesentaysiete
ZZ Ardoz wrote:


Can I borrow your girlfriend for a couple of hours so I can get these flashed? oops


you know I say girlfriend to look cool on the internet and that I really mean sister, right?
ZZ Ardoz
lasesentaysiete wrote:
ZZ Ardoz wrote:


Can I borrow your girlfriend for a couple of hours so I can get these flashed? oops


get your own hihi


I have one, but she only runs El Capitan

very frustrating
okuhtfesa
Hey, we don't run the same OS version but at least we share the same problem ! MY ASS IS BLEEDING
ZZ Ardoz
So I got my FTDI Friend, and things looked good, and it started writing, but then stopped, not in the same place every time.

Sometimes it got past the WRITE commands and started READ command - but here's a shorter example of what I got

Quote:
python stmlib/programming/serial/stm32loader.py \
-p /dev/ftdi-usbserial \
-b 115200 \
-e -v \
-w build/rings/rings_bootloader_combo.bin
Bootloader version 31
Chip id `['0x4', '0x13']'
Global mass erase; this may take a while
Write 256 bytes at 0x8000000
Write 256 bytes at 0x8000100
Write 256 bytes at 0x8000200
Write 256 bytes at 0x8000300
Write 256 bytes at 0x8000400
Write 256 bytes at 0x8000500
Write 256 bytes at 0x8000600
Write 256 bytes at 0x8000700
Write 256 bytes at 0x8000800
Write 256 bytes at 0x8000900
Write 256 bytes at 0x8000A00
Write 256 bytes at 0x8000B00
Write 256 bytes at 0x8000C00
Write 256 bytes at 0x8000D00
Write 256 bytes at 0x8000E00
Write 256 bytes at 0x8000F00
Write 256 bytes at 0x8001000
Write 256 bytes at 0x8001100
Write 256 bytes at 0x8001200
Write 256 bytes at 0x8001300
Write 256 bytes at 0x8001400
Write 256 bytes at 0x8001500
Write 256 bytes at 0x8001600
Traceback (most recent call last):
File "stmlib/programming/serial/stm32loader.py", line 428, in <module>
cmd.writeMemory(conf['address'], data)
File "stmlib/programming/serial/stm32loader.py", line 307, in writeMemory
self.cmdWriteMemory(addr, data[offs:offs+256])
File "stmlib/programming/serial/stm32loader.py", line 188, in cmdWriteMemory
self._wait_for_ack("0x31 programming failed")
File "stmlib/programming/serial/stm32loader.py", line 69, in _wait_for_ack
raise CmdException("No response to %s" % info)
__main__.CmdException: No response to 0x31 programming failed
make: *** [upload_combo_serial] Error 1


Pulling hair a bit here
ZZ Ardoz
Very, very happy to report that I figured an st-link workflow for anyone who is not having fun with it under el capitan, and now have a working Rings!

What I did was compile as usual with the Vagrant environment, and then flashed it using the st-util back in the mac itself.

Here's some helpful tips for getting that last part set up STM32 Development OSX

Feel free to PM if you have any questions, and thanks those above who provided help!
ZZ Ardoz
In answer to a pm, this is what you do when you have both your st-util and gdp windows open and the communication to the chip established



Quote:
in the window with gdb, type load, and then the path to the bootloader file (you can drag it in), then hit enter - when that's done, do the same for the main file, hit enter

when that's done type run and hit enter - if it asks you if you want to run it from the beginning, type y and enter - ket it run, and then power down the module, and unplug the jtag, when you power the module back up, all should be good


if you get a load failed error, then exit both and start again - which I had to do when flashing streams (2 for 2!) Guinness ftw!
okuhtfesa
Oh yeah you're my man ZZ, my first Elements is crying his first melodies ! Thk you so much we're not worthy
BTW I didn't have to "run" the .elf files, just to "load" them after pushing the Reset and Sysboot buttons on the module.
ZZ Ardoz
okuhtfesa wrote:
Oh yeah you're my man ZZ, my first Elements is crying his first melodies ! Thk you so much we're not worthy
BTW I didn't have to "run" the .elf files, just to "load" them after pushing the Reset and Sysboot buttons on the module.
just happy it works without Microsoft getting a penny from me!
ijed
Can I just get a confirmation that a new STM32 chip can't be programmed with ftdi and needs SWD/JTAG programmer for the bootloader?
ZZ Ardoz
ijed wrote:
Can I just get a confirmation that a new STM32 chip can't be programmed with ftdi and needs SWD/JTAG programmer for the bootloader?


You should be able to flash the bootlader with FTDI. Was it not working for you?
ijed
I was trying to connect to the Braids STM32 I just finished building with the Flash Loader Demonstrator software - using a 3.3v FTDI adapter with TX to RX, RX to TX and Ground to Ground.
Push sysboot, reset then release sysboot. Was just timing out and wouldn't connect. TX flashes but nothing from RX. Checked voltages, TX and RX all ok.

Have ordered a ST-Link/V2 which should arrive tomorrow.

Should also finish my Clouds tonight so I can try with that also
ZZ Ardoz
ijed wrote:
I was trying to connect to the Braids STM32 I just finished building with the Flash Loader Demonstrator software - using a 3.3v FTDI adapter with TX to RX, RX to TX and Ground to Ground.
Push sysboot, reset then release sysboot. Was just timing out and wouldn't connect. TX flashes but nothing from RX. Checked voltages, TX and RX all ok.

Have ordered a ST-Link/V2 which should arrive tomorrow.

Should also finish my Clouds tonight so I can try with that also


First, you have the button procedure backwards - it's hold the RESET switch on the side of the module. Press the SYSBOOT switch next to it, and release RESET.

Second, are you using the Mutable Vagrant environment? If not, try from within that rather than the software you are trying.

Third, have you compiled the bootloader and the main file?
ijed
ZZ Ardoz wrote:


First, you have the button procedure backwards - it's hold the RESET switch on the side of the module. Press the SYSBOOT switch next to it, and release RESET.

Second, are you using the Mutable Vagrant environment? If not, try from within that rather than the software you are trying.

Third, have you compiled the bootloader and the main file?


Oh yeah sorry - just writing this post from memory. Am doing the button presses in the right order.

Have the dev environment setup and can compile main hex file but was getting errors compiling the bootfile.

Was thinking I could just use the Flash Loader Demo tool to verify comms to the chip and upload hex file that way.

Should I get a flash on the RX when I put it into bootloader mode?
ZZ Ardoz
If you are getting errors compiling the bootloader, you need to sort that out first as nothing will work without it getting to the chip.

Post what errors you get when you try and compile, if you could
ijed
ZZ Ardoz wrote:
If you are getting errors compiling the bootloader, you need to sort that out first as nothing will work without it getting to the chip.

Post what errors you get when you try and compile, if you could


Thanks - so I can't use the in-built STM32F bootloader I have to send the MI one?

Will have another look at build errors tonight and post if I get stuck.
ZZ Ardoz
ijed wrote:
ZZ Ardoz wrote:
If you are getting errors compiling the bootloader, you need to sort that out first as nothing will work without it getting to the chip.

Post what errors you get when you try and compile, if you could


Thanks - so I can't use the in-built STM32F bootloader I have to send the MI one?

Will have another look at build errors tonight and post if I get stuck.


Correct
ijed
Ok built bootloader after adding the TOOLCHAIN_PATH command to point to /arm-cs-tools

added ftdi programmer in Virtual Box and shows up on an lsusb
Bus 002 Device 002: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC

device id is same as Vagrant config file:
vb.customize ['usbfilter', 'add', '0', '--target', :id, '--name', 'FTDI serial adapter', '--vendorid', '0x0403', '--productid', '0x6001']


ls -l /dev shows a device called /dev/ttyUSB0
crw-rw---- 1 root dialout 188, 0 Sep 12 08:51 ttyUSB0


but
make -f braids/makefile upload_serial

is looking for /dev/ftdi-usbserial

serial.serialutil.SerialException: [Errno 2] could not open port /dev/ftdi-usbserial: [Errno 2] No such file or directory: '/dev/ftdi-usbserial'




am I getting close?

do I need to set PGM_INTERFACE?

[edit]

this command:
udevadm info -a -p $(udevadm info -q path -n /dev/ttyUSB0)

gives info:

looking at parent device '/devices/pci0000:00/0000:00:06.0/usb1/1-1/1-1:1.0':
KERNELS=="1-1:1.0"
SUBSYSTEMS=="usb"
DRIVERS=="ftdi_sio"
ATTRS{bInterfaceNumber}=="00"
ATTRS{bAlternateSetting}==" 0"
ATTRS{bNumEndpoints}=="02"
ATTRS{bInterfaceClass}=="ff"
ATTRS{bInterfaceSubClass}=="ff"
ATTRS{bInterfaceProtocol}=="ff"
ATTRS{supports_autosuspend}=="1"
ATTRS{interface}=="FT232R USB UART"

[edit#2]
create a link in /dev directory to link ttyUSB0 to ftdi-usbserial

sudo ln -s /dev/ttyUSB0 ftdi-usbserial

then back in the euro_rack folder:

sudo make -f braids/makefile upload_serial

getting TX lights but no RX and no response from STM32:

Can't init. Ensure that BOOT0 is enabled and reset device

so looks like my dev environment is setup but I need to troubleshoot my hardware...
ZZ Ardoz
Try changing ftd-usbserial to ttyUSB0 in PGM_INTERFACE

And try upload_combo_serial as the upload command
ijed
Still no luck - thought I'd try my Clouds I just finished as the LEDs light up when it get's put into bootloader mode.

Trying to build clouds and getting these linker errors:

error: build/clouds/stm32f4xx_spi.o uses VFP register arguments, build/clouds/clouds.elf does not

using 4.8.3

I see -mfloat-abi=hard in the linker command somewhere and my googlefu tells me I need to change this to soft but I don't know where..
ZZ Ardoz
ijed wrote:
Still no luck - thought I'd try my Clouds I just finished as the LEDs light up when it get's put into bootloader mode.

Trying to build clouds and getting these linker errors:

error: build/clouds/stm32f4xx_spi.o uses VFP register arguments, build/clouds/clouds.elf does not

using 4.8.3

I see -mfloat-abi=hard in the linker command somewhere and my googlefu tells me I need to change this to soft but I don't know where..


You shouldn't get compiler errors if you set up everything as specified. I would start again from scratch installing - making sure you have every step covered
ijed
ZZ Ardoz wrote:

You shouldn't get compiler errors if you set up everything as specified. I would start again from scratch installing - making sure you have every step covered


Yeah - I'm just trying this now on a different machine.

Must've missed something....

[EDIT]

Yep - Builds first go.

I think my mistake was not running vagrant up from the mutable-dev-environment directory and the shell scripts didn't run properly.

Woo - now to go home and see if I can upload w00t

[EDIT EDIT]

It's peanut butter jelly time! on the Clouds
Took a couple of tries with the ftdi interface and dodgy stackable header I used - also dropped the speed down to 57600 which I don't know if it helped or not.



Still no love on the Braids though.

I had 3.3v and ground on all the correct pins but not sure where else to start poking around for voltages. Should I be getting any response when I put it into bootloader mode? Maybe it's the buttons.... Will keep investigating
ZZ Ardoz
how did you get the bootloader on braids if you didn't have success flashing the MCU?
ijed
ZZ Ardoz wrote:
how did you get the bootloader on braids if you didn't have success flashing the MCU?


Oh I meant the button presses to put it into the mode for uploading the bootloader.
I press the buttons but don't know if it's going into this mode.
I do the make -f braids/makefile upload_combo_serial and it tries to connect but times out with a cannot init BOOT0

Is it possible I'll have better luck with a JTAG programmer? I'm just waiting for some 1.27mm headers which should be here by the end of the week
ijed
It's alive!



Went over the stm32 again and serial started responding and managed to get the firmware uploaded.

Calibrated but coarse doesn't seem to change the pitch so I think there's something up with the input. Voltages from the pot look good and rest of the inputs into the mcp3204 seem ok.

Will continue to investigate
nosamiam
Absolute newbie here. I have a Yarns module built and I'm having some trouble uploading the firmware to it. I've struggled for several days with ST-Link and sort of hit a wall with it.

So I decided to try MIDI. I have the 'snake' first digit on the LED display. Apparently this indicates that it's ready to receive firmware. I have yarns.syx that I'm trying to send via sysex using Elektron C6.

In C6, everything looks fine. The progress bar shows that it is sending. But on the Yarns end, there's no evidence that it's receiving anything. The snake just keeps chasing its tail.

Any ideas?
Southfork
ijed wrote:
ZZ Ardoz wrote:
how did you get the bootloader on braids if you didn't have success flashing the MCU?


Oh I meant the button presses to put it into the mode for uploading the bootloader.
I press the buttons but don't know if it's going into this mode.
I do the make -f braids/makefile upload_combo_serial and it tries to connect but times out with a cannot init BOOT0

Is it possible I'll have better luck with a JTAG programmer? I'm just waiting for some 1.27mm headers which should be here by the end of the week


Usually means your mcu isn't correctly soldered. Reflow it and try again thumbs up
mush
Use:
make -f braids/makefile upload_combo_jtag

if you use stlink.
ZZ Ardoz
Southfork wrote:
ijed wrote:
ZZ Ardoz wrote:
how did you get the bootloader on braids if you didn't have success flashing the MCU?


Oh I meant the button presses to put it into the mode for uploading the bootloader.
I press the buttons but don't know if it's going into this mode.
I do the make -f braids/makefile upload_combo_serial and it tries to connect but times out with a cannot init BOOT0

Is it possible I'll have better luck with a JTAG programmer? I'm just waiting for some 1.27mm headers which should be here by the end of the week


Usually means your mcu isn't correctly soldered. Reflow it and try again thumbs up


You can also get that when the programmer isn't recognized. Try unplugging the cable from the target, so it's just the programmer attached to the usb, and see if the same message comes up
nosamiam
nosamiam wrote:
Absolute newbie here. I have a Yarns module built and I'm having some trouble uploading the firmware to it. I've struggled for several days with ST-Link and sort of hit a wall with it.

So I decided to try MIDI. I have the 'snake' first digit on the LED display. Apparently this indicates that it's ready to receive firmware. I have yarns.syx that I'm trying to send via sysex using Elektron C6.

In C6, everything looks fine. The progress bar shows that it is sending. But on the Yarns end, there's no evidence that it's receiving anything. The snake just keeps chasing its tail.

Any ideas?


Duh. MIDI cable wasn't pushed in far enough. It's often the simplest solution that is the correct one. I guess I was so used to losing on this build that I was ready to throw in the towel.

But now I can call this a SUCCESSFUL BUILD! First module ever is up and running!!
ijed
ZZ Ardoz wrote:

You can also get that when the programmer isn't recognized. Try unplugging the cable from the target, so it's just the programmer attached to the usb, and see if the same message comes up


Yeah Braids is up and running now but having problems with pitch.

It's v0.3 and I can see voltages from Coarse pot and Jack in on the TL074 but only ever appears to output 11v. FM Param1 and Param2 are all working fine.

Looked at everything upstream but maybe I should check the gain resistor?

[EDIT]

Removed and checked R48 which was giving a reading of 120k. Swapped it for another one that was 100k - no difference.
Swapped the 1n Cap - no difference
Removed Coarse pot - no difference
Removed Bridging resistor R34 - no difference

I think the only thing left is to swap the TL074 - seems weird that only one output would be bad and the rest ok though....
tenshun
hello i just finished building up a diy clouds.

I am having a bit of trouble flashing the clouds in Windows 10.
I am using Git Bash and First of all the when i type in lsusb i do not see it in command.

I am using the Olimex Jtag and i am getting this message:

vagrant@vagrant-ubuntu-trusty-64:/vagrant/eurorack-modules$ make -f clouds/makefile upload_combo_jtag
cat build/clouds/clouds.d build/clouds/cv_scaler.d build/clouds/resources.d build/clouds/settings.d bui ld/clouds/ui.d build/clouds/adc.d build/clouds/codec.d build/clouds/debug_port.d build/clouds/gate_inpu t.d build/clouds/leds.d build/clouds/switches.d build/clouds/system.d build/clouds/correlator.d build/c louds/granular_processor.d build/clouds/mu_law.d build/clouds/frame_transformation.d build/clouds/phase _vocoder.d build/clouds/stft.d build/clouds/atan.d build/clouds/units.d build/clouds/random.d build/clo uds/bootloader_utils.d build/clouds/system_clock.d build/clouds/arm_common_tables.d build/clouds/arm_co nst_structs.d build/clouds/arm_bitreversal.d build/clouds/arm_cfft_f32.d build/clouds/arm_cfft_q15.d bu ild/clouds/arm_cfft_q31.d build/clouds/arm_cfft_radix2_f32.d build/clouds/arm_cfft_radix2_init_f32.d bu ild/clouds/arm_cfft_radix2_init_q15.d build/clouds/arm_cfft_radix2_init_q31.d build/clouds/arm_cfft_rad ix2_q15.d build/clouds/arm_cfft_radix2_q31.d build/clouds/arm_cfft_radix4_f32.d build/clouds/arm_cfft_r adix4_init_f32.d build/clouds/arm_cfft_radix4_init_q15.d build/clouds/arm_cfft_radix4_init_q31.d build/ clouds/arm_cfft_radix4_q15.d build/clouds/arm_cfft_radix4_q31.d build/clouds/arm_cfft_radix8_f32.d buil d/clouds/arm_dct4_f32.d build/clouds/arm_dct4_init_f32.d build/clouds/arm_dct4_init_q15.d build/clouds/ arm_dct4_init_q31.d build/clouds/arm_dct4_q15.d build/clouds/arm_dct4_q31.d build/clouds/arm_rfft_f32.d build/clouds/arm_rfft_fast_f32.d build/clouds/arm_rfft_fast_init_f32.d build/clouds/arm_rfft_init_f32. d build/clouds/arm_rfft_init_q15.d build/clouds/arm_rfft_init_q31.d build/clouds/arm_rfft_q15.d build/c louds/arm_rfft_q31.d build/clouds/core_cm3.d build/clouds/system_stm32f4xx.d build/clouds/misc.d build/ clouds/stm32f4xx_adc.d build/clouds/stm32f4xx_can.d build/clouds/stm32f4xx_cec.d build/clouds/stm32f4xx _crc.d build/clouds/stm32f4xx_cryp_aes.d build/clouds/stm32f4xx_cryp.d build/clouds/stm32f4xx_cryp_des. d build/clouds/stm32f4xx_cryp_tdes.d build/clouds/stm32f4xx_dac.d build/clouds/stm32f4xx_dbgmcu.d build /clouds/stm32f4xx_dcmi.d build/clouds/stm32f4xx_dma2d.d build/clouds/stm32f4xx_dma.d build/clouds/stm32 f4xx_dsi.d build/clouds/stm32f4xx_exti.d build/clouds/stm32f4xx_flash.d build/clouds/stm32f4xx_flash_ra mfunc.d build/clouds/stm32f4xx_fmc.d build/clouds/stm32f4xx_fmpi2c.d build/clouds/stm32f4xx_fsmc.d buil d/clouds/stm32f4xx_gpio.d build/clouds/stm32f4xx_hash.d build/clouds/stm32f4xx_hash_md5.d build/clouds/ stm32f4xx_hash_sha1.d build/clouds/stm32f4xx_i2c.d build/clouds/stm32f4xx_iwdg.d build/clouds/stm32f4xx _lptim.d build/clouds/stm32f4xx_ltdc.d build/clouds/stm32f4xx_pwr.d build/clouds/stm32f4xx_qspi.d build /clouds/stm32f4xx_rcc.d build/clouds/stm32f4xx_rng.d build/clouds/stm32f4xx_rtc.d build/clouds/stm32f4x x_sai.d build/clouds/stm32f4xx_sdio.d build/clouds/stm32f4xx_spdifrx.d build/clouds/stm32f4xx_spi.d bui ld/clouds/stm32f4xx_syscfg.d build/clouds/stm32f4xx_tim.d build/clouds/stm32f4xx_usart.d build/clouds/s tm32f4xx_wwdg.d build/clouds/arm_bitreversal2.d build/clouds/startup_stm32f4xx.d > build/clouds/depends .mk
cat build/clouds/clouds.hex build/clouds_bootloader/clouds_bootloader.hex | \
awk -f stmlib/programming/merge_hex.awk > build/clouds/clouds_bootloader_combo. hex
/usr/local/arm-4.8.3/bin/arm-none-eabi-objcopy -I ihex -O binary build/clouds/clouds_bootloader_combo.h ex build/clouds/clouds_bootloader_combo.bin
openocd -f stmlib/programming/jtag/interface_TYPE=hla.cfg -f stmlib/programming/jtag/stm32f4xx_jtag.cfg -f stmlib/programming/jtag/prelude_f4xx.cfg -f stmlib/programming/jtag/erase_f4xx.cfg -c "flash write _bank 0 build/clouds/clouds_bootloader_combo.bin 0x0" -c "verify_image build/clouds/clouds_bootloader_c ombo.bin" -f stmlib/programming/jtag/postlude.cfg || openocd -f stmlib/programming/jtag/interface_TYPE= hla.cfg -f stmlib/programming/jtag/stm32f4xx_jtag.cfg -f stmlib/programming/jtag/prelude_f4xx.cfg -f s tmlib/programming/jtag/erase_f4xx.cfg -c "flash write_bank 0 build/clouds/clouds_bootloader_combo.bin 0 x0" -c "verify_image build/clouds/clouds_bootloader_combo.bin" -f stmlib/programming/jtag/postlude.cfg
Open On-Chip Debugger 0.9.0 (2016-09-24-02:32)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
embedded:startup.tcl:60: Error: Can't find stmlib/programming/jtag/interface_TYPE=hla.cfg
in procedure 'script'
at file "embedded:startup.tcl", line 60
Open On-Chip Debugger 0.9.0 (2016-09-24-02:32)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
embedded:startup.tcl:60: Error: Can't find stmlib/programming/jtag/interface_TYPE=hla.cfg
in procedure 'script'
at file "embedded:startup.tcl", line 60
make: *** [upload_combo_jtag] Error 1
vagrant@vagrant-ubuntu-trusty-64:/vagrant/eurorack-modules$
nevetsokyeron
I've got some curious output from a Braids build...

Quote:
stm32x mass erase complete
target state: halted
target halted due to debug-request, current mode: Handler HardFault
xPSR: 0x01000003 pc: 0xfffffffe msp: 0xffffffdc
target state: halted
target halted due to breakpoint, current mode: Handler HardFault
xPSR: 0x61000003 pc: 0x2000003a msp: 0xffffffdc
wrote 116228 bytes from file build/braids/braids_bootloader_combo.bin to flash bank 0 at offset 0x00000000 in 4.836217s (23.470 KiB/s)
target state: halted
target halted due to breakpoint, current mode: Handler HardFault
xPSR: 0x61000003 pc: 0x2000002e msp: 0xffffffdc
verified 116228 bytes in 1.998709s (56.789 KiB/s)
in procedure 'reset' called at file "stmlib/programming/jtag/postlude.cfg", line 24
in procedure 'ocd_bouncer'


The Braids appears to have taken the firmware OK - I get CSAW on the display.

But... should I be concerned about this "reset" failing at the end of the programming cycle?
lasesentaysiete
does it work ok?
have you tried reflashing?
nevetsokyeron wrote:
I've got some curious output from a Braids build...

Quote:
stm32x mass erase complete
target state: halted
target halted due to debug-request, current mode: Handler HardFault
xPSR: 0x01000003 pc: 0xfffffffe msp: 0xffffffdc
target state: halted
target halted due to breakpoint, current mode: Handler HardFault
xPSR: 0x61000003 pc: 0x2000003a msp: 0xffffffdc
wrote 116228 bytes from file build/braids/braids_bootloader_combo.bin to flash bank 0 at offset 0x00000000 in 4.836217s (23.470 KiB/s)
target state: halted
target halted due to breakpoint, current mode: Handler HardFault
xPSR: 0x61000003 pc: 0x2000002e msp: 0xffffffdc
verified 116228 bytes in 1.998709s (56.789 KiB/s)
in procedure 'reset' called at file "stmlib/programming/jtag/postlude.cfg", line 24
in procedure 'ocd_bouncer'


The Braids appears to have taken the firmware OK - I get CSAW on the display.

But... should I be concerned about this "reset" failing at the end of the programming cycle?
nevetsokyeron
lasesentaysiete wrote:
does it work ok?
have you tried reflashing?


Reflashing gives the same result. Seems to be working OK though. thumbs up
Puzzler
Where does it say that the "reset" command did not work?
Puzzler
tenshun wrote:
.
.
.

embedded:startup.tcl:60: Error: Can't find stmlib/programming/jtag/interface_TYPE=hla.cfg
in procedure 'script'
at file "embedded:startup.tcl", line 60
.
.
.

embedded:startup.tcl:60: Error: Can't find stmlib/programming/jtag/interface_TYPE=hla.cfg
in procedure 'script'
at file "embedded:startup.tcl", line 60
make: *** [upload_combo_jtag] Error 1
vagrant@vagrant-ubuntu-trusty-64:/vagrant/eurorack-modules$


Make sure that this file(s) exist.
pld
tenshun wrote:
embedded:startup.tcl:60: Error: Can't find stmlib/programming/jtag/interface_TYPE=hla.cfg

That's wrong, it should be somthing like stmlib/programming/jtag/interface_arm-usb-ocd.cfg. So like either the PGM_INTERFACE variable was incorrectly modified in the makefile (and which shouldn't be necessary), or it was set in the shell to something invalid.
hautlle
I'm having a bit of trouble flashing Clouds but think I need to check over my MCU joints.

Using Mutable Vagrant environment w/ an STLink-V2 and the ADAFruit Cortex SWD adapter. I've set PGM_INTERFACE=stlink-v2 and PGM_INTERFACE_TYPE=hla. When I run "make -f clouds/makefile upload" or "make -f clouds/makefile upload_combo_jtag" I get the following error --

Quote:
vagrant@vagrant-ubuntu-trusty-64:/vagrant/eurorack-modules$ make -f clouds/makefile upload_combo_jtag
openocd -f stmlib/programming/jtag/interface_stlink-v2.cfg -f stmlib/programming/jtag/stm32f4xx_jtag.cfg -f stmlib/programming/jtag/prelude_f4xx.cfg -f stmlib/programming/jtag/erase_f4xx.cfg -c "flash write_bank 0 build/clouds/clouds_bootloader_combo.bin 0x0" -c "verify_image build/clouds/clouds_bootloader_combo.bin" -f stmlib/programming/jtag/postlude.cfg || openocd -f stmlib/programming/jtag/interface_stlink-v2.cfg -f stmlib/programming/jtag/stm32f4xx_jtag.cfg -f stmlib/programming/jtag/prelude_f4xx.cfg -f stmlib/programming/jtag/erase_f4xx.cfg -c "flash write_bank 0 build/clouds/clouds_bootloader_combo.bin 0x0" -c "verify_image build/clouds/clouds_bootloader_combo.bin" -f stmlib/programming/jtag/postlude.cfg
Open On-Chip Debugger 0.9.0 (2016-09-24-04:02)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
hla_jtag
adapter speed: 2000 kHz
adapter_nsrst_delay: 100
trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain connect_deassert_srst
stmlib/programming/jtag/stm32f4xx_jtag.cfg:31: Error: invalid subcommand "newtap stm32f4xxx cpu -irlen 4 -ircapture 0x1 -irmask 0xf -expected-id 0x4ba00477"
in procedure 'script'
at file "embedded:startup.tcl", line 60
in procedure 'jtag' called at file "stmlib/programming/jtag/stm32f4xx_jtag.cfg", line 31
Open On-Chip Debugger 0.9.0 (2016-09-24-04:02)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
hla_jtag
adapter speed: 2000 kHz
adapter_nsrst_delay: 100
trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain connect_deassert_srst
stmlib/programming/jtag/stm32f4xx_jtag.cfg:31: Error: invalid subcommand "newtap stm32f4xxx cpu -irlen 4 -ircapture 0x1 -irmask 0xf -expected-id 0x4ba00477"
in procedure 'script'
at file "embedded:startup.tcl", line 60
in procedure 'jtag' called at file "stmlib/programming/jtag/stm32f4xx_jtag.cfg", line 31
make: *** [upload_combo_jtag] Error 1


I think it's failing because of that unexpected address which leads me to think it might be a bridged MCU, but I really have no idea. Any help would be greatly appreciated.

edit: pic of MCU
tenshun
pld wrote:
tenshun wrote:
embedded:startup.tcl:60: Error: Can't find stmlib/programming/jtag/interface_TYPE=hla.cfg

That's wrong, it should be somthing like stmlib/programming/jtag/interface_arm-usb-ocd.cfg. So like either the PGM_INTERFACE variable was incorrectly modified in the makefile (and which shouldn't be necessary), or it was set in the shell to something invalid.


Thank you for the reply and help.

I noticed that my olinex ARM-USB-OCD-H is not being recognized when i type
lsusb in gitbash.

Do i have to alter anything to make it show up in virtual box or in vagrant?

Everything up to this point seems to be good (creating bootloader and makefile)

But i dont know what to export it as?

This :

export PGM_INTERFACE=stlink-v2
export PGM_INTERFACE_TYPE=hla

Or this:

export PROGRAMMER=stk500
export PROGRAMMER_PORT=/dev/tty.usb
nevetsokyeron
Puzzler wrote:
Where does it say that the "reset" command did not work?


I think you're responding to my question about the "reset" (yes/no?)

I get the text I quoted above and then the process stops with "Error 1" - i just forgot to include that next line with the quoted text.

I assumed the reset was failing because it's the last thing mentioned (and ocd_bouncer)
ZZ Ardoz
tenshun wrote:
pld wrote:
tenshun wrote:
embedded:startup.tcl:60: Error: Can't find stmlib/programming/jtag/interface_TYPE=hla.cfg

That's wrong, it should be somthing like stmlib/programming/jtag/interface_arm-usb-ocd.cfg. So like either the PGM_INTERFACE variable was incorrectly modified in the makefile (and which shouldn't be necessary), or it was set in the shell to something invalid.


Thank you for the reply and help.

I noticed that my olinex ARM-USB-OCD-H is not being recognized when i type
lsusb in gitbash.

Do i have to alter anything to make it show up in virtual box or in vagrant?

Everything up to this point seems to be good (creating bootloader and makefile)

But i dont know what to export it as?

This :

export PGM_INTERFACE=stlink-v2
export PGM_INTERFACE_TYPE=hla

Or this:

export PROGRAMMER=stk500
export PROGRAMMER_PORT=/dev/tty.usb


I never had luck using vagrant to flash - just compiling - ended up using st-util and gdb and had no problems - have you tried that? There's a link a few posts back of mine
hautlle
I've made a bit of progress after retouching the MCU. It at least gets to "unable to connect to target" now.

Quote:
Open On-Chip Debugger 0.9.0 (2016-09-24-04:02)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
hla_jtag
adapter speed: 2000 kHz
adapter_nsrst_delay: 100
trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain connect_deassert_srst
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
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 v25 API v2 SWIM v4 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 3.225246
Error: init mode failed (unable to connect to the target)
in procedure 'init' called at file "stmlib/programming/jtag/prelude_f4xx.cfg", line 23
in procedure 'ocd_bouncer'


I guess I'll have to poke around a bit more and inspect everything. This is my first SMD project. Should that reported target voltage concern me at all? Should it be closer to 3.3?
lasesentaysiete
looks like some of those joints need more solder.

hautlle wrote:
I've made a bit of progress after retouching the MCU. It at least gets to "unable to connect to target" now.

I guess I'll have to poke around a bit more and inspect everything. This is my first SMD project. Should that reported target voltage concern me at all? Should it be closer to 3.3?
tenshun
ZZ Ardoz wrote:
tenshun wrote:
pld wrote:
tenshun wrote:
embedded:startup.tcl:60: Error: Can't find stmlib/programming/jtag/interface_TYPE=hla.cfg

That's wrong, it should be somthing like stmlib/programming/jtag/interface_arm-usb-ocd.cfg. So like either the PGM_INTERFACE variable was incorrectly modified in the makefile (and which shouldn't be necessary), or it was set in the shell to something invalid.


Thank you for the reply and help.

I noticed that my olinex ARM-USB-OCD-H is not being recognized when i type
lsusb in gitbash.

Do i have to alter anything to make it show up in virtual box or in vagrant?

Everything up to this point seems to be good (creating bootloader and makefile)

But i dont know what to export it as?

This :

export PGM_INTERFACE=stlink-v2
export PGM_INTERFACE_TYPE=hla

Or this:

export PROGRAMMER=stk500
export PROGRAMMER_PORT=/dev/tty.usb


I never had luck using vagrant to flash - just compiling - ended up using st-util and gdb and had no problems - have you tried that? There's a link a few posts back of mine


I have not tried that as i am using windows 10.

So i tried this method using the adafruit ftdi friend and this software here:

http://www.st.com/content/st_com/en/products/development-tools/softwar e-development-tools/stm32-software-development-tools/stm32-programmers  /flasher-stm32.html

And i was able to load :

make -f clouds/bootloader/makefile hex
make -f clouds/makefile

Now when i turn it on i see the leds move around and then they turn off.
I however cannot get any sound out of the clouds. I dont even see the leds reacting to whatever signal i inject into the input.

I tried to install the firmware as well through the left input and i do not see the leds move.
The flash button turns on when i press it. The 2 small buttons seem to cycle through stuff but thats about it.

Am i supposed to load anything else?
lasesentaysiete
leds cycling then turning off is normal behaviour. You should see some metering action when you adjust the gain knob or input volume. Also, adjusting the blend knob changes some led colours.

Check your soldering. How's the codec?
tenshun wrote:


Now when i turn it on i see the leds move around and then they turn off.
I however cannot get any sound out of the clouds. I dont even see the leds reacting to whatever signal i inject into the input.

I tried to install the firmware as well through the left input and i do not see the leds move.
The flash button turns in when i press it. The 2 small buttons seem to cycle through stuff but thats about it.

Am i supposed to load anything else?
ZZ Ardoz
tenshun wrote:


Am i supposed to load anything else?


Sounds like the firmware loaded, but you might have a hardware issue

Have you metered around the board and found all your voltages to be correct?
tenshun
lasesentaysiete wrote:
leds cycling then turning off is normal behaviour. You should see some metering action when you adjust the gain knob or input volume. Also, adjusting the blend knob changes some led colours.

Check your soldering. How's the codec?
tenshun wrote:


Now when i turn it on i see the leds move around and then they turn off.
I however cannot get any sound out of the clouds. I dont even see the leds reacting to whatever signal i inject into the input.

I tried to install the firmware as well through the left input and i do not see the leds move.
The flash button turns in when i press it. The 2 small buttons seem to cycle through stuff but thats about it.

Am i supposed to load anything else?



as far as soldering, i examined the hell out of the board with a really strong magnifying glass and everything looked to be well.
I made sure everything was in the correct location and nothing was bridged before i even tried turning it on.

I will check the codec when i get home from work.
lasesentaysiete
post pics as well eyes...
tenshun wrote:

I will check the codec when i get home from work.
ZZ Ardoz
lasesentaysiete wrote:
post pics as well eyes...
tenshun wrote:

I will check the codec when i get home from work.
video (even crappy) of what happens when you turn it on as well
hautlle
And now the LEDs no longer come on w/ power.... lol, time for a break Dead Banana
ZZ Ardoz
hautlle wrote:
And now the LEDs no longer come on w/ power.... lol, time for a break Dead Banana


Check your 4.7 resistor to see if if fried
hautlle
ZZ Ardoz wrote:
hautlle wrote:
And now the LEDs no longer come on w/ power.... lol, time for a break Dead Banana


Check your 4.7 resistor to see if if fried


got a reading of 5.6 on the multimeter
tenshun
ZZ Ardoz wrote:
lasesentaysiete wrote:
post pics as well eyes...
tenshun wrote:

I will check the codec when i get home from work.
video (even crappy) of what happens when you turn it on as well


Here is a video of me turning on clouds.
I put a ramp signal from the Dixie into the clouds and nothing comes out. It does not even read the signal on the leds.

https://m.youtube.com/watch?v=cFwte6EG7XM

Any help or input would be awesome!
ZZ Ardoz
tenshun wrote:
ZZ Ardoz wrote:
lasesentaysiete wrote:
post pics as well eyes...
tenshun wrote:

I will check the codec when i get home from work.
video (even crappy) of what happens when you turn it on as well


Here is a video of me turning on clouds.
I put a ramp signal from the Dixie into the clouds and nothing comes out. It does not even read the signal on the leds.

https://m.youtube.com/watch?v=cFwte6EG7XM

Any help or input would be awesome!


That's definitely the right startup for the leds, so you almost certainly have the firmware in there

What are you using as an input pot?
tenshun
ZZ Ardoz wrote:
tenshun wrote:
ZZ Ardoz wrote:
lasesentaysiete wrote:
post pics as well eyes...
tenshun wrote:

I will check the codec when i get home from work.
video (even crappy) of what happens when you turn it on as well


Here is a video of me turning on clouds.
I put a ramp signal from the Dixie into the clouds and nothing comes out. It does not even read the signal on the leds.

https://m.youtube.com/watch?v=cFwte6EG7XM

Any help or input would be awesome!


That's definitely the right startup for the leds, so you almost certainly have the firmware in there

What are you using as an input pot?


The input pot i am using is the one thats in the mouser clouds bom;

https://www.mouser.com/ProjectManager/ProjectDetail.aspx?AccessID=cc8b 77c20c

I believe its a 50k pot.

What voltage should be coming out of ic9 and ic10? I am thinking maybe those could be bad tl072s?
ZZ Ardoz
Can you post a good quality image of your board?
tenshun
ZZ Ardoz wrote:
Can you post a good quality image of your board?


Here are some pictures i tried taking with my iphone.

I used some 0805 resistors for the 10k and 100k which i had from previous builds.
lasesentaysiete
c25 and r51 don't look so good. Hard to tell from the photos, though.

did you end up checking the voltage on the tl072s?
tenshun wrote:

Here are some pictures i tried taking with my iphone.
ZZ Ardoz
tenshun wrote:
ZZ Ardoz wrote:
Can you post a good quality image of your board?


Here are some pictures i tried taking with my iphone.

I used some 0805 resistors for the 10k and 100k which i had from previous builds.


It's a little hard to see , but is C19 bridging pins 46 and 47 in your ARM?
lasesentaysiete
also, on the same side as c19, there may be a leg of the uc that has a cold joint, closer to the c25 end. Looks dull.


tenshun wrote:
ZZ Ardoz wrote:
Can you post a good quality image of your board?


Here are some pictures i tried taking with my iphone.

I used some 0805 resistors for the 10k and 100k which i had from previous builds.
ZZ Ardoz
lasesentaysiete wrote:


did you end up checking the voltage on the tl072s?


Indeed - first thing to check
tenshun
ZZ Ardoz wrote:
lasesentaysiete wrote:


did you end up checking the voltage on the tl072s?


Indeed - first thing to check


So i checked the voltages coming out of pin 8 on ic 9 & 10 and im getting 11.73
Also checked pin 4 of both ics and getting -11.75

I will comb the board and reflow some of the caps and resistors you guys mentioned.

Thanks for all the help!
tenshun
I Got it working!!!! It's peanut butter jelly time!

I reflowed the areas c25 and r51 and then drag soldered the ARM ic. turned it on and i got a signal!
Everything seems to run good! SlayerBadger!

Thank you guys for the help and extra set of eyes!
ZZ Ardoz
tenshun wrote:
I Got it working!!!! It's peanut butter jelly time!

I reflowed the areas c25 and r51 and then drag soldered the ARM ic. turned it on and i got a signal!
Everything seems to run good! SlayerBadger!

Thank you guys for the help and extra set of eyes!


Hoorah! Guinness ftw! Guinness ftw! Guinness ftw!
ijed
tenshun wrote:

Here are some pictures i tried taking with my iphone.


Maybe check the caps around the WM8731 - C30 and C34 looks half soldered

[EDIT] Sorry late reply - Glad it's up and running!
lasesentaysiete
tenshun wrote:
I Got it working!!!! It's peanut butter jelly time!

I reflowed the areas c25 and r51 and then drag soldered the ARM ic.

thumbs up I've found that when its half working, its usually just a cold joint on the uC or codec that has gone unnoticed.
Southfork
Finished my clouds build, flashed and everything seems working (getting sound, responds to cv) only problem is mode button is unresponsive.

I've reflowed the mcu many times and the board generally, has anyone else experienced this? Is there any part of the board I should be concentrating on?
lasesentaysiete
Southfork wrote:
mode button is unresponsive.

it has no effects on the leds or on the sound? Do the leds do anything otherwise?
You could check along that switch's signal path to the uC for any cold joints.
Southfork
lasesentaysiete wrote:
Southfork wrote:
mode button is unresponsive.

it has no effects on the leds or on the sound? Do the leds do anything otherwise?
You could check along that switch's signal path to the uC for any cold joints.


All leds functioning correctly and other button is working. The button has a direct line to the mcu so tried reflowing it several times to no avail. Checked the 2 resistors in its path and they check out hmmm.....
av500
Southfork wrote:
lasesentaysiete wrote:
Southfork wrote:
mode button is unresponsive.

it has no effects on the leds or on the sound? Do the leds do anything otherwise?
You could check along that switch's signal path to the uC for any cold joints.


All leds functioning correctly and other button is working. The button has a direct line to the mcu so tried reflowing it several times to no avail. Checked the 2 resistors in its path and they check out hmmm.....


and the button itself makes contact when you press it?
lasesentaysiete
Southfork wrote:
The button has a direct line to the mcu so tried reflowing it several times to no avail. Checked the 2 resistors in its path and they check out hmmm.....


which 2 resistors? Are you talking about SW2? If so, check that the via isn't damaged. FWIW you usually don't need to solder those switches in tho check functionality. They maintain contact well enough dry fit.
Southfork
lasesentaysiete wrote:
Southfork wrote:
The button has a direct line to the mcu so tried reflowing it several times to no avail. Checked the 2 resistors in its path and they check out hmmm.....


which 2 resistors? Are you talking about SW2? If so, check that the via isn't damaged. FWIW you usually don't need to solder those switches in tho check functionality. They maintain contact well enough dry fit.


Sorry my bad read the eagle wrong, there are no resistors in its path. Ok just ran the meter over sw2 (non functioning) and sw3. Sw3 has a change in voltage when button is pressed and sw2 is showing nothing. Not sure what that means.

I've switched the buttons just to test and they are both working fine with good contact.
lasesentaysiete
check the via going to SW2 to see if voltage makes it that far.

It happened to me once that an led wasn't changing colours and it turned out to be a damaged via.

Southfork wrote:
I've switched the buttons just to test and they are both working fine with good contact.
Southfork
lasesentaysiete wrote:
check the via going to SW2 to see if voltage makes it that far.

It happened to me once that an led wasn't changing colours and it turned out to be a damaged via.

Southfork wrote:
I've switched the buttons just to test and they are both working fine with good contact.


Ah ok, no voltage going from mcu to switch. Hmm is it worth checking other components? Re-sit mcu?
lasesentaysiete
post some pics. AND CHECK THE VIA!!!
Southfork wrote:

Ah ok, no voltage going from mcu to switch. Hmm is it worth checking other components? Re-sit mcu?
ijed
ooh I finally got the pitch working on my braids.
After reflowing everything, removing pots and changing resistors it was the input to the TL074 that wasn't making good connection.
Then replaced the 1n cap and it's all happy
nosamiam
Ok, going kinda crazy here. I have a Braids that I'm trying to upload the bootloader on. I've done all the trial and error and educated guessing I can do and now I'm stuck. I don't really know how to do this stuff but I'm trying to learn.

Some details:
older Mac running OSX 10.7.5
Using ST-Link v2 with Olimex ARM JTAG 20-10 adapter.

I've checked all of my joints with a loupe and can't find any bridges, colds, or dry joints.

I think I've gotten through all the software downloads and compiling and am trying to upload the bootloader and when I run this:

make -f braids/makefile upload_combo_jtag


I get this:

stmlib/makefile.inc:322: build/braids/depends.mk: No such file or directory
mkdir -p build/braids/
/Users/Corinne/arm-cs-tools/bin/arm-none-eabi-g++ -MM -g -O2 -Wall -Werror -Wno-unused-local-typedefs -fasm -finline -finline-functions-called-once -fdata-sections -ffunction-sections -fshort-enums -fno-move-loop-invariants -I. -DGCC_ARMCM3 -DSTM32F10X_MD -DAPPLICATION -DF_CPU=72000000L -DF_CRYSTAL=8000000L -DUSE_STDPERIPH_DRIVER -DSYSCLK_FREQ_72MHz=72000000L -Istmlib/third_party/STM -Istmlib/third_party/STM/CMSIS/CM3_f10x -Istmlib/third_party/STM/CMSIS/CM3_f10x/startup/gcc -Istmlib/third_party/STM/STM32F10x_StdPeriph_Driver/inc -mcpu=cortex-m3 -mthumb -fno-unroll-loops -fno-exceptions -fno-rtti braids/analog_oscillator.cc -MF build/braids/analog_oscillator.d -MT build/braids/analog_oscillator.o
/Users/Corinne/arm-cs-tools/bin/arm-none-eabi-g++ -MM -g -O2 -Wall -Werror -Wno-unused-local-typedefs -fasm -finline -finline-functions-called-once -fdata-sections -ffunction-sections -fshort-enums -fno-move-loop-invariants -I. -DGCC_ARMCM3 -DSTM32F10X_MD -DAPPLICATION -DF_CPU=72000000L -DF_CRYSTAL=8000000L -DUSE_STDPERIPH_DRIVER -DSYSCLK_FREQ_72MHz=72000000L -Istmlib/third_party/STM -Istmlib/third_party/STM/CMSIS/CM3_f10x -Istmlib/third_party/STM/CMSIS/CM3_f10x/startup/gcc -Istmlib/third_party/STM/STM32F10x_StdPeriph_Driver/inc -mcpu=cortex-m3 -mthumb -fno-unroll-loops -fno-exceptions -fno-rtti braids/braids.cc -MF build/braids/braids.d -MT build/braids/braids.o
/Users/Corinne/arm-cs-tools/bin/arm-none-eabi-g++ -MM -g -O2 -Wall -Werror -Wno-unused-local-typedefs -fasm -finline -finline-functions-called-once -fdata-sections -ffunction-sections -fshort-enums -fno-move-loop-invariants -I. -DGCC_ARMCM3 -DSTM32F10X_MD -DAPPLICATION -DF_CPU=72000000L -DF_CRYSTAL=8000000L -DUSE_STDPERIPH_DRIVER -DSYSCLK_FREQ_72MHz=72000000L -Istmlib/third_party/STM -

.....buncha stuff that looks ok....

Ibuild/braids/analog_oscillator.o build/braids/braids.o build/braids/digital_oscillator.o build/braids/macro_oscillator.o build/braids/quantizer.o build/braids/resources.o build/braids/settings.o build/braids/ui.o build/braids/adc.o build/braids/dac.o build/braids/debug_pin.o build/braids/display.o build/braids/encoder.o build/braids/gate_input.o build/braids/internal_adc.o build/braids/system.o build/braids/uart_logger.o build/braids/random.o build/braids/bootloader_utils.o build/braids/system_clock.o build/braids/core_cm3.o build/braids/system_stm32f10x.o build/braids/misc.o build/braids/stm32f10x_adc.o build/braids/stm32f10x_bkp.o build/braids/stm32f10x_can.o build/braids/stm32f10x_crc.o build/braids/stm32f10x_dac.o build/braids/stm32f10x_dbgmcu.o build/braids/stm32f10x_dma.o build/braids/stm32f10x_exti.o build/braids/stm32f10x_flash.o build/braids/stm32f10x_fsmc.o build/braids/stm32f10x_gpio.o build/braids/stm32f10x_i2c.o build/braids/stm32f10x_iwdg.o build/braids/stm32f10x_pwr.o build/braids/stm32f10x_rcc.o build/braids/stm32f10x_rtc.o build/braids/stm32f10x_sdio.o build/braids/stm32f10x_spi.o build/braids/stm32f10x_tim.o build/braids/stm32f10x_usart.o build/braids/stm32f10x_wwdg.o build/braids/startup_stm32f10x_md.o
/Users/Corinne/arm-cs-tools/bin/arm-none-eabi-objcopy -O ihex build/braids/braids.elf build/braids/braids.hex
cat build/braids/braids.hex build/braids_bootloader/braids_bootloader.hex | \
awk -f stmlib/programming/merge_hex.awk > build/braids/braids_bootloader_combo.hex
/Users/Corinne/arm-cs-tools/bin/arm-none-eabi-objcopy -I ihex -O binary build/braids/braids_bootloader_combo.hex build/braids/braids_bootloader_combo.bin
openocd -f stmlib/programming/jtag/interface_stlink-v2 .cfg -f stmlib/programming/jtag/stm32f10x_hla.cfg -f stmlib/programming/jtag/prelude_f10x.cfg -f stmlib/programming/jtag/erase_f10x

..... bunch more stuff that looks ok .....

/Users/Corinne/arm-cs-tools/bin/arm-none-eabi-gcc -c -g -O2 -Wall -Werror -Wno-unused-local-typedefs -fasm -finline -finline-functions-called-once -fdata-sections -ffunction-sections -fshort-enums -fno-move-loop-invariants -I. -DGCC_ARMCM3 -DSTM32F10X_MD -DAPPLICATION -DF_CPU=72000000L -DF_CRYSTAL=8000000L -DUSE_STDPERIPH_DRIVER -DSYSCLK_FREQ_72MHz=72000000L -Istmlib/third_party/STM -Istmlib/third_party/STM/CMSIS/CM3_f10x -Istmlib/third_party/STM/CMSIS/CM3_f10x/startup/gcc -Istmlib/third_party/STM/STM32F10x_StdPeriph_Driver/inc -mcpu=cortex-m3 -mthumb -fno-unroll-loops -std=c99 stmlib/third_party/STM/STM32F10x_StdPeriph_Driver/src/stm32f10x_usart. c -o build/braids/stm32f10x_usart.o
/Users/Corinne/arm-cs-tools/bin/arm-none-eabi-gcc -c -g -O2 -Wall -Werror -Wno-unused-local-typedefs -fasm -finline -finline-functions-called-once -fdata-sections -ffunction-sections -fshort-enums -fno-move-loop-invariants -I. -DGCC_ARMCM3 -DSTM32F10X_MD -DAPPLICATION -DF_CPU=72000000L -DF_CRYSTAL=8000000L -DUSE_STDPERIPH_DRIVER -DSYSCLK_FREQ_72MHz=72000000L -Istmlib/third_party/STM -Istmlib/third_party/STM/CMSIS/CM3_f10x -Istmlib/third_party/STM/CMSIS/CM3_f10x/startup/gcc -Istmlib/third_party/STM/STM32F10x_StdPeriph_Driver/inc -mcpu=cortex-m3 -mthumb -fno-unroll-loops -std=c99 stmlib/third_party/STM/STM32F10x_StdPeriph_Driver/src/stm32f10x_wwdg.c -o build/braids/stm32f10x_wwdg.o
/Users/Corinne/arm-cs-tools/bin/arm-none-eabi-gcc -c -x assembler-with-cpp -mcpu=cortex-m3 -mthumb -fno-unroll-loops stmlib/third_party/STM/CMSIS/CM3_f10x/startup/gcc/startup_stm32f10x_md .s -o build/braids/startup_stm32f10x_md.o
/Users/Corinne/arm-cs-tools/bin/arm-none-eabi-gcc -Wl,-Map=build/braids/braids.map -Wl,--gc-sections -T stmlib/linker_scripts/stm32f10x_flash_md_application.ld -mcpu=cortex-m3 -mthumb -fno-unroll-loops -I. -DGCC_ARMCM3 -DSTM32F10X_MD -DAPPLICATION -DF_CPU=72000000L -DF_CRYSTAL=8000000L -DUSE_STDPERIPH_DRIVER -DSYSCLK_FREQ_72MHz=72000000L -Istmlib/third_party/STM -Istmlib/third_party/STM/CMSIS/CM3_f10x -Istmlib/third_party/STM/CMSIS/CM3_f10x/startup/gcc -Istmlib/third_party/STM/STM32F10x_StdPeriph_Driver/inc -Lstmlib/third_party/STM -o build/braids/braids.elf build/braids/analog_oscillator.o build/braids/braids.o build/braids/digital_oscillator.o build/braids/macro_oscillator.o build/braids/quantizer.o build/braids/resources.o build/braids/settings.o build/braids/ui.o build/braids/adc.o build/braids/dac.o build/braids/debug_pin.o build/braids/display.o build/braids/encoder.o build/braids/gate_input.o build/braids/internal_adc.o build/braids/system.o build/braids/uart_logger.o build/braids/random.o build/braids/bootloader_utils.o build/braids/system_clock.o build/braids/core_cm3.o build/braids/system_stm32f10x.o build/braids/misc.o build/braids/stm32f10x_adc.o build/braids/stm32f10x_bkp.o build/braids/stm32f10x_can.o build/braids/stm32f10x_crc.o build/braids/stm32f10x_dac.o build/braids/stm32f10x_dbgmcu.o build/braids/stm32f10x_dma.o build/braids/stm32f10x_exti.o build/braids/stm32f10x_flash.o build/braids/stm32f10x_fsmc.o build/braids/stm32f10x_gpio.o build/braids/stm32f10x_i2c.o build/braids/stm32f10x_iwdg.o build/braids/stm32f10x_pwr.o build/braids/stm32f10x_rcc.o build/braids/stm32f10x_rtc.o build/braids/stm32f10x_sdio.o build/braids/stm32f10x_spi.o build/braids/stm32f10x_tim.o build/braids/stm32f10x_usart.o build/braids/stm32f10x_wwdg.o build/braids/startup_stm32f10x_md.o
/Users/Corinne/arm-cs-tools/bin/arm-none-eabi-objcopy -O ihex build/braids/braids.elf build/braids/braids.hex
cat build/braids/braids.hex build/braids_bootloader/braids_bootloader.hex | \
awk -f stmlib/programming/merge_hex.awk > build/braids/braids_bootloader_combo.hex
/Users/Corinne/arm-cs-tools/bin/arm-none-eabi-objcopy -I ihex -O binary build/braids/braids_bootloader_combo.hex build/braids/braids_bootloader_combo.bin
openocd -f stmlib/programming/jtag/interface_stlink-v2 .cfg -f stmlib/programming/jtag/stm32f10x_hla.cfg -f stmlib/programming/jtag/prelude_f10x.cfg -f stmlib/programming/jtag/erase_f10x.cfg -c "flash write_bank 0 build/braids/braids_bootloader_combo.bin 0x0" -c "verify_image build/braids/braids_bootloader_combo.bin" -f stmlib/programming/jtag/postlude.cfg || openocd -f stmlib/programming/jtag/interface_stlink-v2 .cfg -f stmlib/programming/jtag/stm32f10x_hla.cfg -f stmlib/programming/jtag/prelude_f10x.cfg -f stmlib/programming/jtag/erase_f10x.cfg -c "flash write_bank 0 build/braids/braids_bootloader_combo.bin 0x0" -c "verify_image build/braids/braids_bootloader_combo.bin" -f stmlib/programming/jtag/postlude.cfg
Open On-Chip Debugger 0.9.0 (2016-09-28-17:56)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
embedded:startup.tcl:60: Error: Can't find stmlib/programming/jtag/interface_stlink-v2
in procedure 'script'
at file "embedded:startup.tcl", line 60
Open On-Chip Debugger 0.9.0 (2016-09-28-17:56)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
embedded:startup.tcl:60: Error: Can't find stmlib/programming/jtag/interface_stlink-v2
in procedure 'script'
at file "embedded:startup.tcl", line 60
make: *** [upload_combo_jtag] Error 1



I feel like I'm close. Can anyone tell me where I'm going wrong?

ps: Corinne (the User in the directory) is my gf. I resorted to using her laptop after striking out on the Windows PC we have.
pld
nosamiam wrote:
embedded:startup.tcl:60: Error: Can't find stmlib/programming/jtag/interface_stlink-v2

Check your shell export PGM_INTERFACE=stlink-v2, or in the makefile if you edited it there. There is a file interface_stlink-v2.cfg in that directory, but the command it was trying to execute is
Quote:
openocd -f stmlib/programming/jtag/interface_stlink-v2 .cfg ...

which has an extra space.
hi.mo
Hi all,
So I've build some mutable without problems, but now I've got this shades, and when I power it up the less of my zeus start to blink (also the less of the module) could someone point me in the right direction? cry
Thanks
nosamiam
pld wrote:
nosamiam wrote:
embedded:startup.tcl:60: Error: Can't find stmlib/programming/jtag/interface_stlink-v2

Check your shell export PGM_INTERFACE=stlink-v2, or in the makefile if you edited it there. There is a file interface_stlink-v2.cfg in that directory, but the command it was trying to execute is
Quote:
openocd -f stmlib/programming/jtag/interface_stlink-v2 .cfg ...

which has an extra space.


Thanks, pld! I think I fixed that but I need more hand-holding. Now I get this:

openocd -f stmlib/programming/jtag/interface_stlink-v2.cfg -f stmlib/programming/jtag/stm32f10x_hla.cfg -f stmlib/programming/jtag/prelude_f10x.cfg -f stmlib/programming/jtag/erase_f10x.cfg -c "flash write_bank 0 build/braids/braids_bootloader_combo.bin 0x0" -c "verify_image build/braids/braids_bootloader_combo.bin" -f stmlib/programming/jtag/postlude.cfg || openocd -f stmlib/programming/jtag/interface_stlink-v2.cfg -f stmlib/programming/jtag/stm32f10x_hla.cfg -f stmlib/programming/jtag/prelude_f10x.cfg -f stmlib/programming/jtag/erase_f10x.cfg -c "flash write_bank 0 build/braids/braids_bootloader_combo.bin 0x0" -c "verify_image build/braids/braids_bootloader_combo.bin" -f stmlib/programming/jtag/postlude.cfg
Open On-Chip Debugger 0.9.0 (2016-09-28-17:56)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Error: The specified debug interface was not found (hla)
The following debug interfaces are available:

Open On-Chip Debugger 0.9.0 (2016-09-28-17:56)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Error: The specified debug interface was not found (hla)
The following debug interfaces are available:

make: *** [upload_combo_jtag] Error 1
lasesentaysiete
nosamiam wrote:
I need more hand-holding. Now I get this:

I think the best hand-holding is Olivier's Dev Environment smile
nosamiam
lasesentaysiete wrote:
nosamiam wrote:
I need more hand-holding. Now I get this:

I think the best hand-holding is Olivier's Dev Environment smile


I'll give that a try. Thanks.
lasesentaysiete
thumbs up It makes your problems disappear. Firmware uploading problems, that is. Obviously you don't "learn the hard way", though.
nosamiam wrote:


I'll give that a try. Thanks.
hautlle
hautlle wrote:
ZZ Ardoz wrote:
hautlle wrote:
And now the LEDs no longer come on w/ power.... lol, time for a break Dead Banana


Check your 4.7 resistor to see if if fried


got a reading of 5.6 on the multimeter


Ended replacing that resistor to be safe and going over everything once more and found the tiniest hair of a short b/w pins 49/50 on the MCU. Fixed that and I now have a flashed and working Clouds applause
akashic53
Anyone have a clue how to troubleshoot intermittent output on channel 2 of the Warps module, with nothing connected to level 2? It appears to be related to normalization on that input. Mutable forum suggests there is a software fix and that parts are out of tolerance, but this does not seem to be the case here, unless the opamps are out somehow. With nothing connected, scoping the level_1_cv and level_2_cv outputs shows a very low amplitude waveform at 2.8v above ground. Can someone verify that is the correct level?
pichenettes
If it's a DIY build, calibrate it...
akashic53
pichenettes wrote:
If it's a DIY build, calibrate it...


hmm... thought I did that, but it turns out I don't know how to follow instructions. I had started the calibration with level 2 connected. Starting with nothing connected and then going through the procedure fixed the issue. Many thanks.
Digitek
Hello people,,

Just finish my Rings , turn on and work ok until i move R49 potentiometer all to the left it burns the resistor 4.7.. i change potentiometer and still the same..

Anyone experience something like that,, or any tip ??

thanks
emmaker
Quote:
Just finish my Rings , turn on and work ok until i move R49 potentiometer all to the left it burns the resistor 4.7.. i change potentiometer and still the same.


Looking at the schematic it looks like either the 3.3V or GND might be shorted to the wiper of R49. As you turn the wiper one way there is less resistance and more current being sucked burning up the 4.7 resistor. If you have an ohm meter use that to look for a short between the wiper and the other two sides. Make sure that you turn the pot opposite way of what you are measuring. For GND to wiper turn the pot to 3.3V and for 3.3V to wiper turn to GND.
nicdro
I finished my streams. Everything's working as it should but when in compressor mode it doesnt really compress. the level mod acts as an bias and exp/lin distorts the sound. shape and mod dont effect the sound but are working in the other modes. any ideas?
lasesentaysiete
could be a calibration issue?
nicdro wrote:
I finished my streams. Everything's working as it should but when in compressor mode it doesnt really compress. the level mod acts as an bias and exp/lin distorts the sound. shape and mod dont effect the sound but are working in the other modes. any ideas?
nicdro
i've done the calibration and reflashed. no change at all.
lasesentaysiete
I only mentioned it because my streams is similar, but haven't calibrated it yet.

does the sidechaining have any effect?

nicdro wrote:
i've done the calibration and reflashed. no change at all.
nicdro
lasesentaysiete wrote:
I only mentioned it because my streams is similar, but haven't calibrated it yet.

does the sidechaining have any effect?

nicdro wrote:
i've done the calibration and reflashed. no change at all.


ah good to know.
nope no sidechain at all. but both channels doe act the same. i already thought im using it the wrong way... but turning any knobs in compression mode make no effect beside level mod and exp/log - really depressing
nicdro
sorry for double:
it seems like i have to turn the level mod fully CCW. then i have no output left. how's yours?
lasesentaysiete
check divkid's video for streams. Mine behaves exactly the same way so I asume its correct. I guess its just not a crazy psycho kick type comp smile
nicdro
still cant get the sidechain working
nicdro
the bar graph displays the incoming exciter signal and corresponds to the knobs mod and shape though...
lasesentaysiete
yeah, by all accounts, including my own, its not a real heavy-hitter type compressor. I would say that your build is most likely ok, though.
nicdro wrote:
the bar graph displays the incoming exciter signal and corresponds to the knobs mod and shape though...
nicdro
lasesentaysiete wrote:
yeah, by all accounts, including my own, its not a real heavy-hitter type compressor. I would say that your build is most likely ok, though.
nicdro wrote:
the bar graph displays the incoming exciter signal and corresponds to the knobs mod and shape though...

yes i do know. but sidechain isnt working at all so i guess its not likely ok wink
and i jsut recognized that the vca behaves odd as well. I'll reflow it upcoming weekend. im not satisfied how it turned out in the end...
adam
reading the start of this thread might prove helpful
Altitude909
So has anyone here successfully built an Edges? I'm working on one now and nothing I can do seems to get the 3rd and 4th tune pots working. Voltages are correct on the pot (-10V) and I can trace everything to the ADC but neither do anything nor does the CV in to those channels. I've calibrated all 4 channels (there was a post on the MI forums by someone who had the same issue and fixed it with with a calibration) but no dice on those two. The select waveform controls work fine and they make sound but no modulation or pitch control
pld
Altitude909 wrote:
So has anyone here successfully built an Edges? I'm working on one now and nothing I can do seems to get the 3rd and 4th tune pots working. Voltages are correct on the pot (-10V) and I can trace everything to the ADC but neither do anything nor does the CV in to those channels. I've calibrated all 4 channels (there was a post on the MI forums by someone who had the same issue and fixed it with with a calibration) but no dice on those two. The select waveform controls work fine and they make sound but no modulation or pitch control

Haven't built one myself, but is that the PCB version with a 3208 ADC? There's the OCTAL_ADC #define that's not enabled by default in the makefile (line 26) so it might just be a firmware issue.
Altitude909
pld wrote:
Altitude909 wrote:
So has anyone here successfully built an Edges? I'm working on one now and nothing I can do seems to get the 3rd and 4th tune pots working. Voltages are correct on the pot (-10V) and I can trace everything to the ADC but neither do anything nor does the CV in to those channels. I've calibrated all 4 channels (there was a post on the MI forums by someone who had the same issue and fixed it with with a calibration) but no dice on those two. The select waveform controls work fine and they make sound but no modulation or pitch control

Haven't built one myself, but is that the PCB version with a 3208 ADC? There's the OCTAL_ADC #define that's not enabled by default in the makefile (line 26) so it might just be a firmware issue.




And that was it. Apparently there are 2 hardware versions, the one with the 3208 gets that flag enabled
nicdro
Havent found a solution for my streams. The previous posts on it were not helpful unfortunately. So any other hints on that? Thanks!
nicdro
and i found some odd behaviour. both channels do work in vca mode but there is allways a little sound slipping through when level mod is fully CW. I need to open it that far otherwise there is no sound coming out. VCA works so far...
ZZ Ardoz
nicdro wrote:
and i found some odd behaviour. both channels do work in vca mode but there is allways a little sound slipping through when level mod is fully CW. I need to open it that far otherwise there is no sound coming out. VCA works so far...


Did you follow the calibration procedure?
nicdro
ZZ Ardoz wrote:
nicdro wrote:
and i found some odd behaviour. both channels do work in vca mode but there is allways a little sound slipping through when level mod is fully CW. I need to open it that far otherwise there is no sound coming out. VCA works so far...


Did you follow the calibration procedure?

Yes i did. Perhaps I should do it again..
johncanning
Hi guys,

Trying to flash an elements board. The chip has been through the mill a little so I reckon I have some how bricked it but would like confirmation, if anyone can help?

When I try make -f elements/makefile upload I get

Error: Target not halted
Error: failed erasing sectors 0 to 7

If I try upload_combo_jtag I get

Error: error executing cortex_m crc algorithm

I can upload more of the output code if needed but I thought that this would be enough.

Nice one folks!
eonz
Quick question to anyone who has built a Rings.
So I've successfully flashed the chip and everything went well but I noticed that the 2 LED's when lit were really dim. When powering up the Rings after successfully flashing the chip, the LED's don't light up at all...no action. I haven't soldered the pots or jacks yet because I wanted to see if I would have a issues before.
Any info to help guild me down the right path would be amazingly appreciated!
Cheers
ZZ Ardoz
eonz wrote:
Quick question to anyone who has built a Rings.
So I've successfully flashed the chip and everything went well but I noticed that the 2 LED's when lit were really dim. When powering up the Rings after successfully flashing the chip, the LED's don't light up at all...no action. I haven't soldered the pots or jacks yet because I wanted to see if I would have a issues before.
Any info to help guild me down the right path would be amazingly appreciated!
Cheers


Meter power around the board and see if all as should be.
nicdro
Fixed my Streams by reflowing everything. And i mean literally EVERYTHING. Now it's working as it should.
tnolan
Hi folks,

Nearing completion on a largely normally behaving Clouds - boot, button, LED behaviors all seem right as does the VU metering function of LEDs on an input signal. Don't get any output though.

My thought is that the DAC is fine since the VU metering works - at least it appears that's where the input goes from the .sch file.

Once I verify component values around the output TL0720, might I correctly presume that refloating and perhaps replacing that 0720 is the next step or should I be debugging further up the chain?

Thanks for any suggestions.
berenie
tnolan wrote:
Hi folks,

Nearing completion on a largely normally behaving Clouds - boot, button, LED behaviors all seem right as does the VU metering function of LEDs on an input signal. Don't get any output though.

My thought is that the DAC is fine since the VU metering works - at least it appears that's where the input goes from the .sch file.

Once I verify component values around the output TL0720, might I correctly presume that refloating and perhaps replacing that 0720 is the next step or should I be debugging further up the chain?

Thanks for any suggestions.


i'm far from an expert on debugging these things, but presuming you cleaned the board thoroughly and your soldering looks really neat.. you might want to try to update your module via .wav . if that does not improve things its fairly standard to reflow etc.
tnolan
SOLVED - *gigglesnort* - forgot to put in R61 and R62.
tnolan
I wish my Elements problem were as easy as my Clouds problem:

*poof*

Plugged in Elements build (only missing SW1) - LEDs popped on then off - slight smoke from behind the center top of the panel. Nothing appears awry on inspection and I've subsequently retried a couple times to note LED behavior - quick flicker on and off. Measured values of all passive components around semiconductors in power supply areas - all seems ok there. Diodes don't seem cooked.

Replace IC2 and IC4? IC4 is near the smoke point in question. Any other ideas or docs on where/how to trace?

With just the basic power in place, this board flashed fine just a few days ago.
Thermospore
When I plug in my DIY Rings all my other modules turn off and the lights on my power supply dim. I triple checked the cable is plugged in the right way, and my multimeter doesn't show any shorts between the -12, +12, and ground. Anyone know what might be wrong? Thanks!
tnolan
Thermospore wrote:
When I plug in my DIY Rings all my other modules turn off and the lights on my power supply dim. I triple checked the cable is plugged in the right way, and my multimeter doesn't show any shorts between the -12, +12, and ground. Anyone know what might be wrong? Thanks!


Quintuple check diode orientation.
ijed
tnolan wrote:
Plugged in Elements build (only missing SW1) - LEDs popped on then off - slight smoke from behind the center top of the panel. Nothing appears awry on inspection and I've subsequently retried a couple times to note LED behavior - quick flicker on and off. Measured values of all passive components around semiconductors in power supply areas - all seems ok there. Diodes don't seem cooked.

Replace IC2 and IC4? IC4 is near the smoke point in question. Any other ideas or docs on where/how to trace?

With just the basic power in place, this board flashed fine just a few days ago.


Hmm If there's magic smoke from the centre top maybe the cap C9?
Are you getting 3.3v from IC2 and IC4?

My elements has also been working fine and have been using it sans panel.
Now when I fire it up lights flash on start up and then nothing. Not responding to triggers or manual trigger

I can flash it via JTAG fine and I can put it into firmware update mode but get no level indication when I try and play the wav file into ext 1.
Doesn't seem to go into calibration mode and it had the new firmware and doesn't seem to change modes.
tnolan
Thanks for the suggestion - replaced C9 after it measured froggy - also got the 100n next to it. Powered it and reflashed - no smoke and I'm getting actual sound off of Strike. Nothing on Bow or Blow, but I'll calibr