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 Braids Forgetting Firmware
MUFF WIGGLER Forum Index -> Music Tech DIY  
Author DIY Braids Forgetting Firmware
Bran
I’ve just finished my build of a DIY braids, culminating in the long awaited triumph that was the firmware successfully uploading via .wav.

After testing some things out, I unpowered my rack to do some adjustments. Upon repowering, the braids was back in “RDY” state. Seemingly the firmware had failed to save. I reuploaded the firmware to check if this was a one-off bug, but it happened again upon powering down the module.

Doing a little more poking around, I noticed that the encoder seems to not do anything (enter menus) when I press it. I tested this on many of the settings, and none of them seemed to react to an encoder press.

My first idea what that it could be a faulty encoder stuck in the always depressed position, hence every time the module boots it gets bumped into “RDY”. I think I’ve ruled this out by testing encoder for continuity- it closes the circuit when depressed.

Any ideas what I might do to troubleshoot further? I’ve retouched the solder joints on the encoder and checked the module over visually for anything out of the ordinary.
Altitude909
if you flashed the bootloader, why are you using wav?
Bran
Altitude909 wrote:
if you flashed the bootloader, why are you using wav?


I tried flashing the firmware using the mutable vagrant dev environment, but when I tried

Quote:
make -f /braids/makefile upload


it didn't seem to actually upload the firmware. I tried a few combinations of the make commands (compiling the hex, the bootloader, trying to upload the bootloader), without managing to figure it out. In the process of trying to figure out what I didn't understand, I found people using the wav method and took it as the lazy way :p

If you could explain the bootloader/firmware relationship and what I'm missing I'd love to know, even if it's not related to this problem Mr. Green
Altitude909
The bootloader is there to load the audio firmware via wave file, the main program is the main program. You generally need both for the device to run correctly.

The order is:

Make the bootloader (make -f braids/bootloader/makefile hex)
Make the main program (make -f braids/makefile)
Upload both via JTAG (make -f braids/makefile upload_combo_jtag)

The encoder plugs directly into the uC so if that's not working (and its not since it keeps booting you into the bootloader), you have some hardware debugging to do
Bran
Altitude909 wrote:

The encoder plugs directly into the uC so if that's not working (and its not since it keeps booting you into the bootloader), you have some hardware debugging to do


I've been working on debugging the hardware. The middle pin on the encoder seems to be the only one tied to ground (which makes sense since it goes straight into the ground plane)...
forestcaver
I’d flash the fw via jtag first as suggested above.If that fails then my suggestion is either 1. Still a faulty encoder or, more likely, 2 a bridge on pin 2 of the stm32. Look under high magnification at pins 1, 2 and 3. Check the trace from the encoder to make sure it’s not damaged as well.
Bran
Checked pins 1-3 for continuity, they're not linked. Tested the path from pin 2 to encoder, which is continuous. Checked pin2/encoder click for connection to ground, and there was none. Tore out the encoder, which took about 2 hours of fury. It. Would. Not. Desolder.

Tried different solder wick, tried adding a bit of solder for thermal transfer, tried a hot-air rework station, burnt myself twice in the process. Resisted the urge to force it with pliers. Went to bed, gave it a day to rest. Came back- same problem. Cranked the iron heat and went medieval on this encoder. Think first chapter of Discipline and Punish. Hot pokers. Tearing flesh with pliers- the works. I actually think it was drawn into quarters now that I think about it...

Encoder is in pieces in garbage, but finally off. Didn't even pull a pad somehow. Didn't help, still booting into RDY without the encoder even being connected....

But it isn't a faulty encoder (I reiterate- fuck that encoder), and it isn't a solder bridge (as far as i can tell), and the pin 2 doesn't seem to be shorted to ground. I checked the reset/sysboot switches, and they don't seem to be faulty. Powered module (still no encoder installed), measured pin 2 and 3 at +3.3V.

Measured JTAG reset (pin 7) at +3.3V, not sure what it should be though.

Shorting pin 1 to pin 2 (3.3V to RESET) resets the whole skiff. Shorting pin 2 to GND doesn't seem to do anything at all. (I thought pin 2 -> ground was the convention, so guess I learned something)

I'm just sketching out everything I have seen in case something is a useful hint because at this point I'm sort of at a loss.
sduck
It still sounds like you haven't loaded the bootloader. You don't need vagrant to do that, just find the precompiled hex for it and the main program and load them via st-link utility or whatever tool you're using with the jtag connector.
forestcaver
If you have loaded the bootloader and main fw and you are happy using a debugger then using the on-chip debugger may be helpful in understanding what is happening....
djthopa
I have had a similar problem today with a diy clouds.

I would flash the mcu, via mutable vagrant, via st flash, via audio wav file and clouds would update fine.

I would then power cycle and the module would go into update mode again.

I later found i had a short between pins 63 (gnd) and pins 61 of the mcu.

Tracked down the short all the way down to the switch led.

Pins 2 and 4 where shorted to ground. Under a microscope if found a very little braid from one of the pcb pads of the switch (bottom layer) to the ground plane.

I had to get a sharpie and cut a circle around the pad so it wouldn’t make contact with the ground pour. It could have been a fault on the pcb or me managing to create a tiny short. Im not sure, but i went pretty mental figuring out what i was doing wrong, thinking it was a software bug and it wasnt.

Have you tried erasing and uploading the mcu fresh?

Can you compile the file from the vagrant or are you uploading only via wav?


Maybe this is whats happening to you?

Hope you get it fixed!
Bran
djthopa wrote:
I have had a similar problem today with a diy clouds.

I would flash the mcu, via mutable vagrant, via st flash, via audio wav file and clouds would update fine.

I would then power cycle and the module would go into update mode again.

I later found i had a short between pins 63 (gnd) and pins 61 of the mcu.

Tracked down the short all the way down to the switch led.

Pins 2 and 4 where shorted to ground. Under a microscope if found a very little braid from one of the pcb pads of the switch (bottom layer) to the ground plane.

I had to get a sharpie and cut a circle around the pad so it wouldn’t make contact with the ground pour. It could have been a fault on the pcb or me managing to create a tiny short. Im not sure, but i went pretty mental figuring out what i was doing wrong, thinking it was a software bug and it wasnt.

Have you tried erasing and uploading the mcu fresh?

Can you compile the file from the vagrant or are you uploading only via wav?


Maybe this is whats happening to you?

Hope you get it fixed!


I've gone through error-free uploads via the vagrant env. for the combo_jtag as well as doing bootloader and main firmware separately. Cleaned the builds, and recompiled with the same result. Never got anything but the RDY with jtag upload.

Haven't tried simply doing a fresh wipe of the MCU. I've been working exclusively through the vagrant env. since I've had a difficult time building the ARM toolchain on ubuntu.

I've been flux-ing and reflowing the MCU, and I am somewhat confident it isn't that now.

Definitely a worry that it could be a PCB short, but that would be rough do debug...

This all being said, there's no short on the MCU as far as my continuity tester can tell Dead Banana
sduck
Is your pcb white by any chance?
Bran
sduck wrote:
Is your pcb white by any chance?


No, it's the Braids PCB from Amazingsynth
forestcaver
Bran wrote:
sduck wrote:
Is your pcb white by any chance?


No, it's the Braids PCB from Amazingsynth


As you paid such a high premium for the board and amazingsynth offer full build support it’s probably worth getting your money’s worth and getting them to support and debug your build.... ?
MUFF WIGGLER Forum Index -> Music Tech DIY  
Page 1 of 1
Powered by phpBB © phpBB Group