- Silicon Labs Community
- Welcome and Announcements
- Silicon Labs Knowledge Base
- 8-bit MCU
- 32-bit MCU
- Bluetooth / Wi-Fi
- Other Products Category
- Optical/RH/Temp Sensor
- Other Products
- Hardware and Software Tools
- Simplicity Studio and Software
- General Discussions and Suggestions
- Chinese Forum
- Software Libraries
- Development Kits
- Reference Designs
- Third Party Tools
- White Papers
- Official Blog of Silicon Labs
- Chinese Blog
05-25-2017 02:00 PM
I need to make a blue gecko design with a large flash (8 or more GB) for data storage. I was looking at how this is being done in the EFM32 Giant Gecko Starter Kit with the connections to the 32MB nand flash and software routines used for this flash provided by silabs. In looking at the Blue Gecko software documentation, the nand routines are included there under drivers so it seems like you could use them for a nand flash on a blue gecko.
So the question is if the Blue Gecko doesn't have an EBI like the giant gecko does, can I still use the same hardware connection with the nand.c routines on a blue gecko? Or is this impossible because a blue gecko doesn't have an ebi like the giant gecko does? I am attaching the page from the giant gecko reference manual which shows the hardware connections between the giant gecko and nand flash and hoping to do the same ones between a blue gecko and a bigger nand flash.
Thanks for any insight.
Solved! Go to Solution.
05-25-2017 04:40 PM
Well if your Blue Gecko doesn't have an EBI interface then the same thing won't work...
Just a thought: how about using an SPI flash chip? Or a MicroSD card? (Which also has an SPI interface.) There is an app note for dealing with a MicroSD through SPI with a FAT file system, maybe that could be of use.
05-25-2017 05:42 PM - edited 05-26-2017 12:51 PM
So the question is if the Blue Gecko doesn't have an EBI like the giant gecko does, can I still use the same hardware connection with the nand.c routines on a blue gecko?
No, and you should be running for your life from any design into which you might want to incorporate NAND flash. Unless your design is going to ship in the 100K and above units range, the NAND manufacturers don't want to go near you, and you shouldn't go anywhere near them.
The problem is that NAND product life cycles are notoriously short because the technology is driven by the consumer electronics industry and end user demands for increasing amounts of storage. The ECC algorithms on modern NAND devices are getting more complex (e.g. LDPC) and more or less require that you have them implemented in hardware in order to get any reasonable level of performance.
The NAND on the original Giant Gecko SDK was designed onto that board right as the market really started taking off. I'm quite surprised we are still able to source them.
So, what are your options?
Well, for starters, whatever you use should be a managed NAND solution, e.g. a device which incorporates a dedicated controller to manage ECC and wear-leveling of the flash. That leaves you with, effectively, two options:
- SD or microSD. You can still access one of these if you have a serial port capable of SPI-style transfers (e.g. the USART on EFM32 and EFR32), and we provide a basic driver and FAT file system in our SDK. Note that you'll be limited to only SD and SDHC cards (or their micro equivalents). SDXC cards won't be a choice because the SDXC standard mandates that Microsoft's exFAT file system be used, and we don't have an implementation of it.
- Serial NAND. Really, your only option for Serial NAND in the range of 8 GB is Cypress, who acquired the technology and product line when they purchased Spansion. Other memory vendors like Macronix, Winbond, Toshiba, and Micron have serial NAND devices, but their capacities max out at 2 or 4 GB.
In general, the memory industry isn't much interested in the traditional embedded space, although recent developments, like Serial NAND and high capacity SPI flash, are an attempt to address the need for memory above and beyond what you find integrated on your typical MCU.
05-26-2017 07:47 AM
Thanks John for the complete and educational answer. I have been trying to research things and I didn't seem to get anywhere with the nand flash info, with your answer, I can now see why. I had looked at the eMMC too which would be a managed nand but it also didn't seem easy to integrate hardware-wise into the blue gecko. I think your answer will be enough for my choice on this first version of the design. Thanks again, Maria
05-26-2017 01:39 PM - edited 05-26-2017 05:40 PM
Yep, even though eMMC is a managed NAND solution, it is not an option for embedded devices like Blue Gecko.
Here's story behind why this is the case:
Samsung developed one of several removable memory card standards in the early days of digital imaging called MultiMedia Card or MMC. In order to allow it to be used with embedded devices that did not have a dedicated hardware controller interface, Samsung added a SPI transfer mode that could be used in place of MMC's single clock, command, and data lines.
BTW, for those that didn't know, as the SmartMedia card standard lost acceptance in the market, its primary technology backer, Toshiba, got together with SanDisk and Panasonic to create the Secure Digital (SD) card standard. They essentially took the MMC standard and expanded the data bus to 4 bits. Samsung responded by changing the name of the MMC standard to MMCplus, expanding the data bus to 4 or 8 bits, and increasing the clock frequency.
I always felt MMCplus was a better memory card standard because it supported things not available in SD (at least at the time) like operation down to 1.8V. Additionally, when the need for physically smaller cards arose, MMCplus adopted an elegant form factor that essentially cut the vertical dimension of the card in half and added a physical extended as an adapter...
...as opposed to the kludgy MiniSD and its slide in adapter:
Of course, these mini versions didn't stick around very long, and both standards went to an entirely different, physically smaller format, with the SD Association taking ownership of SanDisk's TransFlash and making it their micro format:
Anyway, I digress. As you can figure by now, MMCplus didn't get the market traction of SD, and Samsung ultimately turned the standard over to JEDEC. However, the story doesn't end there.
Samsung and other vendors, like SanDisk, had started working on what were essentially chip scale versions of their memory cards. These devices would come in packages with solder balls and were intended to be permanently attached to printed circuit boards.
Samsung called theirs eMMC, for embedded MMC, and JEDEC, arguably, assumed ownership of the MMCplus standard really for the purpose of advancing eMMC and not the card formats. So, while SD dominated the memory card market, eMMC quietly began building a head of steam and ultimately became the de facto choice for high capacity on-board storage, driven by, surprise, surprise, the increasing difficulty of using raw NAND components and the impact it had on both SoC designs and operating system software (meaning the Linux kernel).
AFAIK, apart from Apple, every handset manufacturer uses eMMC for their on-board storage. The same applies to things like Roku streaming TV boxes and even the new generation of super, low-cost Windows notebooks and convertibles (if they have 16 or 32 GB of storage, they use eMMC). Even SanDisk, whose iNAND embedded storage devices were at first SD cards in a chip package, ultimately moved to eMMC.
Oh, what does this have to do with using eMMC along with something like a Blue Gecko? Somewhere along the way as the eMMC standard evolved, maybe even in its first iteration, the SPI transfer mode that was always supported by MMC was dropped Without dedicated controller hardware (eMMC supports the original MMC 1-bit data bus in addition to the MMCplus 4- and 8-bit wide options), it's rather painful to interface an eMMC.