| General > General Technical Chat |
| Reverse Engineering a Flash Card for a vintage music synthesizer keyboard... |
| (1/2) > >> |
| STM32:
Hello guys, First of all, I'm not sure if this is the most appropriate place to ask this. Moderators, you may move the topic at will! Well, I've been trying to understand how an 8 Mbytes flash card for a vintage synthesizer keyboard (based on 4x 16 Mbit parallel NOR flash chips) is read/written by its target system (the keyboard) as I plan to design an expanded version. The schematic of the keyboard's main board shows 12 additional CS signals that are not used (NC) on the flash card, which indicates possibility for future expansion of the flash card. Each CS line corresponds to one flash IC, which makes the total flash memory 32 MBytes if all 16 CS signals are used. The keyboard activates only one flash at a time, depending on the program chosen, which means it can only address 2 MBytes of memory. From design and PCB perspective, there's no problem making a new flash with 16 chips (32 MBytes). However, the problem is how to make the keyboard access them? I have been working on this for several months now and here are my observations so far: The keyboard recognizes the flash by reading a 4-bytes header written to IC1 during initialization of card. In order to understand what's going on under the hood, I had to de-solder the flash, read it, solder it back to the board dozens of times. Because the approach was time consuming and risky for both of flash chips and PCB, I eventually designed a breakout board that has a receptacle connector (same as that on the keyboard's main board) and a ZIF connector that routs all signals to my Xeltek SP3000U programmer. I can now read/write any of the 4 flash ICs in the card in matter of moments without having to worry about soldering/de-soldering. First thing I have noticed is that the values written inside the binary are somehow arranged in reversed order. Not sure if this has anything to do with Endianness. For example, if you look at any ASCII value for a file named "File01" loaded into the flash (using the keyboard) the values are arranged like this in the binary file read from flash IC: iFel10. I have done a series of analyses on the flash loading it with variety of files in different sizes, then reading the binary back from IC1 in order to do comparison and find differences in the binary. As far as I can understand, IC1 has 3 chunks of bytes that tell the keyboard how many free bytes are still free or how much was used on all 4 chips, location of files, and if I'm not wrong, which CS to switch in order to locate the file in the IC that corresponds to that CS. To sum it up, IC1 is used to store info about the files loaded to any of the 4 chips, their locations, and the space they occupy. I believe the only possible way for me to expand this card is to design a system that emulates the nor flash so I can modify the chunk of bytes written to the flash during write accesses by keyboard so I can make keyboard switch the other CS signals that are not used originally by existing card. Reverse engineering and binary gurus, any input is highly appreciated. Please let me know if there's anything unclear or confusing above. At least, understanding the arrangement of data inside the binary file would help me a lot to understand the other chunks of bytes written by keyboard, what are they, and how they relate to the files stored, their locations, and how the keyboard calls them across the 4 chips. |
| amyk:
Since they're x16, if every 2 bytes are reversed, you need to swap D0-D7 and D8-D15. |
| STM32:
Yes, you were correct. It was Endianness. I used dd conv=swab to swab bytes and now the ASCII values are readable. I'm now trying to understand the chunks of bytes written to IC1 and see whether I can do something to modify the flash based on that. |
| DavidAlfa:
So you expect us to figure out without having any files to check? |
| NiHaoMike:
--- Quote from: STM32 on November 15, 2022, 11:46:17 am ---Well, I've been trying to understand how an 8 Mbytes flash card for a vintage synthesizer keyboard (based on 4x 16 Mbit parallel NOR flash chips) is read/written by its target system (the keyboard) as I plan to design an expanded version. The schematic of the keyboard's main board shows 12 additional CS signals that are not used (NC) on the flash card, which indicates possibility for future expansion of the flash card. Each CS line corresponds to one flash IC, which makes the total flash memory 32 MBytes if all 16 CS signals are used. The keyboard activates only one flash at a time, depending on the program chosen, which means it can only address 2 MBytes of memory. From design and PCB perspective, there's no problem making a new flash with 16 chips (32 MBytes). --- End quote --- Far more compact would be to OR the CS signals (AND if active low) and use a priority encoder to control additional address lines on a larger Flash chip. |
| Navigation |
| Message Index |
| Next page |