Hi,
Currently evaluating this FLASH and attempting to lock registers using the WP# pin, however it's not working as advertised.
Using the WRR command I am able to set SRNV-1[SRWD]=1, which now should follow WP#. I power cycle and can verify
that it is set via UBOOT console using RDSR-1.
What I expect to happen is that if I ground WP# I should NOT be able to change SRNV1, however I am able to toggle this
register even with the pin grounded. What am I missing? Thanks in advance.
Solved! Go to Solution.
Ok,
Believe we have found the issue, but still don't understand this fully. Our LINUX target boots up in single mode (MISO/MOSI), but when the kernel gets a hold of it, it runs in QUAD mode.
Somewhere along the way, it must have written to CRNV1 and set the QUAD_NV bit for QPI mode. This apparently has no effect on single mode operation, however it seems to prevent IO2 and IO3 to operate as WP# and RESET respectively. Once this was cleared, the write protection worked as expected.
Hi Keith zambrano,
Could you please share the top markings of the failing units with us?
Thanks and Regards,
Sudheesh
Sorry,
Posted to myself. Please see attached JPEG.
Ok,
Another set of eyes looked at the spec, that makes 3 of us trying to figure this out. Section 5.4.2 shows a timing diagram for WP#, which depending how you look at this, implies that the WP# has to be toggled with every WRR/WRAR instruction. Can you please confirm?
Much Gras!
Hi Sudheesh,
Thanks for the reply. Attached is a JPEG
Ok,
Believe we have found the issue, but still don't understand this fully. Our LINUX target boots up in single mode (MISO/MOSI), but when the kernel gets a hold of it, it runs in QUAD mode.
Somewhere along the way, it must have written to CRNV1 and set the QUAD_NV bit for QPI mode. This apparently has no effect on single mode operation, however it seems to prevent IO2 and IO3 to operate as WP# and RESET respectively. Once this was cleared, the write protection worked as expected.
The WP# function is not available when the Quad mode is enabled (CR1V[1]=1). It is an expected behavior.