Skip to main content


Dialog Improves System Performance

Non-volatile memory (NVM) is a key component at the heart of every system design. It holds critical data, controls how the system boots, and affects overall performance. Choosing the right NVM is key. We’re here to help. Our wide range of NVM products offer an array of features designed to help tune and optimize your system.

Octal xSPI Memory


xSPI (8x SPI)

High bandwidth

Low power

eXecute-in-Place (XiP)



See More

Dual / Quad SPI Memory


SPI, Dual, Quad

1.8V, 3.0V. Wide VCC

Ultra-low Energy, Low Power

7nA sleep

Battery monitor


See More

DataFlash SPI Memory

Fast Flexible Robust

Concurrent programming

Easy to use

Power fail protection

Data integrity

Low power modes


See More

Wafer KGD

Known Good Die program

Up to 125°C operating temperature

All voltage levels

  • 1.8V
  • 3.0V
  • Wide Voltage 1.65V to 3.6V

See More

Verified Memory for NXP

Low Power and high-speed SPI Flash solutions for NXP i.MX RT MCUs

See More

Verified Memory for ST Microelectronics

Dialog SPI Flash solutions verified on over 30 STM32 MCUs

See More

CBRAM Technology

CBRAM is a resistive RAM technology that provides power, speed, and cost benefits over other non-volatile memory technologies. It is well suited for battery powered devices, edge computing, and AI applications.

See More

Stay connected

Get in touch with us directly through our worldwide sales offices, or contact one of our global distributors and representatives.

Inquiries Distributors and Representatives Register for newsletters
Back to results


2 weeks ago

AT25SL128A went into protected sector state

Posted by ArunH 95 points 7 replies


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



1 week ago

gordonmacnee 220 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. 

1 week 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!


1 week ago

gordonmacnee 220 points

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


1 week 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.



1 week ago

gordonmacnee 220 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?


1 week 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.



1 week ago

gordonmacnee 220 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.