Shuthi XT : Value 128

Hi, I’m building a new Shruthi XT and I flashed the firmware. However, two things happens :

  • After being in Shruthi XT Full Control Mode, all values are at 128. I can move them individually to whatever my potentiometers are set but when it goes back to the menui showing the values, they show as 128.
  • Flashing the EEPROM gets stuck at 92% and fails. Mighhhht be related to the first issue.

Change EEPROM? Re-flash? What is the best course of action?


Did you compile the firmware from source? Keep in mind, that a specific compiler version is needed for the firmware to fit into the flash memory.

I did follow the instructions on the firmware section of the shruthi page and found them pretty straight forward. I changed the EEPROM to an empty one I had extra, changed USB cable, tried to flash with an Arduino I had laying around but I’m struggling with communication between Crosspack and the UNO.
Haven’t tried with a precompiled hex to be honest.
I’m changing avr programmer tomorrow so I’ll give it a try.

Great. But the problem is that only a specific version of the gcc compiler produces the right optimizations and makes the code small enough to fit into the flash memory of the AVR. You won’t see any errors, it just won’t work. And the type of programmer that you use is irrelevant, too.

Simply flash the precompiled hex files with avrdude with any programmer you have at hand.

That would make sense! My gcc might be a tad too much in the future. I’ll give it a try with precompiled when I get back home tonight.
However, after checking the repo, I’m realizing the .hex of the EEPROM for XT is already built and is not part of the makefile (unless I missed something?). I’m getting avrdude errors in usb receiver (expected 4, received -1) at 92% of the EEPROM flashing process, every single time.
Any idea if this kind of error points in the direction of the programmer, the .hex or the EEPROM?

Alright so new AVR programmer, just in case.

EEPROM flashing (the one in the github repo) :
Writing | ############################################## | 92% 146.80s
avrdude: error: usbtiny_send: usb_control_msg(DeviceRequestTO): transaction timed out (expected 128, got -60)

avrdude: error: usbtiny_receive: usb_control_msg(DeviceRequestTO): unknown error (expected 4, got -1)

avrdude: error: usbtiny_receive: usb_control_msg(DeviceRequestTO): unknown error (expected 4, got -1)

And it brings me back to the issue where I have only 16 factory patches, the memory access is slow and freezes the os.
I’ll try pre-compiled through MIDI and the bootloader.

EDIT : Through C6, interestingly enough, even though it’s plugged in, the LEDs are not displaying like a progress bar in firmware update mode. Strange.
Checking the synth MIDI channels give me impossible values that change every time I get on the setup page (Channel 19, 25, etc)

The crazy values are a typical symptom for the wrong compiler version, it happened to me before so I’ve seen those errors myself.

For the bootloader you don’t have to set any midi channels at all. If the synth doesn’t go into the bootloader mode, then most likely you have not flashed the bootloader yet. You can compile the bootloader with any version of the gcc compiler, as (to my knowledge) the bootloader is not as tightly crammed and there is no risk in overflowing the bootloader memory with another compiler version.

So here’s what you can do:

  1. Check if the synth boots into bootloader mode (indicated by the led pattern described in the manual).
  2. If it doesn’t boot into the bootloader, compile that and upload it.
  3. Upload the precompiled firmware via midi

really, it is very important to have a working bootloader installed. I have seen many request here from people who bought a Shurhti used and didn’t have a bootloader installed and were not able to upload a new firmware.

Alright so following your instructions :

  • Cleared the chip with AVRdude.
  • Re-compiled only the Bootloader
  • Uploaded Bootloader.
  • Got the Bootloader mode to work (LED 1,3,5,7 are lit)
  • Opened C6. Tried sending the Firmware and then the EEPROM.

Part where it doesn’t work : sending the sysex file will not move the LEDs like it should like a loading screen.
Checked soundcard, changed cable, checked if there is any current flowing from the 644p to the MIDI In port. Nada.
At this point, is there a pre-compiled hex I can use somewhere? I can probably give it a try if I can find a version that was compiled with the right version of GCC. It’s still strange that bootloader mode activates as it should but does not move the LEDs… Is there something in bootloader mode I can do to at least check if it’s not frozen?

There are two things that typically go wrong.

  1. The USB-MIDI interface struggles with large sys-ex messages. This happens often with cheap interfaces. You could try another one.
  2. You can introduce some small delay between the packets (there is a setting in C6 for this). if you send them too quickly, the Shruthi won’t be able to keep up.

Once the bootloader receives the first valid message, it switches its leds to the progressbar mode. if the leds “switch off” (0% progress) but then don’t move, you certainly have an issue with the timing (see above). If nothing happens, you can only check the entire midi signal path from C6 to the Shruthi.

Thanks! That was indeed the audio interface being the issue.
Surprisingly, it’s a cheaper audio interface than the one I used that was able to upload the Sysex messages :slight_smile:

Great! I hope everything is working just fine now! Enjoy your Shruthi!

Unfortunately, my joy did not last long.
After putting it into the case, the firmware somehow disappeared.
I reuploaded it and it was fine but noticed some issues on the filter board I had to take care of.

Lots of back and forth trying to pin point issues (still thinking it is due to crappy headers).Long story short :
Turns out that my chip won’t accept upload via MIDI anymore. It boots with squares on two lines, can go in bootloader mode but nothing happens during MIDI.

Replaced the 74HC165. No changes.
Changed Atmega to another one. Issues with rc initialization =1.

I’m starting to think so solder joints needs to be reflowed after going back and forth.

Any other idea of what could be the issue?

Hard to say what’s wrong. Maybe you can give some details. What did you do, what did you expect to happen, what happened instead?

Hi! Actually I was able to give it a shot today.
Issue was that my other sound interface died. Tried again with another one and it can now receive sysex (yay).
Alright so now I’m at an issue where the moment I unplug the XT control board from the filter board (while making sure there is no electricity) it will lose the firmware. Alright, no big deal. Flash the chip. Download sysex. It works…without the filter board (so power coming from ISP programmer).
Put on the filter board. Two lines on screen, all LEDs on. Nada.
Alright, I can go in bootloader mode and send the sysex (while having the power board plugged in and using the 9V power supply). After it’s done uploading… it gets stuck.
All LEDs but the last one is lit up. Completely frozen.
If I erase the chip, unplug the control board from the filter board and transfer with power from the ISP, I will be able to access the firmware once in a while. Strangely enough, it breaks the moment I’m trying to upload the factory presets in bootloader mode and I need to erase the chip, flash it with the bootloader and do it again.

Any ideas at this point of what could be the cause of this issue? Short between the two boards? Something like this?

I’m not sure if I can follow what you did. You say, you can download the firmware via sysex. But later on you write it gets stuck when you download it via sysex. I see you switch between ISP, sysex, factory presets, bootloader.

The problem is, I can hardly follow what you did. Lets not mix too many different things at once and do things step by step.

  1. When you power the synth on with the bootloader button combination pressed, does it go into a bootloader?
  2. if yes: Configure your sysex software on the computer with some delay between data packets. I use Elektrons C6.
  3. Send the official, precompiled firmware file via sysex. If it gets stuck, simply shut it off and retry, maybe with a longer delay between the packets.
  4. Once the firmware is transmitted correctly, power on the synth and check if everything looks okay

Please go through these steps one after the other. If there is something unexpected, stop and give as many details as you can. Please don’t randomly try different things. That only makes it harder to troubleshoot.

My bad, it can be confusing.

  1. Yes it does.
  2. Done. 15 ms is used.
  3. That’s where the issue is : it transmits the sysex but gets stuck once it is finished. Like it would try to boot the firmware after it’s done transmitting (which it did previously) but it can’t boot the firmware. This situation applies only if I’m using the 9V power supply and not the power from the ISP.
    If I’m doing step 3 with the power of the ISP only (control board, no filter board), it will transmit and boot as expected. However, if I’m plugging it back to the filter card, we’re going back to the issue where it can’t boot the firmware at all.

Sorry for not being clear enough.

Okay, that sounds like the firmware is actually running just fine and there most likely is a problem with your filter board.
What filter board are you using? What power supply do you use?

4PM, 9V/1A AC.

Found out that the issue was bad headers (I knew it!!!).

BUT I got too excited when testing that both of my boards touched on the regulators :’(

I was able to identify that the short comes from the control board as plugging the ISP programmer did not light up the screen. Checked voltages on the ground +5V (headers) and I’m getting 0.10V at most…
Swapped the Atmega, removed the chips to check if voltage passes through. Nada.
Physically, it touched near RN3. Check the voltages in this area and I’m getting the same 0.10V, sometimes nothing. Only suspect thing is the ISP pins give 0.8V between this and the GND on the headers.

On the top of someone’s head, any idea of which component would be more prone to short easily? (Caps? RN?)

Can you post high resolution photos of your board from both sides?

For sure!