Skip to main content

AT25SL128A Data Corruption on Write


4 months ago

Posted by MortenSchmidt 30 points 3 replies

We are using AT25SL128A and have a problem with data corruption. We use 8MHz plain SPI mode and have also tried 4MHz clock. We operate in SPI mode 3, verified with logic analyzer the SPI format is valid.

One in about 10-50 writes fail our readback test. Subsequent reads produce consistent output, the problem is isolated to the write operations.

The corruption also always results in one or two bits that should be 1 being corrupted to 0. Never the other way around.

The corruption always occurs in the 2nd last byte in a block.

Most of the time only one bit is corrupted but we have sometimes seen two, and when this happens they are two adjacent bits.

We have verified signal integrity. MISO from AT25SL128A has rise and fall times just about 2.2ns without ringing and CLK+MOSI have rise/fall times just about 7ns without ringing. Traces are quite short. Further the fact we have seen two 1's in a row corrupted to two 0's steers suspicion away from a signal integrity problem.

We have also experimented with improved power supply decoupling and even external 1.8V from an independent 1.8V supply, none of this has made any difference.

What could possibly be the problem here?

accepted answer!

4 months ago

gordonmacnee 220 points

My first thought would be ringing or over/undershoot on the signal lines but you have discounted this. 8MHz SPI Clk is considered a slow clock so that should not be a problem. Can you share some more details of your circuit like uController, schematic, Scope captures of the signal lines etc.(send them to so as not to share them on a public forum). Is there anything else on the SPI bus?

How many parts have you tested?

How many boards is this problem being seen on? 

Please use my email to send any info you do not wish to share on the forum.

Note that this is a VERY popular parts with millions of units shipping per quarter and we have not had similar problems reported so we are keen to see if we can resolve this quickly. 

2 months ago

MortenSchmidt 30 points

Hello Gordon,

Thnak you for assisting with this via email. I'd just like to confirm the problem was fixed by optimizing timing of the /CS signal, and the part is now working great in our design.

Best Regards,


2 months ago

gordonmacnee 220 points

Thanks for the feedback - always nice to hear that a problem is solved...