It’s been a while since my last post, so I thought it about time I provided an update. I’ve been working on the supervisory software inside the SAM4 microcontroller.

Here are the planned features for this chip:

• Flash management including flash translation layer
• MRAM management
• Provide an interface to the FPGA to access these two memories
• Provide a debug console for both the monitor program and the FPGA
• Provide an upload facility to both the FPGA and to memory

To date, I’ve:

• Written the MRAM interface, using the Atmel ASF libraries to handle the SPI
• Connected and passed traffic between the FPGA and the SAM4 supervisor using the 40MHz SPI interface
• Started the user interface for the monitor program. At the moment, all it shows is one active item to upload the bitstream to the FPGA and several templated inactive items.
• Connected and can read/write the RAW flash layer

Where I’ve gotten bogged down is in the flash translation layer (FTL). The Atmel ASF framework provides most of the functionality required to interface to raw flash. It provides hooks and template headers (.h files) for the FTL, but doesn’t actually provide an implementation of FTL.

This is probably because an FTL is a highly complex piece of software and sophisticated flash translation algorithms are a closely guarded secret at the likes of Sandisk and Samsung.

I did find one open source FTL on Github by Daniel Beer. I downloaded and tested this on my PC using all sorts of weird situations and edge cases, and it seemed to work OK, but did do some odd things upon sync/garbage collection and consumed a rather large chunk (20%-40%) of the flash for internal management purposes. It was also extremely slow to start up with the  120MHz SAM4, as it searched for and processed the journal and conducted recovery steps.

My CPC2.0 needs to be instant-on, so I was forced to consider alternatives. I was loathe to write my own FTL, because firstly it’s hard to make it reliable and secondly it wasn’t really a focus for this project, just an enabling technology. I did some further googling and belatedly realised that I had really picked the wrong flash technology. In choosing to use raw flash, the management of this flash is run on the connected processor, slowing down access and limiting the size. (The larger the flash device, the more data needs to be passed to the CPU and back again to manage the FTL). I couldn’t work out why the largest raw flash device was only 1GB. I now know that anything larger than that becomes a management nightmare for resource-limited CPUs, like microcontrollers.

I then stumbled (accidentally) across eMMC and initially had discarded the option because no specifications were available for the Sandisk devices that were on sale at Mouser. After some further reading, I found that all specifications are available on JEDEC, the standards body who took over management of the specification. Further reading told me that although you need to register to log in and download the specifications, they are free of charge after the MMC specification was given to JEDEC to manage from the original developers. The physical, electrical and logical specifications are separately documented, but essentially this tiny BGA device uses the same interface as the SD cards you use in your digital camera, albeit with 8 data lines instead of 4. The capacities are also 128x bigger, (128GB) and 16x cheaper (16GB eMMC for the price of 1GB raw flash).

Crucially, it also has a flash translation layer on board, so an FTL would not be needed in the SAM4 and the monitor program suddenly becomes a lot simpler. I now have to decide whether I replace the raw flash with these eMMC chips. It would mean a revision of the current board, a new build and importantly a delay in the development of the monitor program. The eMMC chips also seem to only come in 0.5mm pitch BGAs, so I’d also need to see if my board manufacturer, OSH Park, would be able to create a board with the right tolerances. A test board seems appropriate, I feel!

I’ve come up with a specification for my FTL, but am now cautious about starting down this track. 16GB would give me a lot more options if I wanted to expand the core images to do something else with the board (like an Amiga!).

For now, I may just map the flash pages 1:1, so that I can connect the monitor program to the flash and move on. I have 100,000 writes/erases available anyway. I doubt I’ll need more than that for the development image. I’ll come back and look at this later.

If anyone has any thoughts or experiences of eMMC, I’d love to hear them.

My next post describes the process of refining the upload process to Flash.