Retro CPC Dongle – Part 18

Since my last post, I’ve been beavering away on the SPI interface between the Atmel supervisor chip and the FPGA. The SPI interface is almost ready to share, but not quite. In the meantime, I’ll share the little side project I’ve been working on, replacing the NAND raw flash with an eMMC chip on the CPC2.0 board.

I wrote about raw flash and the challenges of writing a flash translation later in part 16 of this series. After some research, I concluded that the eMMC interface looked exactly like the much more common SDCard interface, albeit that the interface can be run with an 8-bit width. SDCards are limited to 4 bits by the physical pin count. Taking a gamble I created a board to test this new eMMC chip. I created a fake SDCard!

This fake card allowed me to check very quickly if my assumptions were correct both at a hardware and a firmware level. I wanted to be sure that it was possible to interface the eMMC via 4 bits, rather than the full 8 bits and be sure the firmware instructions were the same between these two technologies.

The Atmel SAM4S chip has a hardware interface for SDCards. If the eMMC worked with the SDCard interface, I just needed to hook up the eMMC to the Atmel SAM4S chip using the built-in HSMCI interface. I could then use the libraries provided in the Atmel Software Framework to interface to the card. No effort required and definitely no flash translation layer required!

The first challenge on this build is that the BGA pitch is 0.5mm. You’ll recall from an earlier post that screen printing the solder paste under 0.5mm is difficult. Screen printing a 0.25mm BGA pad would be nearly impossible. To work around this problem, I created a paste mask with over-size 0.45mm holes at a 0.5mm pitch. I uploaded my design and contacted OSH Stencils to check that they could produce the proposed stencil with such fine tolerances. They were both quick and polite in their reply, confirming that they could produce such a stencil in stainless steel. They could produce a stencil with just 2mil between the holes! True to their word, the stencil arrived and didn’t fall apart as soon as I looked at it, as I had feared it might with such a thin mask.

The second issue I had is that the minimum feature that OSH Park can produce is 5mil / 0.127mm and their smallest via is 18mil / 0.4572mm. This means that there isn’t enough room between the BGA pads to insert a via, so I can’t easily get the signals routed out. There is 10mil of space between the BGA pads, assuming each pad is 10mil in diameter. This isn’t enough room to fit a track plus it’s associated clearance between the pads. The clearance + track + clearance is 15mil.

Luckily many of the pads are not connected (NC), so I just cut straight across them. Have a look at the PCB layout here and you can see, for example in the bottom left corner, I cut across several NC pads to escape the traces. The red colour is the top layer and the BGA pads. The white colour is the paste mask and doesn’t form part of the circuit. Note the clearance between the white circles. Due to good design, or just good luck, the critical pads that I needed to escape, such as D0-D3, are accessible without stomping over other critical pins such as power or control. It seemed possible to create a working board.

Just for completeness, I’ve posted the schematic here, but it’s pretty straight forward. There is nothing significant to the square through holes, these were intended to be debugging points if the SDCard access didn’t work out.

The first issue I had during the build was, once again, solder paste bleed. The paste mask holes were just too big. Take a look at the paste result here. Solder paste tends to spread once it’s been deposited, and with only a 0.05mm between the paste deposits, they all bled into each other into a sticky mess. I decided to scrap the stencil and use my blob-n-scrape method of depositing the paste. This involves running the back or side of a scalpel between and along the rows and columns of the BGA, removing paste a few blobs at a time until the paste is extremely thinly spread. It really doesn’t take much paste to secure these BGAs, so thinner paste is better. Keep scraping the paste off, wiping on a paper towel until it’s not spread across pads too much. A few bridges are OK, as surface tension will pull the paste into the balls of the BGA during reflow. Lining up the chip was hard as the outline was a bit too big, and the reference points are not close enough to the chip to highlight any misalignment. I got it about right, placed the 0.1uF cap and baked the board.

I was fully expecting this build to fail as it’s really pushing the boundaries of the minimum feature size of the PCB manufacturer. To my surprise, as soon as I pushed the finished device into my multi-card reader, it was recognised by the PC.

BINGO!

I guess that answers the question of whether it will work with an SDCard interface. Yes, it will. Obviously, the 4-bit interface is not an issue here.

Interestingly, I ran some performance benchmarks to see how it performs. I’ll start by describing the later runs, as this is likely to be typical of the performance of the device once it’s been in use for a while. Here are the Linux performance test results:

Standard performance to be expected from the 4-bit interface
Close up of the performance variation of later runs

What was really interesting was the first performance run. Take a look at this:

First benchmark run

The read performance isn’t particularly notable, except for its consistency. A pretty standard 25MB/s. Remember that would be 50MB/s if it were running in native 8-bit mode. What is super interesting is the write performance. It’s a nearly uniform 22MB/s until we get 50% through the test, then it drops off to its current performance level of 8MB/s or so. My best guess is that this is the flash translation layer at work in the eMMC. Around the 50% mark, we have written 4GB of data, which is the eMMC stated capacity. At which point, the flash translation layer would need to start reusing old blocks, this requires the erasure of an unused block, a copy of blocks still in use and only then, writing the new data. One way to prove this theory is to somehow execute the TRIM command on the device for each sector and then rerun the test.

Researching this possibility, I’ve drawn a blank as the internet experts tell me that TRIM isn’t available over USB media. I’ll continue to look into this, because the write performance would really make this worthwhile, giving nearly a 3x performance boost.

Anyway, this wraps up the post for today. Here are some shots of the build and test. I’ve shared the PCB on OSH Park here if anyone wants to look at the board or even if they wanted to order one (thank you, OSH Park). The eMMC chips are available from Mouser.

Completed boards from OSH Park (click for hires)
Surface mounted chip (click for hires)
In situ fake SDCard (click for hires)

Footnote: I frequently reference OSH Park and Osh Stencils because they are awesome and I want to ensure they continue to provide their excellent services to the likes of us hobbyists by keeping the work going their way. I am in no way affiliated with either organisation.

Look out for my next post, where I talk about my SPI dramas!

Advertisements

7 thoughts on “Retro CPC Dongle – Part 18

  1. Good to see I’m not the only one out there doing eMMC-related stuff! (here’s my own blog post on a non-PCB approach to a similar issue: https://ripitapart.com/2016/10/28/emmc-adventures-episode-1-building-my-own-64gb-memory-card-with-a-6-emmc-chip/ )

    I’ve played around with a larger-capacity version of the eMMC you’re using, the SDIN8DE2-16G. This line of eMMC does use an SLC cache, but I didn’t notice the slowdown you experienced when doing continuous full-drive write tests. It could be the cache running out or some other Flash management issue, but I suspect that your slowdown may be related to the number of flash dice in the eMMC module as well (likely just one given its 4GB capacity). I have a couple Kingston EMMC04G-S100 chips that max out at 10 MB/s write even after running TRIM.

    As for sending TRIM commands, I found that Windows 10 will issue a TRIM command across the whole eMMC when a Quick Format is issued (at least to NTFS)… but only if you use an SD slot that is listed as an ‘SDA Standard Compliant SD Host Controller’. I have an old laptop with such a ‘true’ SD card slot that allows me to TRIM my eMMCs this way. I’m trying my luck with an ExpressCard SD reader that hopefully provides such functionality as well, since it’s basically an external PCIe 1x bus – as long as it arrives in the mail!

    Cheers,
    Jason

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s