Roland DIF-AT

[Page under construction - as yet incomplete]

PCB photos, Pinouts, Pin header, Device operation, Connections between subsystems. Notes on firmware structure, Machine language monitor program, DFU, firmware extraction, firmware update script (python)

Roland's page on the DIF-AT

Roland publicity image

Brief outline -

I bought this device to repair. They are rare, and interesting. It would not respond any longer or be recognised by host hardware. (it runs in conjunction with host digital mixer / host music production device, translating digital audio formats in real time)

I damaged a lot of traces on the device and gave up on it. However, I learned how to micro-solder and became inspired to continue the repair with reverse engineering techniques. This is my first reverse engineering project, though I have worked on modding and repairing before.

Given the device was already non-responsive (and now damaged) -

Goals-

1. De-solder NOR Flash and read firmware.
2. Determine potential corruption of firmware.
3. Re-flash firmware onto new NOR flash (if good).
4. Determine operation / potential corruption of Xilinx CPLD and/or Alesis OTP? IC - read contents if possible.
5. Analyse firmware for anything interesting.
6. Determine and examine / analyse hardware architecture.
7. Repair traces, replace ICs. Test.
8. Collate information, share research and findings.

PCB Photos -

• 

  Main board

• 

  Cpu (not mcu!)

• 

  Main board, alt

• 

  SRAM + NOR Flash (512kb)

• 

  Custom Alesis chip OTP CPLD? GAL?

• 

  TDIF daughter board

• 

  5v power conditioning

• 

  Sync circuitry with optocouplers

• 

  Reset IC and switch

• 

  Xilinx CPLD with JTAG pads visible (pin 50, 81 silkscreen)

Device Overview

This is a complex device with a 16 bit CPU, Xilinx 95xx CPLD, Custom Alesis chip (Gate array, PAL, GAL, OTP CPLD?) SRAM, NOR flash 512kb, logic and switching for bus arbitration. BREQ Bus request is a very involved circuit. Also CE# Chip Enable NOR Flash is connected through a complicated muxing circuit. The Alesis custom IC handles the WE# Write Enable to the NOR Flash.

No info could be found on the Alesis chip, searching for the numerous IC markings revealed nothing.

The Device is quite old school. This was built for the early generation of ADAT/TDIF machines, still using physical tape. Thankfully a tape machine is not necessary for operation. The sync requirements of locking digital audio using analogue tape definitely adds complexity to this system.

Device has 2 buttons on the PCB: 1 - RESET, reset circuit and IC 2 - Launch monitor diagnostic mode.

A 50 pin header provides easy access to most address lines and relevant (to operation) CPU/RAM/Flash lines. This will be convenient to run a logic capture during boot and operation later. I beeped out the 50 pin connector - Many pins have multiple connections. Happily; the vias were not tented - this was a long endeavour even with continuity through the vias : ) Below, the findings and some general notes:

• 

  Header pins 1 - 16

• 

  Header pins 16 - 24

• 

  Header pins 15 to 38

• 

  Header pins 38 to 50

• 

  General notes about inferred operation

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 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 responding. It was fun, confusing and difficult to set up all these tools. I set most of them up on a Raspberry Pi as dedicated hacking server so I can connect remotely to the hot mess setup with my laptop, somewhere more comfortable : )

• 

  XC3SPROG id read

• 

  Pullup info from Xilinx

• 

  BlueTag correctly reads pins

• 

  OpenOCD and BlueTag (in BusPirate Mode)

BSDL Scan

After initial ID code read, I used a BSDL GUI to determine whether the CPLD was actually passing data throughput. Whilst easy to use when running, this tool took a while to set up (I mistakenly compiled it from source in Windows 7 32 bit - somehow missing the fact there there was a package release) After downloading the BSDL language file from Xilinx and setting up the tool with info from the Xilinx datasheet (super confusing naming convention, cells vs physical pins). Scanner could only run with this set up in Sample mode (OS not present nor running).

It was satisfying to see my logic probe light up on the outputs during BSDL scanning.

Xilinx CPLD confirmed working - big achievement!

At some point I will get a Xilinx Platform Cable to attempt to read the bitstream for archival purposes. However at this stage I'd had to get a few probes etc and didn't really want to get a Xilinx only device. I've had great luck with unlocked devices so far though, everything I've looked at has been open or level 1 : )

Viveris JTAG Boundary Scanner

Extract Firmware

I used a TL48 programmer with a 48pin TTSOP to read the NOR Flash firmware contents -

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.

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.

The strings are very interesting indeed. Not just a standard 'version' or 'release date' string - they are command strings!

As this device has no screen, a low level diagnostic routine is inferred from their discovery. Looking closely at the last string or two, I was worried that it might be corrupted as there are some missing letters in the string - (ADAT Sync port di onnected and Dectected rather than Detected).

T48 programmer settings and dump - note the very interesting strings!