Recovery from onboard Flash ROM(s) on my synthesizer

[testtube44]

I have here a Roland FA-08 synthesizer keyboard, which has been factory reset. The company told me that all of the custom leads/sounds are gone forever, but I've decided to dig into its guts, and lookup the chips to find which ones are ROM. I have this narrowed-down to 4 chips, and I found the data-sheet for both http://www.cypress.com/file/177976/download (both are in the same chipset).
I don't know if it's possible to recover data from these, and would like to know if this is viable.
The chips in question are;
S29GL01GS10TFI020
S29GL128S90TFI020

Let me know if you need any board pics.
Any help is appreciated;
Thank you!

[T3sl4co1l]

Viable, perhaps.  Depends if the factory reset actually wipes the chips, or just unlinks the new data.  Maybe they're even using a file system and the files were literally deleted -- and can be undeleted with a suitable tool.

Technically, even if the chips were wiped, there might be a tiny shred of hope left; but that's heroic effort, in the realm of decapping ICs and skys-the-limit reverse engineering.

Otherwise, if it's nothing obvious, just a bunch of data thrown in a chip, then, sure, it might be viable to read the data -- but what good is it?  Can you recognize the bit patterns of the data you're looking for?  Do you know what headers or links are necessary to hook it into the rest of the program?

All problems in data recovery and preservation are essentially solutions to special cases of the general underlying problem: how to understand data.  A physical interface is required (in this case, you've identified a few chips).  The encoding is required (what if it's stored encrypted?).  And the ultimate meaning of the data itself must be understood (is it composed of pointers from here to there, as some kind of file system? Is it a flat array of sequencer data?  What format does the sequencer read?  Is it streamed out verbatim into the synth controller, or decoded further, first?).

So, these problems may be trivial, or relatively so, but they can also be exponentially intractable, or completely impossible (as in the case of completely corrupted data).  "Viable" may not be the most appropriate word in this context.

Tim

[amyk]

That looks like NOR flash, so at least you won't have to deal with the additional complication of an FTL. However, it also means having an actual filesystem is unlikely, and a "factory reset" may actually erase a bunch of blocks instead of just marking a file as deleted.

The only way to find out is to do a bunch of experimentation; but, before making any writes, do a full and verified dump of those ICs. Then program your own sounds into it, dump again, compare, factory reset again, compare again, etc. It's not really difficult, just tedious. Depending on the board layout, you might want to socket the ICs since you'll be comparing many times.

[testtube44]

Yes I still have this problem. I don't know if this is within the realm of my capability, how difficult would this be to learn how all this works and go about doing it?

[testtube44]

And how do I make this post relevant again?

[hamster_nz]

Yes I still have this problem. I don't know if this is within the realm of my capability, how difficult would this be to learn how all this works and go about doing it?

Not wanting to be rude, but if you don't know that this is in your capability, then it most probably isn't. The task will only get a lot more complex as you learn about it, not simpler.

There is a small chance that you might discover a debug port or serial port that allows easy access to the contents of the storage, but that would be by luck, and nobody is sure if the data is still in the chips anyway. It might be a lot of learning for zero chance of success.

The best hope is one of the designers of the hardware stumbles onto this thread and gives you some of their insight.

[macboy]

Yes I still have this problem. I don't know if this is within the realm of my capability, how difficult would this be to learn how all this works and go about doing it?

Not wanting to be rude, but if you don't know that this is in your capability, then it most probably isn't. The task will only get a lot more complex as you learn about it, not simpler.

I completely agree. The OP is probably still in the "I don't know how much I don't know" stage of the learning process around this. At this stage, one doesn't even know what questions to ask.

Reading the NOR FLASH memories is possible. I have some experience working with these in products, and one thing I know is that there is always an easy-to-use full-chip erase command. It is reasonable that the factory reset would erase the FLASH then initialize some data structures in them, in preparation for storing new sound samples.

The first step is to read the FLASH chips to see if there is any worthwhile data in there. The large number of pins (56), fine pin pitch (0.5 mm) and unique package (generally used only for memory devices) make this a challenge. The process of dumping the FLASH likely means: desoldering the chip from the keyboard, soldering it to some TSOP-DIP interposer board, or better, using a socket adapter like this* (only an example, not a recommendation), and making connection to a reading device from there. The "reading device" would be a universal programmer with at least 56 pins ($$$) or a DIY device. Cheap programmers like TL866 have only 40 pins. An Arduino mega2560 has enough I/O pins to be able to interface with the device, and reading FLASH is really easy compared to writing/programming. The software is not difficult to write for an experienced person, but not trivial. The S/W just needs to ensure the device is in read-array mode, then put successive addresses onto the address pins, read the data, and spew it to the serial port in some readable format (I'd choose to use intel HEX file format directly). After the dump, the chip can be soldered back onto the keyboard PCB. There is a risk of damaging the PCB in the keyboard during the desoldering/soldering process and rendering it unusable.

If the FLASH isn't empty but appears to have data in it, then you'll need to figure out a way to interpret the data as audio. This could be as easy as interpreting the entire file as a 16 bit (or 8 bit or 24 bit??) PCM audio file and opening it in some audio editing software, looking/listening for your lost samples.

[Peacefrog]

Per the other comments in this thread, you'd unfortunately have a terrifically small likelihood of success here even if you could read the flash data - those blocks could be gone forever, which you'd only find out after desoldering the flash and figuring out what's laid down.

If it's really the custom sounds you lost, it'd honestly be quicker to reprogram them (assuming they're your own patches).

[fzabkar]

This reader supports both devices:

https://www.embeddedcomputers.net/products/FlashcatUSB/