[solved] patches upgrade

Hi all

I might be either dumb or dumb (or tired), but I can’t find how to fill my 512k newly bought eeprom with the new patches made for 128k eeprom…I gently upgraded (using avrisp mkii) my shruthi to v0.92, everything went fine…but I only got the 16 preset patches…

Well are those new patches downloadable ? Where is the midi file ?

cheers !


The file is here. Use saved target as

factory data 128k

deleted :smiley: too late

I might have to re-read the procedure…Pushing S6 button during boot makes my LCD’s first line and LEDS L1, L3, L5 and L7 lit. When I transmit sysex packets, all leds light off but nothing else happens… Ididn’t manage to upgrade the patch memory…Might have to look at the pause between packets…

I’m using Linux, so does anybody know an app that can send and receive sysex (working with jack server would be awesome)…I use simple sysexxer yesterday…

> Pushing S6…

This is the firmware upgrade procedure, to update the firmware code stored on the MCU’s flash memory.

You don’t need to put the Shruthi in any special mode, or initiate any special procedure to update the patches which are just stored in eeprom. It would be quite cumbersome indeed if you had to reboot the Shruthi everytime you want to dump a patch!

OK, I’ll then try that when I come back home tomorrow

Thanks pichenettes, and sorry for the dumb question !

Cheers !


Hi there gentlemen getting the same problem as Tom … I dropped a 512k eeprom in from Farnells , upped the syx file and all I get is 16 presets both voices and sequences both … it lets me see 464 slots though …

any insight greatly received …



What happened while you played the .syx file to the Shruthi?

Hi there

Resolved …in my case at least… there is some kind of funky switch on the front of of the Fastlane MIDI port I use which generates a thru…allegedly … it had been depressed and for some reason this prevents data transmittion …even though the LEDs on that unit show transmittion …, but not on the Shruthi…
Making sure that was not depressed sent both syx files correctly and received to the Shruthi …hoping that can help someone else …
All the patches and sequences are there , along with the spare slots ( 464 in total )

Sorry to have buggered you about when it was an external problem …


Paul Burns …

It’s high time for a little lesson…

There are 3 persistent memory units on a Shruthi-1:

  • The program flash on the ATMega644p, storing the firmware code and the wavetables.
  • The 16kb eeprom in the ATMega644p, storing a handful of patches and sequences (1 to 16)
  • The external eeprom.

The Shruthi-1 firmware can easily access the internal and external eeprom. It’s not a big deal to write to them - this can be done anywhere in the firmware code, for example when you are saving a patch on the load/save page… Rewriting the flash to upgrade the firmware is a totally different story. Think a minute about what the job done by the firmware updater… this is a bit of code, so it must be located somewhere on the flash… but then its job is to write the flash, so there’ll be a time where it’ll have to write over itself! Arghhh! It’s sawing the branch on which it is sitting!

Here comes the concept of bootloader: this is a “safe”, non writable (except with a programmer) area at the flash memory in which you can run a little piece of code doing the firmware update. That’s why you need to do something special to do a firmware update… You need to tell the Shruthi “don’t boot into the main code because it’s going to be thrown away, so boot in the ‘safe zone’ of the bootloader”.

And now, back to the problem: there’s absolutely no reason why you’d need to be in this “safe zone” to do a backup/restore of the patches. A patch library restore is a trivial operation, it’s just like saving a patch, multiple times. You don’t have to reboot your Shruthi whenever you want to save a patch, right? So you don’t need to do it either to do the patch library restore.

thanks olivier I have always got that …

I just saw that someone else had had the same prob …

great stuff now I have to work out why the MIDI Thru on my fastlane does not say what it does on the tin …

regards as always

Paul Burns

Worked finally fine…I had to use Midi-Ox under windows…problem came from my sysex app under linux (simple sysexxer)…I did’nt investigate more (will have to if I want to use it, maybe the 250ms time space between transmitted packets)) Anyway, the factory_data.syx worked fine, I now have a 0.92 with 100 more presets greaaaaaattt

Thanks !



After the memory upgrade, is it normal to have patches #17, #18 and #19 empty Did something go wrong during my eeprom update ?



Yes, it looks like something went wrong during the update.

Ok this time, my problem is really solved…was a MIDI-ox setting problem

Thanks !


Tom, what settings did you use?

I won’t have my computer near me until tuesday afternoon…Not sure of the exact settings but you can try this:

in the sysex panel, go to buffers config. In the low level input buffer (same for the low level output), put 256 for the first setting and 2 for the number of buffer. At the bottom of the window, untick autoadjust time, set the two parameters to 250ms.

With the edirol FA-101, I had to set my buffer size to max (but my computer is quite old)

I’ll give you the exact parameters as soon as I go back home !



I have received the 512kb part from Microchip today.

I confirm it doesn’t work. The mystery (or lack of) is in the datasheet… I looked at the I2C bus frequency (should be at least 400kHz), which is fine, but it wasn’t the only important parameter to watch. The Microchip part has a 5ms write cycle, while the ATmel part, has a maximum 5ms write time - in practice it’s near 3ms.

The Shruthi-1 code uses a 4ms delay after eeprom writes to wait for the data to be commited, and I have never seen any problem with that. Even if this incurs a 20% penalty on patch saving speed, I have decided to change this delay to 5ms to be compatible with the Microchip eeproms. I used the burnito firmware to simulate mass writes (the good thing about it is that it does a check after each write so it’s easy to see if there’s any data corruption), and after 15 full write/read cycles it always passed the test with a 5ms delay. If you’re paranoid, I let you compile the code with a 6ms delay - it is in hardware/hal/devices/external_eeprom/h, L107.

I have uploaded at the usual location a v0.92 update file with the write delay fix (5ms).

thank you very much, this is awesome!

Yes, thank you very much indeed pichenettes! It all works beautifully. I used your 5ms 0.92 beta and sent the patches using 300ms delay. Thanks very much for taking the time and making the effort to find a solution for the Microchip EEPROMS. I have been banging my head against the wall trying to get the patches to load using different timings and different sysex tools to no avail so it couldn’t have come at a better time (at least before my head split open :sunglasses: