Need help regarding flash memory options

[Ge0rge Marutz]

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

 

[Tim Wescott]

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

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 .

 

[Ge0rge Marutz]

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

 

[Tim Wescott]

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

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.

 

[[email protected]]

It it really feasible to bit bang this interface? Talk about putting
the programmer through living hell...

It's more like byte-banging multiword accesses.

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.

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).

 

[Ge0rge Marutz]

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

 

[Ge0rge Marutz]

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

 

[Tim Wescott]

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

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?

 

[Pooh Bear]

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.

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

It's not really very hard.

Graham

 

[Ge0rge Marutz]

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

 

[Ge0rge Marutz]

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

 

[Rich Grise]

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?

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

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

Good Luck!
Rich

 

[Ian Stirling]

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.

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?

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

 

[Ge0rge Marutz]

What's reading this?

Why not simply plug the incoming USB thing into >the PC, and eliminate
all the hardware

Huh?

Gerb

 

[Ge0rge Marutz]

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

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

Good Luck!
Rich

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

 

[Ian Stirling]

Huh?

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?

 

[Rich Grise]

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

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

 

[[email protected]]

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.