Serial Dataflash Problem

Log in or register to post comments
Go To Last Post
8 posts / 0 new
Author
Message
daveavr
daveavr's picture
Level: Hangaround
Joined: Mon. Jun 9, 2003
Posts: 127 View posts
Location: Auckland,NZ
#1
Posted by daveavr: Wed. Jun 29, 2005 - 03:27 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hey Freaks,

I've run into a strange problem using the Atmel AT45DB161B serial dataflash. Basically im trying to write data to RAM Buffer 2 and then transfer the data into flash page0. Seems simple enough.
However when the RAM Buffer contains 0x00's it seems to get corrupted when its copied to flash Page0. Mostly it ends up as 0xFF's and occasionally 0x00's.

Here's an example...
Contents of RAM Buffer2
0000:01 00 01 02 03 00 01 02 03 00 01 02 03 00 01 02 03 00 01 02
0014:03 00 01 02 03 00 01 02 03 00 01 02 03 00 01 02 03 00 01 02
0028:03 00 01 02 03 00 01 02 03 00 01 02 03 00 01 02 03 00 01 02
003c:03 00 01 02 03 00 01 02 03 00 01 02 03 00 01 02 03 00 01 02
0050:03 00 01 02 03 00 01 02 03 00 01 02 03 00 01 02 03 00 01 02
0064:03 00 01 02 03 00 01 02 03 00 01 02 03 00 01 02 03 00 01 02
0078:03 00 01 02 03 00 01 02 03 00 01 02 03 00 01 02 03 00 01 02
008c:03 00 01 02 03 00 01 02 03 00 01 02 03 00 01 02 03 00 01 02

After copying to Page0. The contents of Page0 are...

0000:01 ff 01 02 03 ff 01 02 03 ff 01 02 03 ff 01 02 03 ff 01 02
0014:03 ff 01 02 03 ff 01 02 03 ff 01 02 03 ff 01 02 03 ff 01 02
0028:03 ff 01 02 03 ff 01 02 03 ff 01 02 03 ff 01 02 03 ff 01 02
003c:03 ff 01 02 03 ff 01 02 03 ff 01 02 03 ff 01 02 03 ff 01 02
0050:03 00 01 02 03 ff 01 02 03 ff 01 02 03 ff 01 02 03 ff 01 02
0064:03 ff 01 02 03 ff 01 02 03 ff 01 02 03 ff 01 02 03 ff 01 02
0078:03 ff 01 02 03 ff 01 02 03 ff 01 02 03 ff 01 02 03 ff 01 02
008c:03 ff 01 02 03 00 01 02 03 ff 01 02 03 ff 01 02 03 ff 01 02

Has anyone come across anything like this before?
Thanks

Dave.

Tags:

AVR Microcontrollers, megaAVR and tinyAVR
Top
petervk
petervk's picture
Level: Rookie
Joined: Fri. Jul 6, 2001
Posts: 20 View posts
Location: Sydney, AU
Posted by petervk: Wed. Jun 29, 2005 - 05:41 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Dave,

Ive just finished a project using the C revision of this device. I had a simiar problem, and it turned out to be the speed I was programming it at. Are you watching the RDY/BUSY line?

Peter

Top
baer.ac
baer.ac's picture
Level: Hangaround
Joined: Sat. Jan 17, 2004
Posts: 171 View posts
Location: Olpe / Germany
Posted by baer.ac: Wed. Jun 29, 2005 - 06:53 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,
The default state of a Flash cell is 0xFF...
if you are too fast, perhaps the Flash couldn't write the data correctly.

Top
daveavr
daveavr's picture
Level: Hangaround
Joined: Mon. Jun 9, 2003
Posts: 127 View posts
Location: Auckland,NZ
Posted by daveavr: Wed. Jun 29, 2005 - 08:45 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

According to the datasheets, the maximum clock frequency is 20MHz.
Im running the AVR with an 8MHz crystal (/2), so I don't think that should be a problem. There's no harm in trying it though i Suppose. Thanks for your input.

Dave.

Top
daveavr
daveavr's picture
Level: Hangaround
Joined: Mon. Jun 9, 2003
Posts: 127 View posts
Location: Auckland,NZ
Posted by daveavr: Wed. Jun 29, 2005 - 09:19 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I've now tried it at 8MHz /128. Still the same problem.... :?

Top
glitch
glitch's picture
Level: Raving Lunatic
Joined: Sat. Jan 12, 2002
Posts: 8620 View posts
Location: Canada
Posted by glitch: Wed. Jun 29, 2005 - 09:37 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It's likely NOT the SPI clock speed that's the problem (as the clock only runs when data is being transferred over the spi bus).. It's your SS# inactive time that likely is. You have to be very careful about what commands you issue, while the part is busy writing to flash. Also make sure you use the write, with built-in erase, unless you know the page is fully erased already. I strongly suggest monitoring the Busy pin, and not accessing the flash until busy is released. (at least for a start)

Another test, would be to write to the page buffer, and then read it back, without committing it to flash. If it doesn't read back properly, you likely have a SPI transfer problem.. If it does read back properly, then you have a timing problem, and you are likely causing the dataflash write to get corrupted/aborted.

It's been a while since I've worked with one of atmels data flashes, but be sure to respect the SS# assertion/de-assertion holdoffs, with respect to transactions, and clock and data valid signals. you may need to add some NOP's from when you assert, to before you actually send data, and vice versa. you may also want to make sure there a few cycles from when you de-assert #SS to before you assert it again.

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

Top
daveavr
daveavr's picture
Level: Hangaround
Joined: Mon. Jun 9, 2003
Posts: 127 View posts
Location: Auckland,NZ
Posted by daveavr: Wed. Jun 29, 2005 - 11:28 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Glitch,

Thanks for your comments. I am using the program with built in erase command (0x86...). I can read and write to the RAM buffers without any problems.
All SPI commands are initiated by commands that are received on the UART so there's no chance of the dataflash being accessed during the write period. I've verifyed this by monitoring the Ready/Busy line and the CS on the scope. All the other timing looks ok as well. The CS is low for about 3.2us before the data is clocked in, and it stays low for about 6.4us after the last byte is clocked in. The specs say its should be at least 250ns.
The strange thing is that the transfers work perfectly for data other than 0x00.

Dave

Top
daveavr
daveavr's picture
Level: Hangaround
Joined: Mon. Jun 9, 2003
Posts: 127 View posts
Location: Auckland,NZ
Posted by daveavr: Fri. Jul 1, 2005 - 03:09 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Problem Solved!!! :P
I noticed that the 3.3V supply wasn't looking too great during memory transfers. So I added a 2.2uF cap along with the 100nF decoupling cap. Now that supply looks good and memory doesnt get corrupted! I guess writing a heap of zeros takes more current...

Dave

Top