A little continuation from my 4PM problem, got a question about the processor. Even numbered patches from 2 to 18 are not loading when I load the standard bank. This only happens on this particular processor, I swapped it into an XT I just finished so it is in a different control board than the 4PM. Is this fixable or have I done something to the processor?
Weird. Does it apply only to patches 1-16 (the ones stored on the processor - in which case it could simply be a case of memory corruption), or does it also apply to patches >= 17?
You’re right, the problem ends at patch #16. It is only even-numbered patches that are affected. I have loaded new firmware (0.98 in this case) and that did not fix the problem. 0.98 works in my other 6 Shruthis with no problems so far.
I think the eeprom section of the 644p got corrupted… How did the patches got loaded there in the first place?
I don’t know. It worked for a little while but at some point while I was trying to figure out what was wrong with the 4PM, I found Junon in those patches. I didn’t put them there, it just happened. I decided to try changing those to the init patch and then re-load the firmware, but those patches remained as init.
I’m guessing I shorted something, although it is possible to modify those patches and save them. Odd.
Did you do any sysex transfer? from/to this unit?
Just the firmware update. Same firmware update I did to all of the others. Problem is, I can’t remember exactly what I did that caused the problem. It could’ve just happened or it could’ve happened after one of the firmware updates. I wasn’t expecting anything like this to happen so I wasn’t watching for it.
Olivier, just wondering if you have any further insight on this or should I just order another processor?
It’s not the processor but the patch storage eeprom you need to change.
AT24C128B or 24LC128I/P
> It’s not the processor but the patch storage eeprom you need to change.
Wrong, patches 1-16, which are the problem here ; are stored on the processor.
> Olivier, just wondering if you have any further insight on this or should I just order another processor?
I’m pretty sure that this looks like a botched SysEx bank transfer - due to an invalid transfer rate. It would go like this: data for patch 1 is sent. Shruthi receives and writes on internal eeprom. It takes too long and when the write is done, the beginning of patch 2 is missed, so it just ignores the data until the beginning of patch 3. Patch 3 is received correctly, saved to internal eeprom, and when the write is over, the beginning of patch 4 is missed. And so on…
Only patches 1-16 would have been affected because patches 16-464 are stored on the external eeprom which has faster writes.
>Wrong, patches 1-16, which are the problem here ; are stored on the processor.
Didn’t know that. Is that spare space that can’t be used by program code?
The processor has a built-in 2k eeprom. This is different from program (flash) memory. Historically, the Shruthi stored only 16 patches, in this 2k area. Later, I added an external I2C eeprom but kept the habit of storing the first patches internally.
In hindsight, I should have kept the 2k internal eeprom for system settings, and stored all the patches on the external chip.
> I’m pretty sure that this looks like a botched SysEx bank transfer…
In the past week I have updated the firmware and over 400 patches on 7 Shruthis and this was the only one to have a problem. I even tried this processor in two different control boards. I can easily fool with the transfer rate and see what happens 'though.
I tried loading the sysex file for 0.97 using the C6 tool and a delay of 200ms (I usually use 250), no difference.
200 ms might be too short indeed. try 400ms.
Ok. 250 has worked so far.
Tried 400ms, no difference, still doesn’t work.
Okay… Then the chip’s eeprom area is probably corrupted - strange that it’s only affecting every second patch though. You confirm you cannot save anything there?
I tried saving other patches into the even and odd-numbered spots and saving the init patch into a few as well. That works fine, but it seems it’s not just every second patch, it’s all of the first 16 patches. So, none of the first 16 patches will load from an external source, either from a patch librarian or as part of the firmware update.