Skip to main content

Problem With Accuphase DC-37 USB

So my Accuphase DC-37's USB input was damaged a while back. It was broken, but it's fixed now.

Cannot remember what the exact message was, but neither Windows nor Linux can detect the Accuphase DC-37's USB input. The Snakeoil OS logs returns an error message with the error code of -110. 

So what have I done to damage the USB port?

On the day, I had a problem with my PS Audio P5 - it refused to turn ON. To try and get the P5 working again I had to power on/off several equipment multiple times. By the time the P5 is working, the Accuphase DC-37's USB port is dead. 

In the Linux world the code -110 means an I/O READ error; but what is the problem, and the cause?

A colleague of mine (Steve) has kindly helped me out on this matter. He has diagnosed the problem, fixed the USB and modified the board to prevent this from happening again. Here's a review of his findings, note that as I'm not a tech, everything is likely lost in translation!

Credit first has to go to Doncentric (who did fantastic work on my KillerDAC) for identifying the USB receiver chip of the Accuphase DC-37.

It is a Bravo SA9227 USB receiver, pictured below:

You can buy the chip directly and replace it if you are certain it's the receiver chip problem. I opted for this solution instead, a DAC with the Bravo receiver chip.

Thought it was a good idea at the time as I can salvage the metal case in the future for something else. I'm calling this the sacrificial DAC. :)

Glad I chose the latter, because replacing the Sa9227 receiver did not fix the fault on my DC-37. It is still returning the -110 error after the 9277 is replaced with the chip from the sacrificial DAC.

After some discussion with Steve, he postulates the problem could be the EEPROM chip behind the Bravo.

This comment clicked instantly because I finally understood the context of the I/O read error - the Barvo chip must have encountered a problem when it's trying to read data off off some storage, and that storage could be this EEPROM.

And thus Steve went ahead and replaced the EEPROM of my Accuphase with the EEPROM from the sacrificial DAC.

And viola, the USB input is working again, correctly detected by Snakeoil OS as a USB 2.0 async audio device, and capable of playing back PCM and DoP as before.


The hypothesis of a corrupted EEPROM chip is hence proven.

Obviously with a different EEPROM fitted this DC-37 is no longer detected as an Accuphase DAC.

# aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: Audio [HD USB Audio], device 0: USB Audio [USB Audio]
  Subdevices: 0/1
  Subdevice #0: subdevice #0
card 0: Audio [HD USB Audio], device 1: USB Audio [USB Audio #1]
  Subdevices: 1/1
  Subdevice #0: subdevice #0

# dmesg|grep usb|tail -n 2
[    1.134492] input: XENRAN Audio HD USB Audio as /devices/pci0000:00/0000:00:1d.7/usb1/1-8/1-8:1.0/0003:262A:9227.0001/input/input6
[    1.134758] hid-generic 0003:262A:9227.0001: input,hidraw0: USB HID v1.00 Device [XENRAN Audio HD USB Audio] on usb-0000:00:1d.7-8/input0

Functionality wise though I don't think there is a difference. If you worry about this you can always pull the firmware off a working Accuphase, and flash your unit with that copy. In fact, if you are a DC-37 user, investigate the feasibility (and legality), and back up this firmware as a precaution (the reason will be explained overleaf).

For now I'm not interested in 'rolling back'. I wanted to find out if a different Bravo firmware can change the behaviour of this DAC.

In the past the DC-37 has difficulties switching between 192 kHz and DSD materials - usually static noise will be played instead. I'm hoping this can somehow be fixed with a different firmware (doubt it will though). (Update: 10 Jan 2018] So far I have experienced 0 issues when switching between different formats: DSD, 192, 88.2, 48, 96, 44.1. Everything play fine now when I switch files with a different res. Can't say with certainty this is fixed by the EEPROM firmware, or the Bravo chip though)

Also, the specifications of the SA9227 stated it supports with native DSD (88.2 kHz @ 32 bits). Never got this to work before, and was was hoping the firmware of the sacrificial DAC will magically unlock this mystical native DSD. Unfortunately at this point in time don't really have a lot of time to test anything now.

Comparing the firmware dumps from the 2 EEPROMs - the firmware from Accuphase has blocks of nulls. A clear sign corruption has taken place.

So how did the EEPROM get corrupted? Paraphrasing what Steve told me:

Accuphase left the write PIN of the EEPROM permanently on.

In layman speak this means the firmware on the EEPROM is not write protected. At all.

The word EEPROM is short for Electrically Erasable Programmable Read Only Memory. i.e. this chip is supposed to be in read only mode most of the time.

In other words, there is no write protection on this USB firmware. On a stock DC-37, it's USB firmware can be erased anytime, and any unintended erasure will result in corruption. (Note my DC-37 is one of the first, if not the first unit for sale. Later editions of DC-37 may not have this problem). You can think of EEPROM as a computer BIOS - if the BIOS is corrupted the computer cannot boot. It's the same idea here, for reasons unknown Accuphase made an unfortunate decision to make this chip erasable. Perhaps this is required for Windows? Too bad this decision has a disastrous consequence when operating this DAC in a Linux OS. 

What could trigger the corruption? Simple tasks like remove/insert the USB cable, turn the DAC ON/OFF, or reset a computer. Do any of this in quick succession, and you increase the risks of corruption. If you perform any task that will cause the Bravo chip to start reading the EEPROM multiple times in quick succession, you are incurring a high risk of corrupting the firmware. A simple operation like this is enough to kill it.

The corrupted firmware is the reason why a DC-37 will no longer be recognised as a USB 2.0 asynchronous DAC.

What I did before - powering multiple times on/off at a very high rate trying to get PS Audio P5 to power up - is the reason why my DAC's USB input went dead.

So, the morale of the story is - DO everything slowly. Treat the DAC with more respect, wait a few seconds when performing any operation. It' s not a good idea to power cycle the DAC, or reset the computer when the DAC is off.

Another problem with the Accuphase DAC is the Bravo chip is still active even when you physically turn off the DAC's power switch, or disconnect the power cord. You think that'd be OK, unfortunately not.

The Bravo SA9227 chip is powered by the USB's 5V power. Meaning as long as you connect the USB cable to this DAC, the USB receiver is powered, and thus still working. Yes, the receiver is still functioning even when the DAC is not powered by the mains

You have to take my word for this, do not even attempt to verify this on your own DC-37. Most USB DACs are powered from the USB 5 V power alone, so you can say that's not unexpected. However, this plus no WRITE protection becomes deadly combination for the DC-37.

Now you know. If Snakeoil OS cannot detect your Accuphase DC-37 DAC, and the error code is -110, it's likely you have a corrupted EEPROM. This is why it's handy if you have already backed up the firmware - you can easily restore if it ever gets corrupted.

Not entirely aware of just how many people have a malfunctioned USB port on their Accuphase DC-37. I'm aware of at least 3 first generation DC-37s with dead USB one way or another.

There is a more permanent solution though if you're uncomfortable with leaving the EEPROM in permanent RW mode. And that solution is to lift the WRITE leg of the EEPROM and turn that chip into READ ONLY mode - something Accuphase should have in the first place.

This mod means the Bravo chip will lose the capability of writing to the chip, thereby removing any chance of corruption down to 0%. This has its downsides though, we aren't certain why the firmware is writable. Disabling this 'feature' may have unintended repercussions - e.g. if this DAC is firmware upgradable this mod may potentially make it harder to upgrade.

Steve kindly performed this mod on my DAC, and I'm confident to say my DC-37 will not suffer the same affliction a second time.

So to summarise, the first generation DC-37:

  1. The EEPROM behind the USB receiver chip is erasable
  2. USB receiver (Bravo) is always powered by USB cable. So powering off the DC-37 from the mains will not power off the USB input

Combined, under rare conditions you can corrupt the USB receiver EEPROM. The solution:

  1. Lift the WRITE OK leg, and set the EEPROM permanently on READ ONLY mode.

Please share in the comment below if you have a DC-37 with a malfunctioning USB input, or know anybody who has one. Hopefully Accuphase has already addressed this in the later revisions. And if you have a problematic USB port, here's the fix, and how to prevent it from happening again.

Comments

Evgeny (not verified) Sun, 06/05/2018 - 14:02

Thanks you very much! I had the same issue with Accuphase DC-37 and your guide helped us to get the device back to work!

Clark (not verified) Tue, 09/11/2021 - 10:07

My device has the same problem. What model of EEPROM is replaced? Thank you.

Eugene (not verified) Sun, 16/01/2022 - 22:17

In reply to by Clark (not verified)

Hi, Agent Kith. My name is Eugene and I think I have th same problem with DC-37 USB port. Windows cannot identify it, says "the USB device is not working proper" or something like this (please, exuse me for my english). Please, can you kindly help me - how can I reflash the usb port? I’m really stressed now, don’t know what to do…. Please help!

Thank you.

agent_kith Mon, 17/01/2022 - 07:37

In reply to by Eugene (not verified)

You need to reflash the EEPROM on your DAC. This is a electronic component inside the DAC and require a technician with specialist tools. Or you can replace the EEPROM with a working one meant for the Bravo chip.

You can check around your area and see if any audio technicians with the ability to do this. Send them this article for reference.

Add new comment

Restricted HTML

  • Allowed HTML tags: <a href hreflang> <em> <strong> <cite> <blockquote cite> <code> <ul type> <ol start type> <li> <dl> <dt> <dd> <h2 id> <h3 id> <h4 id> <h5 id> <h6 id>
  • Lines and paragraphs break automatically.
  • Web page addresses and email addresses turn into links automatically.

Contents