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 month ago

AT25DF641A Trouble programming the memory

Posted by shreyasbkulkarni 90 points 30 replies
0 upvotes

I'm having difficulty with AT25DF641A - the 64 Mbit SPI serial memory. We have a mature design that is based on an older, now obsolete version - the AT25SF041 which was a 4 Mbit memory. The 2 devices seem pin compatible and are almost supported with the same command and memory structures.

 

On the AT25DF641A, I'm having difficulty writing data into the memory locations. Here are the steps I'm following - 

1) I'm resetting the chip to begin my process. I start this by writing 0x31 and 0x10 to the status byte 2. This allows the device to get reset (RSTE bit = 1). I ensure that the WP_ pin is high when doing this operation. When the device is reset, the Status Registers read as follows - 
Byte 1 = 0x1C
Byte 1 = 0x00

2) I then unprotect the flash globally by writing 0x00 to Status Register Byte 1 (keeping WP_ high during this time). However, reading the status register after this operation results in the same 0x1C and 0x00 values.

3) My next step is to pick an address, and erase the 4K block. I do this by ensuring that the particular memory location's sectors are not protected or locked. I clock in 0x03C (for reading sector protection register) and 0x35 (reading sector lockdown register) which all return 0x00 for both cases. I then do the 4K erase by doing a write enable first (WP_ is high and I clock in 0x06. When write enable is executed, the status register reads byte 1 = 0x1E, byte 2 = 00.

Then the 4K erase is performed by clocking in 0x35 (adn WP_ is kept high during the operation), followed by the 3 byte address. The status register reads 0x1C, and 0x00 after the erase.

4) After the 4K block erase, I'm writing my data to the location, by

a) Doing a write enable (WP_ kept high)
b) Clocking in 0x02, followed by 3 byte address (again WP_ high)

Upon reading the same location, I get 0xFF as the value, which means my write failed.

Anything obvious that I may be missing/overlooked? I know it is hard to tell without the code and actual logs, but any insight will be super appreciated!

One thing that is obviously bothering me is that I am unable to get the status register bytes to read (byte 1 =) 0x02 and (byte 2 = ) 0x00. My status register byte 1 always toggles b/w 0x1C and 1E, i.e. SWP bits are always 11 (default- all sectors protected) but when I do read the protection/lockdown status, they read 0x00.

Please help!

Shreyas K.

1 month ago

gordonmacnee 185 points

Hello Shreyas,

Have you tired more than one device and have seen the same results?

I assume you are sending a WEL (0x05) command before 0x31 0x10?

I need to order a couple of samples of this part and I'll be able to come up with a full sequence to unlock this for you. Please give me a few days to respond.

Gordon 

 

 

1 month ago

shreyasbkulkarni 90 points

Gordon, thanks for getting back to me!

I have tried 2 devices and getting the same results. Actually, there was an error on my part in parsing the Status Bytes 1 and Byte 2. My actual problem is that whatever I do, I cant get the Status Byte 1 to change from 0x00 to anything (even if I issue a write enable command etc.). The Status Byte 2 toggles between 0x14, 0x16 and 0x1C which is very confusing.

About your comment regarding issuing a WEL (0x05) command before 0x31, 0x10 - I did not see this in the datasheet. 0x05 seems to be for reading the status register. Can you confirm?

I'm not sure how this works, but if we can troubleshoot "live" maybe through a conference call or something, that would be great!

 

Thanks

Shreyas

 

 

 

1 month ago

gordonmacnee 185 points

My mistake on the Write Enable command -should be 0x06 before a write to the status registers

What SPI clock frequency are you using? 

Would you be able to read the status Byte 1, then send the Write Enable command, then read the status reg again and report this back to me? 

Thanks

1 month ago

shreyasbkulkarni 90 points

Hi Gordon, thanks!

I’m using SPI clocked at 4 MHz

Here’s what I’m doing every time I perform a “write enable” –

  1. Pull WP_ to high
  2. Read the status register (full register, byte 1 and byte 2). I do this by clocking in 0x05 and then I’m reading 4 bytes just to make sure I’m reading correctly. The datasheet says the bytes will repeat as <byte1, byte2, byte1, byte2…>. The value I get here is 0x0014. This means byte 1 = 0x00 and byte 2 = 0x14.
  3. I then clock in 0x06 to do write enable.
  4. After that, I read the status register by performing step 2 again. It reads 0x0016 this time, so byte 1 = 0x00 and byte 2 = 0x16. So the WEL bit is not getting set to 1 but I don’t understand why.

I’m able to read the manufacturer ID (0x1F480001) correctly, so I think my low level SPI drivers for sending/receiving bytes is working fine. And this is based on legacy code that we have had in production since 3+ years, based on the earlier AT25SF041, so not sure what else can be going wrong.....

Thanks
Shreyas

1 month ago

gordonmacnee 185 points

Hi Shreyas,

I would have expected that sequence to work. I am expecting some samples of this part to arrive today or Monday and will be able to confirm how to access to AT25DF641A. I am assuming this is an upgrade to an existing design and I assure you that there are no plans to remove or End of Life the DF641A BUT we do have the AT25SF641B which is built on a smaller and more up to date process may be a better device for any new design...   

I will contact you as soon as I have my samples and have some results.

1 month ago

shreyasbkulkarni 90 points

Thanks Gordon, 
Appreciate it!

4 weeks ago

shreyasbkulkarni 90 points

Hello Gordon
Just checking in - were you able to re-create the issue and see what's happening?

Staying tuned for updates.

 

Thanks!

4 weeks ago

gordonmacnee 185 points

sorry Shreyas,

Yes - have completed initial testing on a fresh AT25DF641A.

Read the Manufacturer's ID  - 1F 48 01

Read the STATUS Reg - 1C 00 

Clear the STATUS reg by sending WE (0x06), take /CS high between commands, and then send 0x01 0x00 to write 0x00 to Stat Reg

Read the STATUS Reg - 10 00

I can now erase and write to the memory.

Attached are the logic captures for the three sequences 

 Hope this helps...

Attachment Size
STAT READ 1 123.07 KB
STAT READ 2 81.75 KB
STAT WRITE 86.52 KB

3 weeks ago

shreyasbkulkarni 90 points

Gordon thanks for trying this out! I appreciate the help.

I have several questions though - 

When you first read the STATUS register, you got 0x1C00 correct? From the datasheet and your logic captures, the STATUS byte 1 = 0x1C and STATUS byte 2= 0x00. This means that the device has following configuration - 

Bit 7 - 0 => Sector protection registers unlocked (default)
Bit 6 - 0 => RES
Bit 5 - 0 => Erase/Program successful
Bit 4 - 1 => WP_ deasserted
Bit 3 - 1 
Bit 2 - 1 => All software sectors protected (default)
Bit 1 - 0 => Device not write enabled
Bit 0 - 0 => Device ready

Then you performed Write Enable (0x06) and then sent {0x01, 0x00}. This means you overwrote STATUS Byte 1 to be 0x00. But the logic capture still reads new STATUS register as 0x10 00, meaning STATUS Byte 1 is - 

Bit 7 - 0 => Sector protection registers unlocked (default)
Bit 6 - 0 => RES
Bit 5 - 0 => Erase/Program successful
Bit 4 - 1 => WP_ deasserted
Bit 3 - 0 
Bit 2 - 0 => All software sectors unprotected
Bit 1 - 0 => Device not write enabled
Bit 0 - 0 => Device ready

However, if the bit 1 (WEL) is still 0. How were you able to write to the memory in this state?

 

-Shreyas

 

3 weeks ago

gordonmacnee 185 points

Hi Shreyas,

The WE bit is always cleared after an operation that requires it to be set. So if I read the status reg after power up, I read 0x1c for STATUS1 but this becomes 0x1E after sending WE command and then to 0x10 after I send the 0x01 0x00 write to status reg command. 

3 weeks ago

shreyasbkulkarni 90 points

Got it.

I'm doing the exact same things that you mentioned but I just am unable to write to the memory. I even read the LOCKDOWN and PROTECTION registers to be all 0x00 but I cannot seem to write and ensure the write was successful. Hitting a brick wall.

Our devices are in production and we are in a bit of a crunch.

Any other way we can troubleshoot this?

Again, thanks for all the help!

3 weeks ago

gordonmacnee 185 points

Would you let us know where you got these devices and how many you have? If you can also include images showing the text on the top and bottom sides of the devices, we can check that these are valid Adesto devices. If you can provide some 'scope captures of the sequences or logic analyser captures I can see if there are any timing violations. We have sample stock of the AT25DF641A-MH-Y Adesto Sample Center (samplecomponents.com) which you can order. These parts will solder down on to a narrow body SO footprint and allow you to confirm that the problem is with the devices you currently have or with the drivers...    

3 weeks ago

shreyasbkulkarni 90 points

Hi Gordon

The ICs have the following text written on them -

adesto2125
25DF641A
SH

I have attached a picture of the device.

We sourced them either from https://www.win-source.net/adesto-technologies-at25df641a-sh-t.html or from Farnell, not entirely sure, as everything else was out of stock. I'm not sure which supplier the PCB house finally used....

I need to do the logic/waveform capture and analysis, but the issue is that the board is a production version and I cant really probe the signals very well to capture good waveforms. Ill try that as the next step.

 

 

Attachment Size
Adesto.jpg 1.09 MB

3 weeks ago

gordonmacnee 185 points

Hi Shreyas,

I need to markings on the backside of the chip as well. Once we have this we can confirm that these are genuine Renesas parts. Please keep the removed device to one side and you can ship it back to see if I can replicate the problem here. Please also send some 'scope captures showing the /CS to first SCK (to check timing) and an overview of the write to flash sequence.

Thanks   

2 weeks ago

shreyasbkulkarni 90 points

Hello Gordon

I was able to do some probing on the SPI bus and get nice screencaps. BTW, I got inspiration from you to use the DSLogic Analyzer, so thanks for that!

Image 1 - I'm reading the Manufacturer ID by clocking in 0x9F and reading 0x1F48000100

Image 2 - I'm doing write enable by first reading the Status byte (reads 0x1000), then clocking in WE command (0x06) and then writing 0x00 to status byte 1 (clocking in 0x01 00).

Image 3 - This shows what the status register reads immediately after the above step. It still reads 0x1000 which means my writing 0x00 to status byte 1 failed... 

 

Am I doing something obviously wrong?

I have the setup ready and I can do a debug session or more investigation as you suggest, if you can think of anything!

Thanks

Shreyas

Attachment Size
Image 1 - Read MFG ID 135.53 KB
Image 2 - Write Enable Process 148.46 KB
Image 3- Status after WE 112.82 KB

2 weeks ago

gordonmacnee 185 points

Hi Shreyas,

All the signals look correct - just an incorrect response

I need to markings on the backside of the chip. Once we have this we can confirm that these are genuine Renesas parts. Please keep the removed device to one side and you can ship it back to see if I can replicate the problem here. (I love my DS Logic Analyser - it has solved a lot of problems for me...)

Please send me an email to gordon.macnee.wj@renesas.com and I'll send over my address for the sample once we verify it is genuine.

Thanks   

2 weeks ago

gordonmacnee 185 points

Just one more idea would you capture a STATUS READ just after sending Write Enable? You should see bit 1 set in the status reg... 

2 weeks ago

shreyasbkulkarni 90 points

Something very weird is happening - 

On doing the following - 

Read MFG ID - OK

Read Status - 0x9C 18

Do WE and read Status - 0x9E 18 ------> ie bit 1 of byte 1 is set (WEL bit)

Write 0x10 to byte 2 and read status - 0x9C 10 ------> ie successfully wrote to byte 2 of status

Why does it work now? Is there a particular sequence I'm supposed to follow that I'm missing? Sorry but I'm a bit lost since this was supposed to be a simple drop in replacement from our legacy version....

 

Shreyas

 

Attachment Size
Read MFG ID and Status 136.6 KB
Send WE and read Status 130.03 KB
Write Byte 2 and read Status 141.26 KB

2 weeks ago

gordonmacnee 185 points

As I mentioned earlier, 

Read the Manufacturer's ID  - 1F 48 01

Read the STATUS Reg - 1C 00 

Clear the STATUS reg by sending WE (0x06), take /CS high between commands, and then send 0x01 0x00 to write 0x00 to Stat Reg

Read the STATUS Reg - 10 00

You should not have to read the status reg after WE command. I also don't know why bit 7 is now set...

Can you now write and erase the device? 

2 weeks ago

shreyasbkulkarni 90 points

Gordon, thanks.

I re-did the driver and stripped it down to the bare minimum that you suggested above. Here's the new sequence and test result - 

Part A - Initial Configuration

1) Read MFG ID - 0x01F4801

2) Read Status - Reads 0x1000

3) Do WE by clocking in 0x06. Write 0x00 to status byte 1, by sending 0x01 0x00

4) Read Status - Reads 0x1000

Part B - Block Erase

1) Read sector lockdown register - Reads 0x00

2) Read sector protection register - Reads 0x00

3) Do WE by clocking in 0x06

4) Do Block erase by clocking in 0x20, followed by address <0x0E A0 00>

Part C - Read/Write/Read

1) Read a location in the erased block to make sure it is 0xFF - Clocked in 0x0B, <Address>, 0x00 dymmy and read data to be 0xFF

2) Do WE by clocking in 0x06

3) Unprotect sector - Clock in 0x39, followed by address

4) Do byte program - Clock in - 0x02, <Address - 0x0E A0 5F>, <Data 0x7F>

5) Read same address - Clock in 0x0B, <Address>, 0x00 dummy to read the same value (0x7F) as above

Attaching a screenshot of above transaction

 

Part D - Unsuccessful Write/Read - 

Tried programming a different location (0x0E AE A6)

1) Do WE

2) Unprotect the sector - 0x39, <Address>

3) Do WE and write data - 0x02 0x0e AE A6 0xF4

4) Read - Read data does not match

Attaching a logic capture for this, The initial WE is out of the frame but it was done before sending the unprotect command.

 

Seems I may be doing something wrong in configuration or commanding. Any suggestions? Are there any timing violations?

 

Best,

Shreyas

Attachment Size
Part C 145.8 KB
Part D 148.96 KB

2 weeks ago

gordonmacnee 185 points

Are both parts behaving the same?

After every operation that requires WE, would you read the status registers (this does not clear the WE bit) 

1) Read MFG ID

2) Read Status - should Read 0x1C00 after power up 

3) Do WE by clocking in 0x06.

4) Read Status Reg - should read 0x1E

5) Write 0x00 to status byte 1, by sending 0x01 0x00

4) Read Status - should Read 0x1000

Part B - Block Erase

1) Read sector lockdown register - Reads 0x00

2) Read sector protection register - Reads 0x00

3) Do WE by clocking in 0x06

4) Read Status Reg - should read 0x1200

5) Do Block erase by clocking in 0x20, followed by address <0x0E A0 00>

... test write and read operations

I think the next step will be get these parts back for a deeper investigation. Would you send me your company email address and I'll send details on how we start this process.

Please send this info to gordon.macnee.wj@renesas.com

2 weeks ago

shreyasbkulkarni 90 points

I'll modify my WE command so that it reads the status register right after the transaction so I can post screen caps here tomorrow.

 

I sent you an email on your address. Did you get it?

 

Shreyas

2 weeks ago

shreyasbkulkarni 90 points

Update - 

Modified the WE command to read status right after doing WE. It always reads 0x1200.

 

For some addresses, the write is working but not for all, even though the code is the same and addresses are generated at random. Also, I always do WE, then "unprotect" the address before doing WE and writing to them. I also built in commands to ensure the Lockdown and Protection registers are reading zero before writing to the address. Attaching 3 instances when the write worked but it failed right after...

 

At this point, I think I want to send you the memories to see if something else is going on....Can you please send me details on how to proceed?

Thanks!

Shreyas

Attachment Size
Successful Write 1.JPG 203.33 KB
Successful Write 2.JPG 196.44 KB
Successful Write 3.JPG 196.44 KB
Failed Write.JPG 247.24 KB

1 week ago

gordonmacnee 185 points

incase the email failed see the form discussed here 

1 week ago

shreyasbkulkarni 90 points

Hi Gordon
No still ddnt rcv it but I'm going to chat with our IT admin to see what's happening

Can you link the form again? There's no link in the comment above.
Thanks!

1 week ago

gordonmacnee 185 points

Hi Shreyas,

I have attached the word doc in a macros disabled version. Let's see if this get through...

Attachment Size
CFR0227_V7_ComplaintRequestForm.docx 75.24 KB

1 week ago

shreyasbkulkarni 90 points

Worked! I'll fill it out and email it to you

Thanks

1 week ago

gordonmacnee 185 points

:)

1 week ago

shreyasbkulkarni 90 points

Sent the form! Hoping you received it haha!

1 day ago

shreyasbkulkarni 90 points

Hi Gordon

Any news on this front?

When/where can I ship the samples?