AT45DB161D Dataflash

Basil

Hi All,

Just wondering if anyone has had experience with this chip?

I want to using it for datalogging on my altimeter.
Will only need to write 5 bytes every 10ms so doesn't look like it will be a problem

Just need to know if it is difficult to implement, or can it be used with standard SPI objects?


Alec

Paul Baker

It appears to be a chip used in MMC cards, so you should be able to adapt·rokicki's code for SD cards. Whether you use the FAT layer or not is up to you.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer

Parallax, Inc.

Post Edited (Paul Baker (Parallax)) : 4/19/2007 9:51:45 PM GMT

Newzed

Alec, I am not familiar with that particular chip, but I have been using the AT45DB041 for quite awhile.· 4Mb of storage, easy to communicate with.· It writes to a 264 byte buffer, and if the buffer is full, or if the logging is stopped, it writes the contents of the buffer to main memory.· Excellent EEPROM - if I can help you with it, I will be happy to do so.

Sid

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Yesterday is history, tomorrow is a mystery, and today is a gift.

That is why they call it the present.

Don't have VGA?
Newzed@aol.com
·

Basil

Hi Newzed,

Thanks for that [noparse]:)[/noparse]

I have had a quick look at the data sheet and it looks good [noparse]:)[/noparse]

Do you have a object already for this device? I'd assume there wouldn't be too much difference between the 4Mb and 16Mb versions.

Haven't had a chance to look in detail, how long would it take to write 5 bytes?

Tracy Allen

I've used dataflash extensively for my OWL2pe data loggers with the BASIC Stamp and have helped others implement it on the Stamp for hobby projects. The -D revision is RoHS and comes in higher densities, so it (AT45DB041D) is what I am using now. The -D revision is mostly backward compatible with the -B version, but there are additional commands and the static method (without clocking) for checking the write status is no longer supported, and some o the other commands are on a relegated list. Keep that in mind if you look at old code.

The SPI objects might work, but the commands are peculiar enough that you might want to customize the object for this purpose. Several of the commands have lots of "don't care" clocking bits, and the command is usually left open (without dropping chip select) at the end so that additional data can follow, and the chip select is only dropped at the end of the entire transaction, which might involve hundreds or thousands of bytes.

I don't know about dataflash being used in SD cards, but it certainly might be in the fastest cards, due to the dual high speed RAM buffers. I don't use a FAT structure.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com

Basil

OOO lots of good feedback, this is good [noparse]:)[/noparse]
I have pretty much made up my mind on this chip and will start designing it in.

I like the fact its 3V, easy to interface to the prop!

Does anyone have an Eagle file for this component? (SOIC version)

Newzed

Alec, could I make a suggestion - if you have a Stamp laying around, why not let the Stamp handle the EEPROM.· It would only take two Prop I/O pins -serin and serout.· The Prop could send the data to Stamp for storage and upon receipt of the proper command, read back the EEPROM contenets to the Prop for VGA display.· That is the system I use - the Prop has an XBEE, and communicates with two Stamps in remote locations using only two Prop pins.

A design reminder - the EEPROM takes a bit of power when it starts to write and can cause a brownout if you don't allow for it.· I would recommend a large electrolytic on Pin 6 - 22uf would be the absolute minimum.· I think you can get a suitable SMD cap in Case size D or E.

Sid

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Yesterday is history, tomorrow is a mystery, and today is a gift.

That is why they call it the present.

Don't have VGA?
Newzed@aol.com
·

Basil

Hi Newzed,

Thanks for the suggestion. Unfortunatly I am very tight for space and the prop will have to be the only MCU. Im also trying to keep the cost down and software is free of charge for me, hardware is definatly not lol
I can afford to dedicate a prop completly to datalogging though so thats a plus.

Good sugestion though, I may use it in other applications [noparse]:)[/noparse]

Peter Jakacki

I have used the 041 part myself but this part has some enhancements besides the extra memory. It used to be a pain on the old version with auto-buffering (using the dual RAM buffers) due to the non-standard page length which didn't lend itself to FAT structures unless you padded or manual accessed pages. I see that this new version allows the user to select 512bytes/page.

I like this family of devices because they are in compact 8-pin smd packages and very easy to interface.

As to the large capacitor that Sid mentioned I have not found that necessary. Perhaps if the power traces are long and narrow that might have been necessary but the maximum current is only 17ma when programming. Note that this is specified at 3.6V and most might think that it would be less at 3.3V but this is not the case with EEPROM/FLASH technology as they need a voltage converter to develop the voltages necessary for tunneling during writing (correct me if I am wrong in this case). So this voltage converter is built on the chip and will draw more current at 2.7V than at 3.6V. However this current is still relatively low so the normal decoupling caps should be fine.

Personally I would just drive this directly from the Prop as there are only 4 lines required as you can tie the SI and SO together without any problems. The SO and SI are separated only because this allows them to interface to standard SPI ports but since we are bit-bashing we have control over the direction of the data line. Frequently I will simply hang the SCK off the I2C SCL line and SO/SI off the SDA without impacting either bus. In which case you really only need 1 line to drive the CS but make sure you have a pullup on this to disable the dataflash during boot until software can control this line.

*Peter*

Basil

This is all very interesting. So I could add this device the the I2C bus which the 32K boot memory is on and not have any troubles? I don't think there will ever be a time when I need to write to the I2C memory after the initial boot so no problems there [noparse]:)[/noparse]

Tracy Allen

I do tie SI to SO (with 3kohms to SO). But, Peter, I beg to differ on combining I2C and SPI signal lines. In my opinion that leads to nothing but trouble. It can be done, but special care has to be taken to get each part into its ground state before sending commands. SPI signal lines rest at a low level, asserted, while I2C lines rest at a high level via pullups. Incorrect juggling can lead to strange effects, especially if parts have to be powered down to conserve a battery.

Note on the -D series -- if you decide to blow the fuse for the binary page sizes, as I understand it, there is no going back! I think those extra bytes on the page were meant for checksums and for page link pointers etc.

The dataflash can accept data very fast, clocked at 66mhz, or as fast as the Prop can push it, and much faster than the Stamp. That is to fill the RAM buffers. The page programming time (page previously erased) is 2 milliseconds typical, so it can accept data continuously at a rate of around 32 kilobytes per second.

Watch out for the issues of wear leveling that are discussed at length in the Atmel application notes. In a data logger application you will want to have a base pointer that chases the current record pointer around the entire array so that no one page take all the heat.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com

Basil

Pins P0-P3 are free on my schematic anyway so I can use them for the dataflash. It's actually easier to route the tracks using separate buses too[noparse]:)[/noparse]

I am at work now so haven't had a good read of the data sheet (had lots of time to read forums though lol). If I only need to write every 10ms and it takes 2ms to do a write, would the 8ms in between wrties reduce the wear on 1 page?

Peter Jakacki

Hi Tracy,

I beg to politely differ as well because I speak from experience. I2C devices wait for a valid start condition (data high to low while clock high) before they even listen to the bus and then they still need the correct address etc. SPI is just as blind to bus activity if it is not selected (of course), so the start condition + device address is analogous to the chip select in SPI, don't select them then they are ignorant. I have seen some fudging done in this forum with I2C by sending extra clocks for instance. The devices do not need fudging, just read the I2C spec and issue the correct ack/naks etc and the device is happy (I have been working with I2C since it was born).

SPI is easy to get back into it's ground state as I believe that it only needs to be deselected then reselected as it always will expect opcode1. I2C is designed for multi-master etc and so could conceivably be interrupted in the middle of a transaction so they behave differently. Blowing fuses accidentally? If it was that easy then I would take a look at my code as well to make sure it didn't happen but the only real sure safe method is hardware control.

These chips were originally designed for voice message storage and the extra bytes are for housekeeping such as crc, links, etc so you are correct in your statement.

Your comments about wear leveling remind me of a couple of old 8K parallel bus EEPROMs in the 28-pin pack that a friend was trying to reprogram but without success. So I tried my universal burner on it and it fared little better. From what I could tell the chips had been cycled beyond their endurance and obviously the designers didn't take that into account. But it was an old bit of equipment after all.

When I have implemented data-loggers within a FAT structure (usually on SD) I don't rely on the FAT to handle the logging. Basically I preallocate in large chunks and maintain a unique logical EOF to permit recovery in the event of unexpected system reseting (power fail). The poor old FAT and DIR entries would wear out if they were handled in the traditional constant update method but FAT can be read by almost any computer.

*Peter*

Tracy Allen

Understand that if you are only going to change one byte or a few bytes on a page, and you need to append to data that is already there, you have to read the current contents of the page into one of the RAM buffers, put in your new data, then write the RAM buffer back to the page. Writing is always is done by page

A delay between writes is not a problem. It is a matter of the total number of writes, not how often they are done. There are two issues. One issue is wearing out an individual page by writing it too often. The -D version is improved and specs 100,00 writes per page minimum. But that is why you want to cycle your data logging around the array rather than always starting at absolute zero. The second issue is retention of data that has been written to a page a long time ago, where "long time" is largely defined by how many other different pages have been written to in the meantime. Data (the charge that represents the data) can "leak" off the page, and pages may need to be refreshed from time to time. The chip has a convenient refresh command that basically transfers the data into a RAM buffer, erases the flash, and then reburns the data.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com

Peter Jakacki

Basil, it comes back down to the 100,0000 minimum writes per page. If you wrote to the page in Flash (not RAM) every 8ms that's 100/second or 6,000/minute which means you are going to kill it within 17 minutes. Do not have any scheme which relies upon a constant update to any one page or it's bye bye Flash. The time between writes is immaterial as the endurance is related to the tunneling of a charge onto the memory cells floating gate, this involves stressing the silicon sufficiently. If it gets zapped too much it will eventually fail. The early Flash devices only had endurances of 100 cycles which was 100 times better than none!

*Peter*

Basil

Oh ok.

So if I was to store 1 second of data into the 512K buffer (500 bytes when sampled @ 100Hz), and then write a whole seconds worth of data to the memory (nearly 1 page), I could write 4096 seconds of data without appending, is this correct?

The user will then upload the data to a PC, which will erase it off the altimeter ready for another 4096 minutes of data [noparse]:)[/noparse]

As I understand it, this would mean I could fill up the entire memory 100,000 times before the IC is fried?

Peter Jakacki

Basil,
There should be no reason in this application where you cannot use the alternating RAM buffer and then Buffer to Main Memory Page with Built-in Erase method. This means that for every 512 bytes you are only burning the page once = 1 cycle. So you are then only putting the whole device through one cycle when you have filled all 4,096 pages as long as you use this sequential method. The device is guaranteed for 100,000 cycles so it might even be 1,000,000 cycles before you start to see problems and yes you could have software allow for this and map out bad sectors but I like to keep it simple.

*Peter*

Basil

Thats exactly what i had in mind in my previous post, only you explained it alot better lol

500bytes = ~1 second of recording @ 10ms per sample.

[noparse]:)[/noparse]

Tracy Allen

Peter,
I do grant that SPI and I2C can be mixed. I'd rather not if there are pins available. There are extra hassles of having to be sure the clock line is low before starting an SPI transaction and for it to be released as an input (pulled high) and to generate a stop condition before starting an I2C transaction. It can be made to work, but I was in the environment of programming the Stamp and it always had to be considered when adding a new device to each bus. You have more options on the Propeller than there are on the Stamp, more structure. Also, some I2C devices that run on backup batteries (RTC) will do very odd things related to parasitic power if their i/o pins are driven high when the rest of the chip is powered down. I'd much rather seperate the busses and not have to worry about it. But of course, if short of pins...

Basil, are you really going to sample the altimeter at 100 hz, 500 samples every second for 4096 seconds? Or is that hypothetical? What you say is correct, 100,000 times before the IC is on the edge, according to the data sheet as I read it. Those things are statistical. I am not sure exactly how a statistician would phrase it, and I might not want to know!

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com

Basil

Hi Tracy,

I will be recording at a user selectable rate of either 10ms, 20ms, 50ms or 100ms between writes.

(In actual fact, the device will be sampling the various sensors every 10ms regardless of how frequently data is recorded, and only recording at the user defined frequency)
The data I will be saving is 12bits from barometer, 12 bits from accelerometer and the time in ms after launch when the sample was taken, 1 byte i'd think.

So all up, I will be recording ~5 bytes every 10ms minimum, which is 500 bytes per second isn't it? (Lets hope im write lol this is simple maths)

Anywho. Each flight is likely to be short, say 1-2 minutes, or if the user chooses to stop recording at apogee, then a whole lot less data will need to be recorded!

Each flight's data will start being stored where the previous flight ended. Once the memory is full (4096 bytes full), the MCU will tell the user to upload his/her data to a PC and will start the next recording from 'Byte 0' again.

Basil

On the hardware side of things.
I understand there are no additional components id need (I.e. Pull up/down resistors) to connect this device the the prop on its own 3 data lines? (SI & SO tied together)

Just finalising my hardware and want to make sure I don't miss anything [noparse]:)[/noparse]

Tracy Allen

Basil, I use a ~3kohm resistor from SO to SI and then to the microprocessor pin. If the code is written and debugged correctly, it should not be necessary to include the resistor. However, the R protects against the possibility of contention. Don't forget the other lines, WP high. Also the power supply bypass capacitor.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com

Basil

Hi Tracey,

Thanks for the advise

I have pulled the WP and also the Reset high as per the PDF. Is the reset not needed?

I will put in a 3K3 resistor to be safe
I can't think of a time when I will ever read from the memory during flight, and I can't think of a time where I will write to it after so contention shouldn't be a problem, but its better to be safe than sorry!

Would 0.1uf do for the cap?

Tracy Allen

Whether reading or writing, the prototcol is an exchange of command, data, status info. The 3k R is more a protection while you are in the process of tinkering(!) with the firmware.

I've always tied reset\ and WP\ both high. I usually use a 1uF 0805 X5R capacitor, but 0.1 right by the chip should be fine if the rest of the power supply is well filtered. The -D version chip draws 17 mA maximum during the 2 or 3 milliseconds of a page write, but if you use the block or sector erase commands (very convenient for "starting over"), that duration can be much longer. But it is all less than 1/2 the current drawn by the B version of the chip.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com

Basil

I would never tinker Ok, so I do tinker a bit
I will take your suggestion and use 1uf cap. I have to have good filtering on everything as I can't have anything go wrong due to its rather explosive job

Newzed

Basil, for what it's worth, I tie the Reset to an I/O port and hold it low unless I want to write to or read from the EEPROM, in which case I take it high.· The initializing protocol for the chip makes it pretty unlikely that anything could trigger a write or an erase, but still...............Just playing it safe.

Sid

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Yesterday is history, tomorrow is a mystery, and today is a gift.

That is why they call it the present.

Don't have VGA?
Newzed@aol.com
·

Basil

Thats a good idea.
Just had a look at the PDF again and relalised just how simple this is to do! The Prop and Dataflash are right beside each other on the PCB

Peter Jakacki

I would say that not only is it unnecessary to tie the reset line to an I/O pin but also a bad idea. The dataflash times it's own erasures, writes and buffering and so frees the host from worrying about these details. Reseting the chip when it is in the middle of these operations is a big no no and if you go reseting the chip after a write this will most likely happen.

There is no reason I can see where you would want to reset the chip, if it is for "protection" then I say it is a very poor and dubious method of protection. If you are going to accidentally write garbage to the device which requires the CS active and the correct codes etc then what protection is a single I/O line that only needs to go high going to provide?

Atmel Datasheet said...

Reset: A low state on the reset pin (RESET) will terminate the operation in progress and reset
the internal state machine to an idle state. The device will remain in the reset condition as long as
a low level is present on the RESET pin. Normal operation can resume once the RESET pin is
brought back to a high level.
The device incorporates an internal power-on reset circuit, so there are no restrictions on the
RESET pin during power-on sequences. If this pin and feature are not utilized it is recommended
that the RESET pin be driven high externally.

Stick with the advice that Tracy gave and tie it high.

*Peter*

Basil

I see the reasoning behind that
Ill stick with my original design then, no worries.

While we are on the topic of protection, in the schematic I posted earlier, I need to protect the signal from the MCU to the Bias Transistors, and the one from them to the FET's from going high accidently due to noise.
The track connecting them to the MCU will be approx 1" long. Does it pay to make this track fatter (I am using 16mil for this one already) to help protect against noise/interferance accidently firing the FET?

Also, am I able to put this track through a via safely? or does this come with problems of its own? (MCU and trans on bottom layer, FET on top)

I have a ground plane on the bottom layer and an tossing up between a 3.3V/5V and ground plane for the top layer. Depends what give the best protection.

Your inputs are appreciated on this.

Bean

Tracy Allen said...

Note on the -D series -- if you decide to blow the fuse for the binary page sizes, as I understand it, there is no going back! I think those extra bytes on the page were meant for checksums and for page link pointers etc.

Tracy,
· I think the extra bytes are for wear-leveling data.

· Have you actually used this device with SI connected to SO ? The datasheet doesn't say anything about it.

Bean


▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"Educate your children to self-control, to the habit of holding passion and prejudice and evil tendencies subject to an upright and reasoning will, and you have done much to abolish misery from their future and crimes from society"

Benjamin Franklin
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
www.hittconsulting.com
·

Tracy Allen

Hi Terry,

The AT45DB041 is the storage memory on my OWL2pe data loggers, and a single Stamp pin is connected to SI and also through 3kohms to SO. I know they do not suggest that method explicitly in their literature. However, you can read from the timing diagrams that the SO pin is high impedance until an output command is decoded, and the SI pin is shown as "don't care" (crosshatch) during activity on SO. I did extensive testing and talked with ATMEL engineers before committing it to the circuit boards.

Incidentally, the input pins are 5 volt tolerant. The Atmel app note AN-4 talks a lot about wear leveling and other issues.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com