This chip feeds a whole page of 264 bytes into memory from a RAM buffer. But you can fill the RAM buffer byte by byte, if you want.
That way you can read in bytes to the RAM buffer and transfer the buffer to main EEPROM memory when it is full.
And it is 2.7 - 3.6 Volt power supply but the inputs are '5 Volt tolerant'. This means nothing will go wrong if you put 5 Volt, from a Stamp, to the data in or clock and chip select pins.
Come on, guys.· Someone out there must be using an AT45DB011B, or has used one before.· I have never, never given up on a project before but I'm awfully close to giving up on this one.
I looked at the snippets you sent me and nothing jumps out at me as being obviously wrong.
-- You say that you can write and read to the sram buffers without a hitch, which shows that the hookup is okay.
-- It looks like you have a good pause after the command to write the buffer to the flash memory, because without the pause the write process can be aborted.
-- How about your 3 volt power supply? Does it have an adequate filter capacitor? The AT45 requires quite a pulse of current when it has to write to the flash.
-- In a debugging situation like this, I always try stripping away everything but the step in question. Make a program that writes a few bytes to page 1, write it to flash, and see if you can read it back using one or the other of the read commands . Leave out all the stuff that fills up multiple pages.
-- I know people have been able to get the AT45 working after looking at my examples at www.emesystems.com/BS2flash.htm. Those are from 1999, when I was using the 5 volt version of the part, but the protocol has not changed at all, and it is the same for the AT45DB011 as it is for the AT45DB041, except that the '011 has only one sram buffer. There is also a chapter on using the AT45DB041 with the Stamp in the manual for my OWL2pe data logger, emesystems.com/OWL2pepr.htm -- follow the link to the technical manual and look on page 26.
My packets are 8 bytes.· I tried writing·2 packets to the buffer and then writing the buffer to main, page 0.· I'm only trying to write/read page 0.
I rewrote buffer to main several times, each time with different results.
Here are the results I got - erratic to say the least.· The results are probably not in the order they were noted.· I just telling you the different results I got:
1 time 1st packet was OK
1 time no packets were OK|
1 time both packets were ok
1 time middle 2 bytes were OK
1 time middle 4 bytes were OK
1 time middle 6 bytes were OK
I am using a 3 volt SMD regulator with a 9V input.· The only cap I have on the 3 volt regulator output is a .1uf bypass.· The regulator output is not easily accessible with a scope so I don't know if the voltage is dropping when its starts writing to main.· The circuit is on the bottom side of a small PC sandwiched between the Stamp socket and my BS2p.
I just tried again.· I wrote 2 packets to the buffer, then wrote buffer to main.· The first three writes, no·bytes were good, all 255's.· On the fourth write, the middle 6 bytes were good, everything else was 255's.
The erratic results suggest a power supply problem. Try at least 1.0uf at the output of the regulator and/or across the AT45 power supply pins. Some SMT regulators are not stable with 0.1uf and an oscillation would be deadly to the write cycle.
The AT45 has a busy flag in the status register, that you can read to determine exactly when the chip is finished with a flash write. That is the "waitready" routine in my program listings.
Tracy, are you suggesting I remove the .1uf from the regulator output.· I have been using this cap on all the other EEPROMs I have and they work OK.· The regulator is an IRU1206-33CY.
Tomorrow I will tack a jumper on the regulator outsput so I can look at it with a scope.· If I see any irregularities, I have a 22uf SMD cap I can probably attach to it.
Thanks for all your help - I know you are quite busy.
Tracy, I finally got a scope on the regulator output.· I couldn't use the Optascope and debug at the same time so I had to use my HP.
I inserted a 20 second pause at the beginning of the program so I could get a good look at the trace before it started doing anything.· The output had a very small sawtooth, maybe 1mv p-to-p.· When the program started writing to the buffer, the write was reflected in the regulator output, maybe 2mv p-to-p.· When the program started writing to main, same reflection, same magnitude.· I tacked a 47uf cap onto the regulator output and started over.· The sawtooth disappeared, and so did the reflections.· I left the 47uf in place and went back to·my regular program.· I wrote 33 packets - 264 bytes - to the buffer, and it automatically wrote buffer to main.· Went to ReadMain and all 33 packets displayed perfectly!
For this, I owe you.· Again.
I'm thinking of going to the 041 since the chip footprint is the same and I can use the boards I have.· If I understand correctly I can use the·011B program with the following changes:
Instead of
SHIFTOUT Dout,Sclk,MSBFIRST,[noparse][[/noparse]0\6]
I write ·SHIFTOUT Dout,Sclk,MSBFIRST,[noparse][[/noparse]0\4]
and instead of
SHIFTOUT Dout,Sclk,MSBFIRST,[noparse][[/noparse]paddr\9]
I write
SHIFTOUT Dout,Sclk,MSBFIRST,[noparse][[/noparse]paddr\11]
Tracy, this little chip is working great - now I can write and store multiple pages.· The packets I store are 8 bytes - v1,v2,v3,v4,v4,v3,v2,v1 - which are given fixed values in the program.· As long as I wrote in multiples of 33 packets - 264 bytes - all the pages came out neat and full.· Then I wanted to write a number of packets which weren't multiples of 33, such as 37.· The last 4 packets - 34 to 37 - showed up on page 2, but the balance of the page was filled with a repeat of what was on page 1 since those packets in the buffer had not been overwritten. A no-no situation.
So I added the following little routine after the Read_DataBuffer call:
IF b = a and BAddr<>256 THEN······· 'b is number of packets written
BAddr = (b-33) * 8······················· 'a is number of packets to write
v1=255:v2=255:v3=255:v4=255
GOTO Write_DataBuffer1
ENDIF
Then I wrote a special Write_DataBuffer routine:
Write_DataBuffer1:
HIGH red··········· 'LED indicator
LOW CS
SHIFTOUT Dout,Sclk,MSBFIRST,[noparse][[/noparse]Buffer_1_Write]····· 'con $84
SHIFTOUT Dout,Sclk,MSBFIRST,[noparse][[/noparse]Dummy\15]··· 'don't care bits
SHIFTOUT Dout,Sclk,MSBFIRST,[noparse][[/noparse]BAddr\9]
SHIFTOUT Dout,Sclk,MSBFIRST,[noparse][[/noparse]v1,v2,v3,v4,v4,v3,v2,v1]
HIGH CS
LOW red
BAddr=BAddr+8
IF BAddr = 264 THEN cont1·········· 'pointer to Read_DataBuffer
GOTO Write_DataBuffer1
Now then everything after packet 37 is filled with 255's, which tells me I have read all the valid data.
I think I'll go play with my new toy, maybe serin some temperature data
from my keyboard interface RF module.
You know I might have given up on this if you had not mentioned the power supply.
Success is always good news! These power supply glitches can last a fraction of a microsecond, so you might need a 'scope with a 60mhz or 100mhz bandwidth and turn up the intensity and get the triggering and sweep right to see the spike. Or, a digital scope with ver good glitch capture functions. 2mV of ripple would not be the problem, but there was obviously a problem before you put on the larger filter capacitor. Remember that this chip is writing 264x8 bits all at once when you write to it. That is probably a lot more than the other eeproms you have played with.
Your SHIFTOUT commands are unnecessarily complicated, and that is probably due to the convoluted way that the ATMEL data sheet explains things. But the following single SHIFTOUT statement works across the AT45 family, up to the 8 megabit ('081) density.
That is, with one SHIFTOUT statement you can send the command, the page number, and the address on the page. Note that the total address length is 15+9 = 24 bits.
Up to 8 Mbit these all have 264 byte pages. At higher densities, the total address is partitioned diffferently, to accomodate 528 or 1056 byte pages, but it is still the same syntax even for those huge arrays, same command set, everything, even for the AAT45DC series in the MMC card format.
You will notice in my examples I use one single subroutine call to send a command and a CASE statement to append the "don't care" clocking bits for the 4 specific commands that require them. BTW, to avoid confusion, all my routines shift the address on the page left one, because I do all the addressing in terms of words, two bytes.
I was wondering why your program sends the data like this: v1,v2,v3,v4,v4,v3,v2,v1, with 1 to 4 and then again 4 to 1?
Thanks for the shiftout info, Tracy.· I went that way because I didn't want to make any mistakes when I was just starting.· Now that it is working, I can clean up the program a bit.
I was using v1-v2-v3-v4-v4-v3-v2-v1 as a quick and dirty way to get 8 bytes into the packet, which is what I'll be working with later.· I'll be switching to serin RF data in a day or so and my packet will be:
v1.lowbyte,v1.highbyte,v2.lowbyte,v2.highbyte, packet counter,
HEX2 hrs, HEX2 mins,HEX2 secs.· That's 8 bytes.· incoming RF is kist v1 and v2;· the packet counter and time will be inserted prior to writing to the buffer.
You're right, Tracy - success is good news and it makes me feel good.· Sort of wipes out the 6 days of frustration[noparse]:)[/noparse])
Newzed
Posts: 2,503
Comments
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon Williams
Applications Engineer, Parallax
Dallas, TX· USA
Sid
Stop me if I'm wrong, but don't flash chips like that only accept entire page writes at a time? Something like hundreds of bytes per write?
Dave
Jim
This chip feeds a whole page of 264 bytes into memory from a RAM buffer. But you can fill the RAM buffer byte by byte, if you want.
That way you can read in bytes to the RAM buffer and transfer the buffer to main EEPROM memory when it is full.
And it is 2.7 - 3.6 Volt power supply but the inputs are '5 Volt tolerant'. This means nothing will go wrong if you put 5 Volt, from a Stamp, to the data in or clock and chip select pins.
So, it should work with a Stamp !!
Klaus
I'm no closer to getting this thing to work than I was five days ago.· I simply can not get it to write to main memory.
Sid
Sid
Tracy has documentation on a similer Atmel EEPROM chip here:
http://www.emesystems.com/BS2flash.htm
Perhaps there is something helpful there in his notes.
Regards,
Bruce Bates
Thanks anyway,
Sid
-- You say that you can write and read to the sram buffers without a hitch, which shows that the hookup is okay.
-- It looks like you have a good pause after the command to write the buffer to the flash memory, because without the pause the write process can be aborted.
-- How about your 3 volt power supply? Does it have an adequate filter capacitor? The AT45 requires quite a pulse of current when it has to write to the flash.
-- In a debugging situation like this, I always try stripping away everything but the step in question. Make a program that writes a few bytes to page 1, write it to flash, and see if you can read it back using one or the other of the read commands . Leave out all the stuff that fills up multiple pages.
-- I know people have been able to get the AT45 working after looking at my examples at www.emesystems.com/BS2flash.htm. Those are from 1999, when I was using the 5 volt version of the part, but the protocol has not changed at all, and it is the same for the AT45DB011 as it is for the AT45DB041, except that the '011 has only one sram buffer. There is also a chapter on using the AT45DB041 with the Stamp in the manual for my OWL2pe data logger, emesystems.com/OWL2pepr.htm -- follow the link to the technical manual and look on page 26.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
My packets are 8 bytes.· I tried writing·2 packets to the buffer and then writing the buffer to main, page 0.· I'm only trying to write/read page 0.
I rewrote buffer to main several times, each time with different results.
Here are the results I got - erratic to say the least.· The results are probably not in the order they were noted.· I just telling you the different results I got:
1 time 1st packet was OK
1 time no packets were OK|
1 time both packets were ok
1 time middle 2 bytes were OK
1 time middle 4 bytes were OK
1 time middle 6 bytes were OK
I am using a 3 volt SMD regulator with a 9V input.· The only cap I have on the 3 volt regulator output is a .1uf bypass.· The regulator output is not easily accessible with a scope so I don't know if the voltage is dropping when its starts writing to main.· The circuit is on the bottom side of a small PC sandwiched between the Stamp socket and my BS2p.
I just tried again.· I wrote 2 packets to the buffer, then wrote buffer to main.· The first three writes, no·bytes were good, all 255's.· On the fourth write, the middle 6 bytes were good, everything else was 255's.
Does that tell you anything?
Sid
Sid
The erratic results suggest a power supply problem. Try at least 1.0uf at the output of the regulator and/or across the AT45 power supply pins. Some SMT regulators are not stable with 0.1uf and an oscillation would be deadly to the write cycle.
The AT45 has a busy flag in the status register, that you can read to determine exactly when the chip is finished with a flash write. That is the "waitready" routine in my program listings.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
Tomorrow I will tack a jumper on the regulator outsput so I can look at it with a scope.· If I see any irregularities, I have a 22uf SMD cap I can probably attach to it.
Thanks for all your help - I know you are quite busy.
Sid
I inserted a 20 second pause at the beginning of the program so I could get a good look at the trace before it started doing anything.· The output had a very small sawtooth, maybe 1mv p-to-p.· When the program started writing to the buffer, the write was reflected in the regulator output, maybe 2mv p-to-p.· When the program started writing to main, same reflection, same magnitude.· I tacked a 47uf cap onto the regulator output and started over.· The sawtooth disappeared, and so did the reflections.· I left the 47uf in place and went back to·my regular program.· I wrote 33 packets - 264 bytes - to the buffer, and it automatically wrote buffer to main.· Went to ReadMain and all 33 packets displayed perfectly!
For this, I owe you.· Again.
I'm thinking of going to the 041 since the chip footprint is the same and I can use the boards I have.· If I understand correctly I can use the·011B program with the following changes:
Instead of
SHIFTOUT Dout,Sclk,MSBFIRST,[noparse][[/noparse]0\6]
I write
·SHIFTOUT Dout,Sclk,MSBFIRST,[noparse][[/noparse]0\4]
and instead of
SHIFTOUT Dout,Sclk,MSBFIRST,[noparse][[/noparse]paddr\9]
I write
SHIFTOUT Dout,Sclk,MSBFIRST,[noparse][[/noparse]paddr\11]
Have I got it straight?
Thanks again
Sid
So I added the following little routine after the Read_DataBuffer call:
IF b = a and BAddr<>256 THEN······· 'b is number of packets written
BAddr = (b-33) * 8······················· 'a is number of packets to write
v1=255:v2=255:v3=255:v4=255
GOTO Write_DataBuffer1
ENDIF
Then I wrote a special Write_DataBuffer routine:
Write_DataBuffer1:
HIGH red··········· 'LED indicator
LOW CS
SHIFTOUT Dout,Sclk,MSBFIRST,[noparse][[/noparse]Buffer_1_Write]····· 'con $84
SHIFTOUT Dout,Sclk,MSBFIRST,[noparse][[/noparse]Dummy\15]··· 'don't care bits
SHIFTOUT Dout,Sclk,MSBFIRST,[noparse][[/noparse]BAddr\9]
SHIFTOUT Dout,Sclk,MSBFIRST,[noparse][[/noparse]v1,v2,v3,v4,v4,v3,v2,v1]
HIGH CS
LOW red
BAddr=BAddr+8
IF BAddr = 264 THEN cont1·········· 'pointer to Read_DataBuffer
GOTO Write_DataBuffer1
Now then everything after packet 37 is filled with 255's, which tells me I have read all the valid data.
I think I'll go play with my new toy, maybe serin some temperature data
from my keyboard interface RF module.
You know I might have given up on this if you had not mentioned the power supply.
Sid
·
Success is always good news! These power supply glitches can last a fraction of a microsecond, so you might need a 'scope with a 60mhz or 100mhz bandwidth and turn up the intensity and get the triggering and sweep right to see the spike. Or, a digital scope with ver good glitch capture functions. 2mV of ripple would not be the problem, but there was obviously a problem before you put on the larger filter capacitor. Remember that this chip is writing 264x8 bits all at once when you write to it. That is probably a lot more than the other eeproms you have played with.
Your SHIFTOUT commands are unnecessarily complicated, and that is probably due to the convoluted way that the ATMEL data sheet explains things. But the following single SHIFTOUT statement works across the AT45 family, up to the 8 megabit ('081) density.
SHIFTOUT Dout,sclk,MSBFIRST,[noparse][[/noparse]cmd,ATpage\15,ATadrs\9]
That is, with one SHIFTOUT statement you can send the command, the page number, and the address on the page. Note that the total address length is 15+9 = 24 bits.
Up to 8 Mbit these all have 264 byte pages. At higher densities, the total address is partitioned diffferently, to accomodate 528 or 1056 byte pages, but it is still the same syntax even for those huge arrays, same command set, everything, even for the AAT45DC series in the MMC card format.
You will notice in my examples I use one single subroutine call to send a command and a CASE statement to append the "don't care" clocking bits for the 4 specific commands that require them. BTW, to avoid confusion, all my routines shift the address on the page left one, because I do all the addressing in terms of words, two bytes.
I was wondering why your program sends the data like this: v1,v2,v3,v4,v4,v3,v2,v1, with 1 to 4 and then again 4 to 1?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
I was using v1-v2-v3-v4-v4-v3-v2-v1 as a quick and dirty way to get 8 bytes into the packet, which is what I'll be working with later.· I'll be switching to serin RF data in a day or so and my packet will be:
v1.lowbyte,v1.highbyte,v2.lowbyte,v2.highbyte, packet counter,
HEX2 hrs, HEX2 mins,HEX2 secs.· That's 8 bytes.· incoming RF is kist v1 and v2;· the packet counter and time will be inserted prior to writing to the buffer.
You're right, Tracy - success is good news and it makes me feel good.· Sort of wipes out the 6 days of frustration[noparse]:)[/noparse])
Sid