83
edits
Changes
Jump to navigation
Jump to search
m
Below in In the image below are the settings needed for a good read. The NOR flash is 16 bit wide, but the CPU is reading it in 8 bit mode (8 bit mode pin is tied low). SHARP LH28F400BVE Parallel NOR Flash 512kb. The chip is from the late 1990s as the device is also, turn of the century 2000s.
→JTAG/Programming/Firmware
</gallery>
== JTAG/Programming/Firmware == The device has two levels of firmware: NOR Flash and CPLD bitstream. The Xilinx is an older model XC95144 which is programmed over JTAG. However, due to the architecture, bitstream cannot be read out over JTAG (even if unlocked). It still seems strange to me that, this is a 100 pin CPLD, and only 4 inputs and 4 outputs are used! (RBUS data solely, 8 channels L/R).
Perhaps Roland just had a load of these in house already and it was cheaper to use them than get a smaller device. Or maybe it was the only suitable device in that range?
JTAG pads are exposed on the PCB as seen in the image above. I could connect to these to read the CPLD. Pretty soon they were pulled off the board, and I had to solder a pin to the leg temporarily to continue reading data. (before I discovered the tiny IC clips!) I connected using Bluetag, OpenOCD and XC3SPROG (open source Xilinx CLI) and was eventually able to read back ID codes and find IR Len etc. I was happy it was still alive!
I used a TL48 programmer with a 48pin TTSOP to read the NOR Flash firmware contents -
Although the strings are legible here, this is because the T48 is re-arranging the byte order automatically. The byte order must be swapped (little endian) in order to disassemble the firmware. I found this out after nonsensical strings were seen, without swapping byte order. I tried some 8 bit reads, but this garbled the strings in the T48. It was clear 16 bit wide was correct, but then byte order needed changing. I used a python script to swap the byte order of the entire dumped firmware file.
