Shruthi 1 Blank Chip Programming

Bit late to the party, but I’ve built a couple of these now with various filter boards using blank chips and thought I would share the process that works for me in terms of programming firmware and factory patches as there still seem to be some in the community having the odd problem.

Point to note that I am a PC user on Win 7 64 bit and sending / receiving MIDI via a Behringer UMC404HD. I am also using a standard generic ebay bought (assuming Chinese) USB ISP. The below is with the obvious disclaimer that it is used at your own risk and I cannot be held responsible etc etc.

It is assumed you have installed the driver successfully for your programmer and you have all the hex and syx files.

Btw the six pin programmer adaptor plugs into your control board with the tab pointing up - i.e next to your screen.

1: Install WINAVR 20100110 - standard install paths
2: Add ‘;C:\WinAVR-20100110\bin’ into the environment variables Path via the control panel\system\advanced system settings
3: Open a command prompt (as administrator)
4: Navigate to the directory where your hex files are - I normally put these in the root of C in a folder called ‘mi’. The command would therefore be ‘cd c:\mi’ (in my case)
5: Run the following scripts (copy and paste):

avrdude -B 100 -V -p m644p -c usbasp -P usb -e -U lock:w:0x3F:m -e -u -U efuse:w:0xFD:m -U hfuse:w:0xD6:m -U lfuse:w:0xFF:m -U lock:w:0x0f:m

avrdude -B 1 -V -p m644p -c usbasp -P usb -U eeprom:w:internal_eeprom.hex:i -U flash:w:shruthi1_1.02.hex:i -U flash:w:muboot.hex:i -U lock:w:0x2f:m

6: If you get the fault code(s) ‘avrdude: stk500_getsync(): not in sync: resp=0x00’ and ‘avrdude: stk500_disable(): protocol error, expect=0x14, resp=0x51’ these are related to the internal USBASP firmware but have no effect on successfully loading the code so you can safely ignore them. You do not need to flash the programmer despite what the internet tells you.

I have learned it is advisable to redo the firmware via Midi as sometimes ISP programming can leave you with distorted sounding waves, especially on OSC 2. Download and install (unzip) c6.exe - always run as admin

7: Power up your Shruthi holding down S6
8: Run c6.exe
9: Configure delay to 500ms - I have found this speed works 100% of the time as lower delay speeds sometimes cause inconsistent results, especially loading the factory patches
10: Load 'shruthi1_1.02 .syx
11: Click ‘Send’
12: Reboot your Shruthi NORMALLY - i.e. do not hold down S6
13: Run c6.exe
14: Configure delay to 500ms
15: Load shruthi1_factory_data.syx
16: Send

That pretty much covers it. I hope the above helps other builders out there having issues. If anyone has questions - just ask.

Regards

Stu

1 Like

Really? I’ve never encountered this a single time.

It may be that I have a programmer that has issues and whilst it sorts the bootloader fine, sometimes causes errors with the firmware. Like I said it is an el-cheapo job from ebay…

When I had issues of this nature building my first Shruthi, I read round all the forums and found other builders having varying problems with blank chips. I finally got the process down that works every time for me - I have built six now, 2 for myself and 4 for friends without any further issue. It could just be that it works for the equipment I am currently using, but I thought I would share in case it saves someone else some pain.

The problems others had with the blank chips is that they probably used the wrong compiler version which produces a firmware file that is too large to fit into the flash. This can lead to all sorts of weird behaviour. It seems to result in a glitchy screen more than a change in the actual sound, though.
In that case the bootloader is fine so programming one of the readily available firmware update files via MIDI can indeed solve the problem. But that is not due to a bad ISP but due to the fact that the sysex update file was compiled with the correct version of the compiler and the ISP loaded firmware was not.

I had read about incorrectly compiled firmware and tbh this was one of the first things I checked when I initially had issues with build number one. The hex files I use are definitely the correct size btw.

However I have got to the root of the issue after spending time this weekend debugging my gear…

The ribbon cable that connects my ISP to the adapter that plugs into the control board had a connectivity issue on one of the pins, i.e it only worked if the cable was at a certain angle which if it moved during flashing would, I suspect, cause the weird results I described. Long story short, replaced faulty ribbon cable and now everything works without issue.