Can you please let us know the RSR1 values after SE. Are you polling for WIP bit and ensuring that the sector erase is finished before PP.
You mentioned that WEL is not present after WREN what do you mean by WEL not present ?
In page programming the CS# pin must be driven high after the eighth bit of the last byte has been latched. If this is not done the Page Program command will not be executed. Are you making CS # high ?
Can you please check the value of P_ERR bit (SR2V). It will indicate if an error occurs in the programming operation that prevents successful completion of programming.
Just to confirm are you sure that the sector is not protected ?
No errors in SR2, at anytime. WEL bit seems to be behaved and responds to WREN's. WIP bit present for the appropriate amount of time after a SE4, PP4. CS hi / lo per the instructions.
I changed to 4 byte instructions and addressing. That caused it to perform some kind of a writes and does sector erase, but it writes consistently correctly sized gibberish. I suspect its locked into quad mode... or something as its only reading half the data it gets.
All commands and signals verified on the wires confirmed with Saleae logic monitoring. tried a 2nd chip as well.
Something is not correct here....
1 of 1 people found this helpful
"I suspect its locked into quad mode... or something as its only reading half the data it gets."
Are you able to read half the data correctly ?
Please let us know which sector you are trying to program and facing the issue. Is it first sector ?
Can you try writing to some other sectors and check if you are observing the same issue.
What is the frequency you are operating. ? are you providing the correct dummy cycles as provided in table 16 of the datasheet ( page 37).
Are you migrating from any of our older device or is it new design ? If you are migrating please let us know the which part you are using earlier.
Hi, well success at last.
To your questions - 2 Mhz on a test board, single byte mode, and no extra latency reads needed. Sector 0, Used the P series before, moving to the L series now.
The first chip was bad and did erratic things. In both chip 1 and 2,, the legacy 3 byte addressing and commands never did a proper write, although the reads were probably OK, but how can one tell when its all 0xFF's. I'm suspicious of an apparent reliance that requires an SR2 read to be performed after the write command, but before the write is fully committed / actioned in the chip.
But it works now including Security Region and its Lock Bits.
The docs could do with a nice introduction section, describing the shipped default state of the chip, what features are on and what is not on. That would save me wading through 150 pages of stuff.
Glad the issue is resolved. Just for your information :
We have Migration application note from FL064P to FL064L. Please refer the link below :
Are you using 64Mb density device in FL-P series or any other density ?
We will try to incorporate your suggestions .
Can you please let us know what changes you did so that you are able to solve . Is it related to initial delivery state of FL-P and FL-L device ?