Hello,

I was confused when reading the datasheet of the Micron Serial NOR Flash Memory.
There is "To avoid data corruption and inadvertent WRITE operations during power-up, a poweron reset circuit is included... ".

After WRITE operations (program or erase sector) to the Flash Memory, it does not respond to any instruction during power-up except READ STATUS REGISTER, I have reset the circuit and the device remains in lock mode. I have to power down the chip to unlock the memory and get correct values (previously written) back from the EPCQL.

The write bytes/erase sector command sequecing is respected and the data read back after power down being as expected.

my question is : Does the logic inside flash memory devices require a power down after each WRITE operation?

Any help or points in a direction would be much appreciated. Thank you in advance

 

Hello,

I was confused when reading the datasheet of the Micron Serial NOR Flash Memory.
There is "To avoid data corruption and inadvertent WRITE operations during power-up, a poweron reset circuit is included... ".

After WRITE operations (program or erase sector) to the Flash Memory, it does not respond to any instruction during power-up except READ STATUS REGISTER, I have reset the circuit and the device remains in lock mode. I have to power down the chip to unlock the memory and get correct values (previously written) back from the EPCQL.

The write bytes/erase sector command sequecing is respected and the data read back after power down being as expected.

my question is : Does the logic inside flash memory devices require a power down after each WRITE operation?

Any help or points in a direction would be much appreciated. Thank you in advance

A link to the datasheet, and your schematic would both be helpful.
It should not require a powerdown after a write operation.

 

Take a look at this brief Technical Note (PDF).

To answer your question:

my question is : Does the logic inside flash memory devices require a power down after each WRITE operation?

I would say that it is not required, but note that:

At power-down, when VCC drops from the operating voltage, to below the POR threshold voltage, VWI, all operations are disabled and the device does not respond to any instruction. The designer must aware that if power-down occurs while a WRITE, PROGRAM,
or ERASE cycle is in progress, some data corruption may result.

Hope it helps.

 

A link to the datasheet, and your schematic would both be helpful.
It should not require a powerdown after a write operation.

@Papabravo and @Raymond Genovese , thank you for responding.

Here is a link to the datasheet : https://www.micron.com/-/media/clie...nor-flash/serial-nor/n25q/n25q_256mb_1_8v.pdf (desciption Power Up and Power Down page 72)

I need to power down the chip because it does not respond to any instruction after write operations. I noticed that there is no data corruption since the data read back after power down being as expected. I think that Write operations lead to a situation similar to "Brownout" : A brownout is when the voltage temporarily drops below the operating voltage level and then recovers.
Here lies my problem: after Write operations, the device is locked , only polling STATUS register is allowed and I can't regain control over the chip until power down. I don't understand why do I have to power down the chip to recover the fully accessible mode?

MOD: Datasheet downloaded & added.E

 

@Papabravo and @Raymond Genovese , thank you for responding.

Here is a link to the datasheet : https://www.micron.com/-/media/clie...nor-flash/serial-nor/n25q/n25q_256mb_1_8v.pdf (desciption Power Up and Power Down page 72)

I need to power down the chip because it does not respond to any instruction after write operations. I noticed that there is no data corruption since the data read back after power down being as expected. I think that Write operations lead to a situation similar to "Brownout" : A brownout is when the voltage temporarily drops below the operating voltage level and then recovers.
Here lies my problem: after Write operations, the device is locked , only polling STATUS register is allowed and I can't regain control over the chip until power down. I don't understand why do I have to power down the chip to recover the fully accessible mode?

MOD: Datasheet downloaded & added.E

Thanks for the datasheet. You are repeating yourself and it is not necessary. Given the complexity of the device, we also need to see a schematic of your setup. Then we may need to examine ALL of the code you have written, to find the problem. I would find it extraordinary for your setup to produce a brownout condition every time you write to the device. I believe the explanation is much simpler, but I can't help if you won't provide the requisite information

 

Why don´t you show your schematic? I bet that the supply voltage is dipping below the treshold during the write op.

 

Did you see the section on p68? Are you exiting the address mode after the write?

 

@Raymond Genovese : I'm working in the 4 byte address mode, this mode is entered following the reset inactivation (write enable followed by 4 byte address enable operations are executed) and I do not need to exist it.

@Papabravo : you’re welcome, please check the attached screenshot given here below, I'm using a developed kit. I am trying to access in read and write my EPCQL-1024 low-voltage quad-serial configuration device (1.8V).

@kubeek : I feel likewise, I think that the write operations lead to voltage issue, I am not sure where to start debugging this.

 

View attachment 168505

 

@Raymond Genovese : I'm working in the 4 byte address mode, this mode is entered following the reset inactivation (write enable followed by 4 byte address enable operations are executed) and I do not need to exist it.

So, what I am saying is that you do need to exit it. Write enable / 4bit address enter / ---/ 4bit address exit / Write disable. Would this be too difficult to try?

My thinking is that you are leaving write enable active because you have not exited 4b address mode and that is why you can't do anything but read the status. But, maybe I am wrong. On the other hand, if the write operations somehow lead to a voltage issue, you would be able to see that pretty easily on a scope, I would think.

Please let us know what happens?

 

Here, read this thread carefully, it is from a different context, but I think it is relevant - especially the part where the participants talk about what micron says to do. Looks like this is an old chip and was meant to be compatible with some others.

 

Once you initiate the self-timed "PROGRAM" operation, how do you determine the success or failure of the operation? Programming a whole page takes several milliseconds accordin to timing parameter tpp. Bit 0 of the status register should tell you that a write is in progress. I usually use a "fail" timeout of 2.5 to 4 times the maximum time for programming a whole page. In the case of a tpp of 5 milliseconds I would use 12.5 to 20 milliseconds to time out the operation.

I agree that a write disable does not seem to be required per the datasheet.

 

Thank you for your answers

@Raymond Genovese : If the problem is that I'm leaving the write enable active, the status register value should tell me that the
WEL (Write Enable Latch Bit) is maintained to 1. I will try to implement this operation. It should be set after the Write operation or the read status. if I will add it as a separated request, it will never be taken since after write operations the device rejects all instructions except RS.

@Papabravo : the read status register returns bit WIP always 0, there is no write cycle in progress. I have tried to use "usleep" to fix the time out operation, I'm providing a correct level shifting and I cant get success too. Although I'm not programming a whole page, I'm sending only 4 bytes to the device to program a single address.

I will inform you , I appreciate you taking the time to assist me thank you again.

 

Just to be clear:

1. You send a one-byte Write Enable command of 0x06, by dropping S#, sending the command bits, and raising S# after the last bit is sent
2. You send a 1 byte page program command of 0x02, by dropping S# sending the command bits, the 3 address bytes, one data byte, and raising S# after the last bit of the data byte is sent.
3. When S# is raised after sending the last bit of the data byte, the self timed write operation takes place.

Review the steps you are taking and ask yourself why the write operation is not even being initiated.

Highest probability guess is the S# is being raised prematurely.

 

I don't know what the problem is, but here are links to a Micron driver source code in C and a tech note documentation for the code (if you do not already have them). Maybe it will help to compare their code with yours (or running their code).

Edit: added better links.
Driver software zip file here: https://www.micron.com/-/media/clie...lash-software/n25q_16mb-1gb_device_driver.zip

Tech note documentation for their code here: https://www.micron.com/-/media/clie...lash-software/n25q_16mb-1gb_device_driver.zip

 

@Papabravo : the write operation sequencing is respected: RS (to verify memory protection status) , Write enable , write memory , continuously RS. I have used simulation model of the Micron chip and simulation result was successful. I have runned a write memory followed by read memory to the same address to check that the data have been correctly written, check the waveform capture attached here (there are model signals)

@Raymond Genovese : Thanks for the sofware drivers, I'll check if I've missed something.