Skip to main content

Memory

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

See More

Dual / Quad SPI Memory

Universal

SPI, Dual, Quad

1.8V, 3.0V. Wide VCC

Ultra-low Energy, Low Power

7nA sleep

Battery monitor

Security

See More

DataFlash SPI Memory

Fast Flexible Robust

Concurrent programming

Easy to use

Power fail protection

Data integrity

Low power modes

Security

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

Memory

1 week ago

AT25SF321 clock problem

Posted by nsanfa 35 points 4 replies
0 upvotes

Hi,

Currently I am working on a project that uses the memory AT25SF321. In some devices the flash operates at 40MHz perfectly and in other devices the flash does not work properly at clock frequencies higher than 33MHz (same hardware and firmware).

For instance, when I read the manufacturer and device ID at 40MHz I get the correct response (0x1F, 0x87, 0x01) from some devices  and from others I get 0x0F, 0xC3, 0x81. Bit wise it seems to be a shift, like the flash is not handling correctly the timing at the start of the response. If I reduce the clock frequency to 30MHz the flash works perfectly. 

The ID (on the chip) of a "faulty" flash and of one that works properly are the same: "adesto1949 25SF321 SSHD". 

Kind regards,

Noe

1 week ago

gordonmacnee 185 points

Hello Noe,

Just checking but do you mean the AT25SF321B - the AT25SF321 (without any suffix) is now End of Life. Either way both parts should have no problem running well in excess of 40MHz.

Would you let us know what voltage you are running these parts at and which micro controller you are using? 

Are you able to have a look at the signal lines with a 'scope and check that you have a fast enough rise and fall on your clock and signal lines and that they are making it above and below the thresholds for the voltage you are using. If you think that they are meeting daatsheet parameters, would you also post the 'scope captures here and we will dig a little deeper.    

1 week ago

Hi,

Thanks for the reply, here are some details:

- The flash is an AT25SF321 (not B).

- The flash memory is controlled by an ESP32-WROOM (configured with SPI full duplex at 40MHz).

- ESP32 and flash run at 3.3V.

- In this case the values read by the esp32 are [0x1F, 0xC7, 0x81] for the command 0x9F.

I attached some captures of the clock (yellow), MOSI (red) and MISO (blue) signals.  "ClkFreq" shows the frequency of the clock, "Clk_MOSI_MISO" shows the three signals (with the 0x9F commad on MOSI) and "MISO_signal" shows the flash response(I am sorry for the image quality, I connected the osciloscope to a screen to take the photos because the osciloscope screen was even worse).

If I set the SPI frequency to 30MHz the flash memory gives the correct ID ([0x1F, 0x87, 0x01]). Also, the devices that work at 40MHz have this problem at 50MHz (same response, same hardware and same firmware). 

After the 0x9F commad there are bytes in the MOSI channel, according to the datasheet the memory ignores the data after the command and it should not be a problem or ¿does it need a 0 after the last bit?

Kind regards.

Attachment Size
MISO channel, response of the flash 150.03 KB
Clock signal 116.47 KB
Clock(yellow), MISO(blue) and MOSI(red) signals (with the command 0x9F on MOSI) 150.41 KB

1 week ago

I managed to make the AT25SF321  flash work at 40MHz after adding a delay of 25ns before reading MISO. Also, the flash memories that work fine at 40MHz doesnt work at 50MHz because that is the upper limit (my mistake, I thought the limit was 55MHz).

accepted answer!

1 week ago

gordonmacnee 185 points

Hi Nsanfa,

The signals on the 'scope images look very rounded with the SCLK looking more like a sine wave... Can you change the output pins to give you a faster rise and fall time or a stronger drive? Looking at the "MISO channel response of the flash" trace and assuming that the first high is the '1' of the '1F' byre in the response then checking every falling edge I read 

...1 1111 1000 0111 0000 0001 = 1F 87 01

Might be the ESP32 is reading too early given the slow slew rate on the clk.

Once any "read" command is complete then any extra "data" sent on the MOSI line is ignored so it does not matter what is in the TX buffer after the command (and address etc) has been sent.