Connect with us

Need help regarding flash memory options

Discussion in 'Electronic Design' started by Ge0rge Marutz, Oct 5, 2005.

Scroll to continue with content
  1. I have an embedded application where I want to add up to 1GByte of
    non-volatile memory. The first product offering will require 256MByte
    but I need room to expand. The whole assembly must be extremely small
    in size.

    My first thought was to use NAND flash. However, the micro I must use
    does not have an external memory interface. As far as I know this
    rules out NAND flash.

    The micro does have a SPI buss. I tried looking for serial memories
    designed to communicate over the SPI buss. The problem is, the largest
    memory I can find is 64Mbit (8MByte). I would have to add numerous
    devices on the SPI buss to obtain the memory density I require. This
    is not an option.

    I recently found that SD Flash cards can communicate over a SPI buss in
    the SPI/MMC mode. I realize I could simply place a card reader slot on
    the board and add a SD memory card. However, I see this approach
    adding un-necessary cost. I would like to manufacture quite a few of
    these devices. I wish to keep cost down by any means possible. I
    tried searching for design information regarding what is inside a SD
    memory card but come up with nothing. My thought is that I would buy
    whatever chip/chipset that is on the card and place this directly on my
    board. This would save the cost of the plastic case and circuit board
    inside a SD flash card. It would also save me the cost of the card
    reader slot. However, days of searching google has not yeilded the
    information I need.

    Do you have any ideas where I might start my search? Are the contents
    of a SD flash card proprietary or does someone sell the chip/chipset?
    Is a SD flash card simply a NAND flash cell plus some memory
    controller? Can you think of a better option?

    Any help you could offer would be deeply appreciated.

    Gerb
     
  2. Tim Wescott

    Tim Wescott Guest

    It's been a while since I've looked but check the NAND flash specs --
    they don't have a "normal" memory interface; what they have requires 11
    lines or so (8 data & command, a few control lines). You'll have to
    bit-bang it anyway, so you don't have to feel bad about the lack of a
    "real" interface.

    They'll require software to talk to -- they're more like disks in that
    they'll ship with bad sectors and it's up to you to format. Furthermore
    they expect you to implement error correcting codes, but when I was
    looking there weren't any white papers (at least not in English) on how
    to do it.

    For the "chipset" a small PIC, AVR, or 8051 variant with SPI, a few GPIO
    lines, and some code ought to reduce the problem to mere software :).
     
  3. It it really feasible to bit bang this interface? Talk about putting
    the programmer through living hell...

    Do you have any leads on a small, inexpensive, microcontroller that has
    a SPI port and hardware based SD memory controller? I've come across a
    few with a hardware controller but they were not economical options.
    IMO the more software overhead I can eliminate the better.

    Gerb
     
  4. Tim Wescott

    Tim Wescott Guest

    If you think bit-banging that interface is a living hell you've led a
    protected life! It looks like it couldn't be easier, to me.

    Now, dealing with the formatting and error correction issues would take
    some work, but nothing that's not fairly direct, I don't think.

    No, I don't know of someone who makes a pre-programmed processor, or one
    with a hardware interface. Might be a good cottage-industry product,
    though.
     
  5. Guest

    It's more like byte-banging multiword accesses.
    What you want is a micro with some general purpose I/O pins... maybe 12
    or so, 8 of which could be shared with another function (since they'd
    be validated by the remaining ones that you'd use for control signals).
     
  6. The micro I am using has many available port pins that could be used
    for data/control. It's just that writing the memory interface sounds
    kind of scarey. As a hardware engineer I want to give the programmer
    something he can work with and feel comfortable about. I'll have to
    address "byte-banging multiword accesses" with him. It is quite
    possible he will not have a clue on how to do this. He's a great PC
    level programmer but I'm not sure about embedded. I'd hate to throw in
    a ton of confusion by having to perform memory read/write management.

    Ge0rge

    Gerb
     
  7. The micro I am using has many available port pins that could be used
    for data/control. It's just that writing the memory interface sounds
    kind of scarey. As a hardware engineer I want to give the programmer
    something he can work with and feel comfortable about. I'll have to
    address "byte-banging multiword accesses" with him. It is quite
    possible he will not have a clue on how to do this. He's a great PC
    level programmer but I'm not sure about embedded. I'd hate to throw in
    a ton of confusion by having to perform memory read/write management.

    Ge0rge

    Gerb
     
  8. Tim Wescott

    Tim Wescott Guest

    If he chokes on this he'll never manage embedded stuff. I would put the
    level of difficulty of actually talking to the flash chip in the same
    class as getting an SPI interface working correctly.

    And since when have hardware engineers succeeded by looking out for the
    poor bastards who have to make their hardware actually work?
     
  9. Pooh Bear

    Pooh Bear Guest

    Without an external memory interface you don't actually have any choice !

    It's not really very hard.

    Graham
     
  10. I'm not concerned about actually communicating with the chip. I'm
    confident this can be done to some extent. I'm more concerned about
    how fast this can be done and the CPU time I'd be using to do it.

    I'd like to read/write at 12Mbit/s (limit of full speed USB). I'm not
    sure this can be accomplished if all memory management is done through
    software alone.

    Then there is writing data and keeping proper buss timing, learning how
    to format the memory and treat it like a disk, and of course error
    correction (which is not well documented). This seems like a lot of
    extra effort.

    Can anyone think of an application note that might go over how to do
    all this? Some other source?

    All may not be lost. Let me run this by you. It might be about the
    only computationally intensive task the CPU might have to do is memory
    management. Data will enter the application via an on board USB
    controller. An on chip DMA controller will send the data directly to a
    hardware based signal processor. From there the DMA controller can
    route data back out the USB port or write it to RAM. Hypothetically,
    all without a significant amount of the microcontroller CPU's
    intervention. The microcontrollers CPU can then fetch data from the
    RAM and use its memory management routine to write to flash.

    What do you think?

    Gerb
     
  11. Hmm, topic seemed to have died off.

    Say I was to try bit banging using general purpose I/O. Are there
    certain types of ports that would work better than others for this
    application?

    Gerb
     
  12. Rich Grise

    Rich Grise Guest

    Ones where you can control individual bits would be a good idea.

    How many "types" of ports do you know of?

    Good Luck!
    Rich
     
  13. Ian Stirling

    Ian Stirling Guest

    What's reading this?
    Why not simply plug the incoming USB thing into the PC, and eliminate
    all the hardware.
     
  14. What's reading this?
    Huh?

    Gerb
     
  15. Ones where you can control individual bits would >be a good idea.
    Perhaps I oversimplified the question. I was thinking more along the
    lines of:

    Timer counter
    SPI ports
    USART ports
    Ethernet
    TWI
    PWM channels
    etc...

    These features are unused. Could I hack features of these interfaces
    to make external NAND flash memory control less software intensive?

    Gerb
     
  16. Ian Stirling

    Ian Stirling Guest

    The description as I understood it was
    USB-input-device (webcam/...) -> device -> USB input to a PC.

    Why not simply remove the device from the middle, and plug it straight into
    the PC?
     
  17. Rich Grise

    Rich Grise Guest

    Well, I don't really know that much about flash, but if it's serial,
    I'm pretty sure you'd use the SPI port. If it's parallel, you'd
    have to dedicate as many plain old ordinary outputs as you need for
    address and data.

    Have you already decided on a flash chip, or are you still doing
    research to find a suitable one?

    Thanks,
    Rich
     
  18. Guest

    No. Access to the flash device is not really all that software
    intensive - at least not much more so than talking to a serial one over
    SPI. Parallel access off general purpose ports is going to require
    something like three or four port accesses per read or write. Access
    to SPI is going to require one to set it up, but then you have to wait
    for it to finish.

    That's just communicating with the chip. To accomplish anything
    meaningful like reading data, or writing it, or erasing blocks, or
    mapping around errors, is going to require about the same amount of
    work either way. Regardless if the interface is SPI or parallel, you
    are going to have to issue commands to the chip to do each of these
    things - command, address, data, in some cases a whole block of data
    without more command or address.

    Parallel access is no harder to code than getting the SPI ports on an
    unfamiliar micro up and running. It's likely faster at run time, or at
    least not appreciably slower. And the complexities of software to do
    anything usefull with the flash are the same, because the command sets
    and underlying NAND cell behaviour are pretty similar regardless of the
    physical interface used.

    If you really want to avoid all of this, buy an embedded O/S with flash
    routines.
     
Ask a Question
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.
Electronics Point Logo
Continue to site
Quote of the day

-