Fixing Abnormal Behavior in FC1307A-Based SD-to-IDE Conversion Boards

Introduction

This is a story about SD-CF adapters and SD-IDE conversion boards equipped with the FC1307A, which seem to have appeared a few years ago.

As the shape suggests, these are devices for using SD or MicroSD cards in place of IDE hard drives. The 40-pin types are printed with model numbers like SD35VC0 and TF35VA0, while 44-pin SD types have no markings, and the MicroSD version exists with model number TF25VA0.

Logically, these are almost equivalent to an "SD-CF adapter + CF-IDE adapter" combo. However, they include power circuits and passive components that are omitted in simple SD-CF adapters, and feature push-pull card slots. They seem more electrically stable and have a structure that makes card insertion/removal easier compared to combining a CF-IDE converter with an SD-CF adapter.

...However, there was one fatal problem.

What is the problem?

Depending on the situation, the contents of the first sector read during power-on would become corrupted, leading to failure in normal operation. While the data on the SD card itself isn't actually destroyed, from the host's perspective, it looks like data corruption because it cannot read back the data exactly as it was written.
When integrated into Linux-based equipment, musical instruments using proprietary formats, or computers with partition table formats different from PC/AT, this bug is triggered, causing issues like failing to boot.

Now, several methods were devised to work around this issue:

• Power on without a card inserted, then insert the card and reset.
• Create a card that mimics the PC/AT partition table.

...and so on.
But ideally, you'd want it to work correctly from the moment you power it on with any card inserted, regardless of the environment and without any special procedures, right?

Investigation

It is known that several versions of the FC1307A firmware exist, including those for SD-IDE and SD-CF, and there are slight differences in behavior depending on the version.
I disassembled one, removed the SPI Flash, and attempted to dump its contents.
For methods to read/write SPI Flash, you can find simple ways by searching for "SPI Flash RaspberryPi". Also, it was possible to read/write without removing it from the board using an SOP8 IC clip.

List of confirmed FC1307A firmware:

ATA Device Name	Revision	Internal Firmware String	Flash Model/Capacity	Known Products	48-bit LBA Support
SINTECHI HighSpeed SD to CF Adapter V1.0	Rev 1.2	FC-1307 2012_07_19-BANK CF_V1.5B15	Pm25LD512 512kbit	SD35VC0 (yellow silk), Henkan Meijin SD-IDE 44-pin type (yellow silk)
FC-1307 SD to CF Adapter V1.3	Rev 1.3	FC-1307 2012_10_29-BANK CF_V1.5B17	FH25VQ40 4Mbit	TF-CF Adapter (red)
FC-1307 SD to CF Adapter V1.4	Rev 1.4	FC-1307 2012_12_20-BANK CF_V1.5B18	BY25D40A 4Mbit	SD-IDE adapter (Reported by TD-Linux), SD35VC0 (white silk), 44-pin type (white silk), TF25VA0, 1.8" ZIF type 2TF2CEVA1
FC-1307 SD to CF Adapter V1.5	Rev 1.5	FC-1307 2015_10_16-BANK CF_V1.5B17	FH25VQ40 4Mbit	SD-CF Adapter (black), Sanwa Supply ADR-SDCF1
iFlash-Platform iPod Adapters	iFlash85	FC-1307 2015_03_05-BANK CF_V0.10 CM	Unknown	imCort Design, iFlash Quad	○
SD to CF Adapter 3rd Gen	Rev 3.72	FC-1307 2014_09_30-BANK CF_V3.72 CM	GD25Q512 512kbit	Sanwa Supply ADR-SDCF2	○

(Revised on 6/24: Flash capacity and known products.)
(Added products on 7/23, 1/14, 2/20, 6/16.)
It appears that both 512kbit and 4Mbit Flash only use the first 48KB (384kbit).

Additionally, there is something called "Misty Ghost" that uses the FC1307A but is intended for removable use; however, since having a removable flag is inconvenient for my purposes, I will not consider it here.

After verifying several environments on hand, I confirmed that the Rev 1.5 version does not suffer from the aforementioned issue. Therefore, I came up with the barbaric act of replacing the problematic firmware with the more convenient one.

As of this writing, the following products had integrated firmware that could not be dumped. (25/06/16: Information organized as many corrections were needed.)

• iFlash (SD-CF, SD-ZIF, 2SD-ZIF, 4TF-ZIF types)
  These are equipped with the FC1307A, but the ATA device names appear to be proprietary. The area around the chip is encased in resin, so disassembling it would likely require destructive methods to read the firmware.
• The SD-CF type appeared on 2012/12/26
• The Dual type appeared on 2015/09/18
  Since these existed before 2015/10/16 (the date of FC1307A Rev 1.5), unless they traveled back in time, it is likely that iFlash is based on a version of the FC1307A firmware older than Rev 1.5.
• iFlash-SD v7/iFlash72: There are reports suggesting the first-sector issue exists. No dump reports.
• iFlash85: This firmware supports 48-bit LBA when cards larger than 137GB are inserted and does not suffer from first-sector corruption. However, it has a serious bug where parts of the Identify information are overwritten with strings, likely because someone who doesn't understand null terminators messed with the revision/model name strings.
• imCort Design (2TF-ZIF type)
  An adapter likely designed for the same purpose as iFlash.
  The release date is unknown, but according to Rockbox chat logs, "it's basically the same as iFlash, broken everything." Later, I received information that it was identical to the one in the iFlash Quad. Thank you very much for the hard work of verifying it by removing the resin. (Added on 2/20)
  Since this one is not covered in resin and uses an SOP8 package, making access via an IC clip easy, reading it or fixing bugs should be relatively straightforward.
• According to information from Arqam, it seems only Rev 1.5 lacks the JBOD function. Since I only own single-card adapters, I have not verified this. (Added 7/16, updated 1/14)
• For Sanwa Supply adapters, the specifications state that the ADR-SDCF1 supports up to 128GB, while the ADR-SDCF1N and ADR-SDCF2 support up to 512GB. This is likely because the former uses Rev 1.5 and the latter uses Rev 3.72. It is a bit strange that Rev 3.72 has an earlier date, though. (Thanks to "Yellow Bok Choy" for the information!)

Preliminary Test

As a first step, I tried loading the Rev 1.5 firmware onto a Rev 1.3 TF-CF adapter (red). It worked without any issues.

As you can see from the photo, the 3.3V regulator inside the CF card-type adapter is omitted, so make sure to supply 3.3V to the card.

Implementation

Initially, I intended to just flash the Rev 1.5 firmware onto the SD-IDE adapter and call it a day, but it didn't work. It remained silent even after power-on, and the host didn't see any response.
Why, even though they use the same chip... That shouldn't be the case... If that's how it is, I'll trace the circuit and modify it to match the SD-CF state.
As a result of my investigation, I decided to make the following changes to the board:

• Flash the Rev 1.5 firmware to the SPI Flash on the board.
• The following pins are pulled down to GND, so cut the patterns:
  • FC1307A 9pin (IOP0)
  • FC1307A 13pin (IOP1)
• Remove U3 (STCA1) and pull down the 6-pin land = FC1307A 14pin (IOP2) to GND

(Added on 5/28) While performing the modifications in reverse order, I found that removing U3 is unnecessary.

Actually, I had started this work in early 2022 and left it for a full two years, but since I finally obtained the pinout information, I was able to settle the score after two years.
Even just being able to distinguish whether a pin is a power pin or an IO pin significantly changes the difficulty of analysis.

Now, I carefully check the pattern cuts with a magnifying glass... OK, power on.
The Access LED flashed for a moment! It worked!!

The SD-CF Rev 1.5 firmware is now running on the SD-IDE (SD35VC0) board.
It looks like I won't have to suffer from abnormal behavior anymore.

If I applied a patch to the firmware to ignore the state of the IO ports, I wouldn't need to cut the patterns, but I'll leave that for another time... Actually, there's no point in hiding it anymore, so I'll write it down. It seems that for any firmware, you can change 03CFh from FE -> 00. Please make sure the checksum matches. Wait, does that mean the pattern cutting was a waste!? No, no—it's through this kind of steady verification that we are where we are today. Hacks aren't built in a day.

FAQ

• Where can I find the Rev 1.5 firmware?
  • First, I recommend reading this article to the end.
  • If you cannot find it after searching, you can obtain it by purchasing one of the products listed in the "Confirmed Products" section, disassembling it, and extracting the ROM.
  • If you find a version or a product not listed here, I would be happy if you could leave a comment.
• The access lamp on my device glows dimly or stays on constantly?
  • If the host-side access lamp is pulled up with 5V, while the 39th pin in the SD-IDE adapter is pulled up with 3.3V, the LED may light up due to the 1.7V difference.
    • Source the + side of the access lamp from 3.3V.
    • Replace the access lamp with an LED with a larger Vf (white, blue, or purple).
    • Insert an LED or diode in series with the 39th pin on the SD-IDE board.
    • Pull up the 39th pin to 5V on the SD-IDE board.
      • This method is not recommended because if you insert an undersized resistor because the dim glow doesn't stop, excessive current will flow into the IC and damage it. (Added on 7/8.)
  • These are potential solutions. Please respond appropriately by looking at the relationship with the host-side circuit.
• It seems to be recognized, but the data is corrupted...
  • Hosts prior to UDMA66 use 5V as the reference voltage, but since the FC1307A is driven by 3.3V, I have confirmed cases where bits are dropped depending on the chipset.
  • As a symptomatic treatment, solving this by slightly increasing the voltage (e.g., by replacing the regulator on the SD-IDE board with one that provides around 3.5V, or by inserting a diode in series with the GND terminal of the regulator) may work.
    • I have confirmed this resolves the issue on the Libretto SS1000.

Souvenirs

Thank you for visiting today.
Please take this FC1307A KiCAD library as a souvenir.
FC-1307A.lib

Extra: Creating Modified Firmware

Now that we've achieved a generally convenient state and things have settled down, some of you might be looking to use this for specific models with peculiar behaviors.
Adam K, who collected firmware on the Internet Archive, shared a case where he modified the model name of the SD-IDE firmware to support the Toshiba T5200, which only recognizes certain HDD models.
https://www.vogons.org/viewtopic.php?p=1018823#p1018823
Inspired by this, I committed a further barbaric act by attempting to create firmware that avoids cylinder count calculation overflows and the resulting hangs that occur on PC-98 series models with internal IDE disk capacity limits of 543MB and 4,351MB.
As a result, I found that by setting the native Head/Sector values to 8/17—the values hard-coded by these models—the boot-time overflow can be avoided regardless of the capacity of the inserted SD card.

Firmware image target for patching:
FC-1307 2015_10_16-BANK CF_V1.5B17.bin 65,536byte CRC32=2F99F86C

Patch for the relevant models. Apply to the above firmware using the git apply command.

diff --git a/FC1307A_1.5.bin b/FC1307A_1.5.bin
index 7e3b8536b7735757a52cbd40ec9b17df5cae8fb2..9d9c20ef5900d0cfb801225aafda2787e6e616b0 100755
GIT binary patch
delta 84
zcmZo@U}<Pz+0dZP$HBnB;J_pZBtc;EMs1PFi?r()88$2G2nq}MI+vtoD+D;}T3Q$w
lC<MDqcCz2Y6r{JwVUjQ_M@4O!;O6PU={ihI&lfc`002?}7R~?w

delta 71
zcmZo@U}<Pz+0dZPC&0kK;J{=LBtc;EMs1PFi?r()SvD)`2ntVbv6r0eZNHhRN@bJ7
YBw<#8irO;!&C`R^b(qdPTh!110Eb=`NB{r;

(Updated 6/18: Since I found the storage location for the H/S values used in cylinder value division, I corrected the patch so that the correct cylinder value is calculated. This allows cards under 4GB to be recognized with the correct capacity.)
(Added 2/3: I attempted to correctly reflect the Current H/S values and set the maximum capacity to 4351MB. This allows it to work on EPSON98 compatible machines as well. Since I am rewriting the program by disassembling it, it has become difficult to publish openly... Therefore, the new patch is posted here.)
(Added 4/23: I rewrote the entire cylinder count calculation routine to calculate the Native and Current cylinder values individually and capped them at 65535. Additionally, to make it work on early EPSON notebook models that were reported to hang when connecting an HDD of about 2GB or larger, I added a mechanism that identifies when H=4 is specified and treats it as H=1 S=68 to allow recognition up to 2175MB. The new patch is here.)

Example using a 32GB MicroSD card:

If you have read this section this far, you probably know how to safely access areas exceeding 543MB and 4,351MB, and I will not explain it here as it would deviate from the main topic.
The C/H/S values reported by the adapter may be incorrect, which could cause issues with software that utilizes them... or so it was, but this has been resolved in the latest patch by the barbaric act of rewriting the entire C/H/S calculation routine.

Use the modified firmware at your own risk. While reports of success are welcome, the author assumes no responsibility for data loss or any other events that may occur as a result of its use.

References and Resources

Troubleshooting Reports

https://www.vogons.org/viewtopic.php?t=76871
https://www.vogons.org/viewtopic.php?t=62397
48-bit LBA related
https://www.reddit.com/r/ps2/comments/hdas2g/opl_with_sd_mod_400gb_microsd_card_issue/
https://www.reddit.com/r/ipod/comments/1h5ekpj/has_anyone_successfully_extracted_firmware_from/

Software-based Solutions

https://www7b.biglobe.ne.jp/~marimo9821/hduty/conv98at.html
Mentioned as a "specific SD-IDE converter," with countermeasures implemented.
Thank you for featuring this article.

Firmware, Schematics, and Documentation

https://archive.org/details/sd2ide_fc1307a_fw
Contains ROM images for Rev 1.2, Rev 1.3, Rev 1.4, and Rev 1.5, as well as the SD-CF adapter schematic.
Thank you for featuring this article.

http://www.kwanghua.com.cn/cn/product_view.aspx?id=144&classId=68&pId=0
The FC1307A catalog (PDF) is available for download.