0
\$\begingroup\$

I am using an AT45DB081E 8-Mbit flash from Adesto (formerly from Atmel). I am storing 7-byte data records and keep the location of the newest record stored in the last page of flash. This value is occasionally read (about every 5 minutes) to see if it is different from the address of the next data record to be written. This allows the microcontroller to check if any new data has been written to the flash or not.

The issue I'm running into is occasionally the location of the newest pointer is read incorrectly. I'm wondering if reading from the same location over and over is causing some buildup of charge and contaminates the flash cells, but I didn't think flash memories had any limits on read operations. I have submitted a support ticket to Adesto, but have yet to hear back.

Has anyone else run into this issue? What have you done to work around it? For now, I am reading the newest record location twice and making sure the values are the same. All this did was give less of a chance of seeing the problem, but it still occurs (just less frequently).

\$\endgroup\$
7
  • 1
    \$\begingroup\$ Write has limited life, worse if to same location. Hence, leveling software. ATMega328 is 100,000 life as data sheet. Read should be not much harm as no high voltage strength field is used as in erase and then write. \$\endgroup\$
    – EEd
    Commented Aug 19, 2014 at 16:36
  • \$\begingroup\$ I'm using a dev board and am wondering if during the development process I have written too many times to this location. Perhaps I should try another dev board that hasn't been used as much. \$\endgroup\$
    – Oilyraincloud
    Commented Aug 19, 2014 at 16:43
  • \$\begingroup\$ Maybe a slab of FRAM or a few expendable 25XXs can help you find the problem. \$\endgroup\$
    – Ignacio Vazquez-Abrams
    Commented Aug 19, 2014 at 17:03
  • 1
    \$\begingroup\$ It's possible, but unlikely unless you were writing in a tight loop. More likely is something unreliable about your read scheme - poor timing margins between SPI clock and data? Analog issues? Bad connection? Missing power or ground? \$\endgroup\$
    – Chris Stratton
    Commented Aug 19, 2014 at 17:03
  • \$\begingroup\$ @ChrisStratton That could very well be it, but I've only noticed this issue at this very specific location. I've never seen a 7-byte data record or anything else come out as something unexpected, but they aren't read as frequently either. In terms of writing in a tight loop, I wonder if my development environment (Rowley Crossstudio for MSP430) did some strange things when I was originally testing my flash read/write/erase methods - or perhaps some bad development/testing habits of my own. \$\endgroup\$
    – Oilyraincloud
    Commented Aug 19, 2014 at 17:10

2 Answers 2

Reset to default
2
\$\begingroup\$

If it's not a persistent corruption of memory, I would assume it's either a software problem or a timing/sequence problem of some type.

If you're reading the location in an ISR, or if ISRs are doing anything remotely related to the pins used for communication with the SEEPROM, I would look very carefully at that as a potential source of problems.

\$\endgroup\$
3
  • \$\begingroup\$ This is now what I'm suspicious of. Might be time to scope out the signals. \$\endgroup\$
    – Oilyraincloud
    Commented Aug 19, 2014 at 18:25
  • \$\begingroup\$ That will find it if its a straightforward timing issue. If it's a timing issue with ISRs interacting with other parts of your program you might have trouble catching it with a scope. A logic analyzer or just poring over the code might work better. \$\endgroup\$
    – Spehro 'speff' Pefhany
    Commented Aug 19, 2014 at 20:01
  • \$\begingroup\$ Another problem is how intermittent it is. Since posting this question, I haven't been able to reproduce the problem. I usually have to keep things running overnight and check the next morning. Makes it seem more likely that it is an ISR problem. \$\endgroup\$
    – Oilyraincloud
    Commented Aug 19, 2014 at 20:13
1
\$\begingroup\$

No, reading the same page again and again does not alter its value on flash. Even after hundreds of thousands of reads, the value isn't corrupted. You should look for other failure sources (such as EMC, preemption, operations while busy, ...).

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.