Skip to main content

Micron M25P M25PE M45PE Replacements

Micron Replacements

We offer highly compatible solutions for the designer, component engineer and sourcing teams that are rapidly moving to replace Micron NOR Flash products and avoid potential price instability and supply shortages that could impact their production.

DATAFLASH (AT45 Series), DATAFLASH-L (AT25PE Series) and FUSION (AT25 Series) families offer price and long-life supply stability with exact-match pin out and performance to the Micron selection.


Highly-compatible, including exact-match replacements to Micron EOL products

Included in Dialog's memory longevity program to ensure supply security and stability

Superior product performance and command sets

Micron M25PE Replacements

Density Product / Datasheet Speed Vcc range Interface Details Status Samples
16Mbit AT25PE16 85MHz 2.3V-3.6V SPI   ● Active Order Samples
8Mbit AT25PE80 85MHz 1.7V-3.6V SPI   ● Active Order Samples
4Mbit AT25PE40 85MHz 1.65V-3.6V SPI   ● Active Order Samples
2Mbit AT25PE20 85MHz 1.65V-3.6V SPI   ● Active Order Samples
AT25PE16 details
Ordering Code Package
AT25PE16-SHN-B SOIC 208MIL 8S2 8
AT25PE16-SHN-T SOIC 208MIL 8S2 8
AT25PE16-MHN-Y UDFN 8MA1 8 - 5x6
AT25PE16-MHN-T UDFN 8MA1 8 - 5x6
AT25PE20 details
Ordering Code Package
AT25PE20-SHN-B SOIC 208MIL 8S2 8
AT25PE20-SHN-T SOIC 208MIL 8S2 8
AT25PE20-MHN-Y UDFN 8MA1 8 - 5x6
AT25PE20-MHN-T UDFN 8MA1 8 - 5x6
AT25PE40 details
Ordering Code Package
AT25PE40-SHN-B SOIC 208MIL 8S2 8
AT25PE40-SHN-T SOIC 208MIL 8S2 8
AT25PE40-MHN-Y UDFN 8MA1 8 - 5x6
AT25PE40-MHN-T UDFN 8MA1 8 - 5x6
AT25PE80 details
Ordering Code Package
AT25PE80-SHN-B SOIC 208MIL 8S2 8
AT25PE80-SHN-T SOIC 208MIL 8S2 8
AT25PE80-MHN-Y UDFN 8MA1 8 - 5x6
AT25PE80-MHN-T UDFN 8MA1 8 - 5x6

You can no longer post questions or comments on this page. All product forum activity on the Dialog Semiconductor website are being migrated to a new platform called RenesasRulz communicated to users 4 May. Renesas Electronics Corporation (“Renesas”) will be the service provider and processor managing this move on behalf of Dialog Semiconductor PLC. (“Dialog Semiconductor”). In due course you will receive a welcome email from Renesas providing detailed information on accessing your new RenesasRulz account.

Back to results


4 months ago

AT25SL128A went into protected sector state

Posted by ArunH 97 points 8 replies
1 upvote


I have a design based on AT25SL128A. I started with the standardflash.c and tests for it from the Adesto github website and all tests pass. So I assume my SPI integration is fine on my MCU.

I then set it running for a longer test so that it would keep writing/reading back data and then wrap around to the start of memory. Then I erase the 4K sector to reclaim it for writing.

However when I read back data after the wrap followed by 4K erase, I found I was always reading all 0s. Further check revealed that Status Register 1 value was 0xFC which means all the protect bits were set to 1.

Q1: This was not done by me, so I am wondering if you have any suggestions on whether the flash might go into this state on its own due to any trigger?
Q2: Or can it only happen if the MCU wrote this value to it?

Note1: I was able to recover back to working state by writing a new value to Status Register 1 but I want to check how to avoid this in the future.

Note2: Status Register 2 was 0x00, which is the default value. It did not change.


- Arun



4 months ago

gordonmacnee 225 points

Hello Arun,

I have not used the drivers from GitHub myself but have worked with the AT25SL128A and it should NOT protect itself. Are you able to break your test down to see when the STATUS reg 1 is being changed? I will also ask some of our SW engineers if they have seen any issues with the drivers. 

4 months ago

Hi Gordon,

The github drivers and tests themselves seem perfectly fine.

The odd part is that this happened only on wrap back to the first sector, which is why I thought I'd ask the question i.e. if an already-written sector needs to be unprotected before erase or write or read.

This did seem unlikely but this is the first time I am using this flash part, so I though I'd ask.

I have not been able to repeat this yet but it happened on two units, and both on wrap around.

I will try to get more info if this situation repeats.

Thanks for your reply!


4 months ago

gordonmacnee 225 points

Would you give me a more in depth description of the 'wrap around' condition? 


4 months ago

Hi Gordon,

By "wrap-around" I mean that I write data (and read lags behind data) till the end of the flash memory and then I wrap back to the start of the flash. So as I have already written data there before I have to erase that 4K sector (4K sector number 0), before I can write to it again.



4 months ago

gordonmacnee 225 points

Hi ArunH,

Just speaking with one of our SW team. These drivers were written by an intern to help us demo our flash parts and were tested on NXP and ST controllers. Note that these drivers use a 'bit banging' method where IO pins are used to simulate SPI hardware. This makes them slightly slower and does not make best use of available SPI bus hardware. That said, they should work on any controller and should NOT protect the Flash without the host program requesting this. 

Would you let us know which processor you are using as well as more info on when this 'wrap around' occurs?


4 months ago

Hi Gordon,

I am not using the bit-banging technique from the driver, I replaced that with SPI code from the MCU I am using (SiLabs EFR32BG22). In general this works fine, not really found any issues except this one case. Sorry, I forgot to mention this before, I am using standardflash.c unchanged, interfaced to MCU SPI code.

The wrap-around is the case when writing to the end of flash (16MByte limit) and then going back to address 0 or 4K sector number 0. The readback of data failed i.e. only 0s were read back and not the real data. I cannot say if the write failed and wrote 0s or the read failed and read 0s.

Thanks for confirming that this is not expected on the flash without the host program actually commanding this, regardless of the driver used. This is really what I wanted from your side.



4 months ago

gordonmacnee 225 points

Thanks for the feedback. I will leave this parked for the moment but feel free to open this thread again if there are more issues.

1 month ago

wouter_palmsens 5 points

I have experienced the same or very similar behavior using the AT25SF128A. I was using my own code (not the code from GitHub), which had been working on our first prototype for weeks. During testing on the final product, one of the flash devices got wrote protected somehow (Status Register 1 value was 0xFC). My code did not include any "Write Status Register" command, and I'm completely unaware of what triggered the write protection. After clearing the Status Register it was possible to write to the flash again, but I still don't understand why this was necessary.