内存
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
Hi-Performace
xSPI (8x SPI)
High bandwidth
Low power
eXecute-in-Place (XiP)
Read-While-Write
Security
Dual / Quad SPI Memory
Universal
SPI, Dual, Quad
1.8V, 3.0V. Wide VCC
Ultra-low Energy, Low Power
7nA sleep
Battery monitor
Security
DataFlash SPI Memory
Fast Flexible Robust
并发编程
Easy to use
Power fail protection
Data integrity
Low power modes
Security
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
Verified Memory for ST Microelectronics
Dialog SPI Flash solutions verified on over 30 STM32 MCUs
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.
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内存
3 months ago
AT25SL128A went into protected sector state
Posted byArunH97 points 8 repliesHello,
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.
Thanks!
- Arun
3 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!
3 months ago
Would you give me a more in depth description of the 'wrap around' condition?
Thanks
3 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.
Thanks,
Arun
3 months ago
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?
问候
3 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.
问候,
Arun
3 months ago
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 week ago
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.
3 months ago
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.