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 further) -

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/CPLD

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 has to use vendor specific tools (Platform Cable USB)

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!)

[Only one device is visible in the JTAG chain, the Xilinx. The CPU, H8300H (Hitachi/Renesas) is not equipped with JTAG at all. Low level CPU operation is done through a bootloader mode]

I connected to the Xilinx XC95144 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 : )

It seems strange to me that, this is a 100 pin CPLD, and only 4 inputs and 4 outputs are used! (solely RBUS data, 8 channels L/R in/out). Counter output from H8300H goes to clock pin of the Xilinx, through an inverter.

• 

  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 Extest mode (OS not present nor running) toggling the input pins at a user defined frequency - means the corresponding output logic pulses accordingly.

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

Xilinx CPLD confirmed working - big achievement! (Not tested in actual operation) I'm 99% sure its fine after these tests.

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 -

At some point in the repair attempt, I heard a strange flapping sound from the NOR Flash as I moved the device around. ALL of the pins 25 - 48 had detached from the PCB with zero damage to the traces or pins. I surmise that this was the original failure point of the device - dry joints on the Flash chip.

After I desoldered the other half using hot air, I could proceed to read out the contents -

TL48 Programmer-

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!

Binwalk / Binvis -

I slowed down a bit here because I had no idea how to actually load the file I'd dumped to look at it. First I used Binwalk, which I think is more suited to SOC work. Anyway Binwalk was able to provide a nice image showing the entropy of the file - low entropy = low chance of corruption or encryption (or possibly I'm defining that the incorrect way around)

I also had a look at Binvis. Binvis makes for a stunning visual representation, regardless of anything else at all. I love it. It was fun to see the strings represented in coloured pixels. Also, very apparent to see in Binvis, are the banks. This firmware is banked and split. This is to facilitate DFU - the device can be firmware updated by the user while still maintaining stable OS. Then switch a flag to change/denote active bank.

This device has two firmware version strings visible in the firmware (at this point the strings are the only thing I've been able to see)

Appears it was already updated in the field to the last OS version (1.022) from I'm not sure if it then wipes the other bank? Possibly, because the other regions are written with FF. However it was still pretty confusing to navigate around later on; BRA from active code to 0xFF region. I'm still not sure: maybe the Alesis CPLD remaps certain memory addresses at run time?

Binwalk entropy image looking good - encouraging at least

BINVIS The little 'white line defined' area is where the pointer is viewing

Strings -

Alright we've heard enough about them; here is the list - strings -n 6 INTEL_HEX_DIF_AT_LH28F400BVE@TSOP48_byte_swapped.bin

mpTp**RolandDIF-AT**z :MONITOR Ver.1.00z mpVp DIF-AT system program  Ver 0.9800 H0123456789ABCDEF System Version = Check Sum = 0123456789ABCDEF Flash memory OK. Flash memory check error   RAM test OK.   RAM test NG.   RS-422 loopback test 1 OK.   RS-422 loopback test 1 NG.   RS-422 loopback test 2 OK.   RS-422 loopback test 2 NG. DA-88 sync loopback test 1 OK. DA-88 sync loopback test 1 NG. DA-88 sync   opback test 2 OK. DA-88 sync loopback test 2 NG.   ADAT sync loopback test 1 OK.   ADAT sync loopback test 1 NG.   ADAT sync loopback test 2 OK.   ADAT sync loopback test 2 NG.         RMDB Fs unstable.      Video sync in check NG.    NTSC video signal received.    PAL video signal received.     Video signal checked NG.    Different    sampling Clock.    Check the    sampling rate. ADAT Sync port    di  onnect. DA-88 Sync port disconnect. Dectecte tape      end.   Tape is write   pr 0ected. Tape Ejected. Unformat Tape. !"#$%&'()0123456789@ABCDEFGHIPQRSTUVWXY DIF-AT system program  Ver 1.022

I removed all the strings returned which are over n6 but not really strings - and - There are also two blank strings which the above table has optimised away. These seem to have a function, unclear at present.

You can see how, it does look like corruption in some of the strings - gaps in the text.

The **Roland xx looks like a boot banner and is called differently in the firmware. I'm sure that's why it has different start and stop markers. Ditto for the early Version string. Interestingly, the early Version is way at the other end of the addresses in the code. This adds to the DFU / Bank swap theory.

When I finally load the firmware (I still haven't at this point) I spend ages looking for what calls these strings. It is very difficult to navigate the firmware. Basically zero xrefs. One or two strings can be discovered, which have a different call system to the diagnostic strings (the ones I'm most interested in) especially because I have to repair so many subsystems.

I don't know at this point that these diagnostic strings are highly likely to be called by the Monitor Version 1.00, which is highly likely a Machine Language diagnostic tool which must operate over UART.

High Performance Embedded Workshop -

(that's right, I still haven't found Ghidra or Cutter yet)

High Performance Embedded Workshop

I downloaded HEW from Renesas, which still keeps this available online. Superannuated Software, total 1998 vibes. I love that look though! I managed to load the firmware into it, and yes, it appears to be recognised and loads in just fine. This is a big step, its the first time I'm looking at the disassembly, and it seems like its not badly corrupted (it loads it in) I enter the RAM addresses and sizes and mess about with it for a bit. . .

Ultimately, its not great for RE. It was probably good at the time for developing for the H8, but it's pretty hard to use for RE. I give it up.

There was actually some DOS software that I had a crack at too which apparently loaded H8 firmware but I never got it to open the file.