Can't configure flash memory PMODSF3

[AryA7_user]

Hey everyone,

I'm having a problem with pmodSF3 that uses a flash memory with FBGA code RW146 ( datasheet).

The problem is once I try to modify the enhanced volatile configuration registers, the flash starts sending ones. I tried to follow the datasheet by sending a write enable, then 0x61 command and then the value to write in the register. I did check the commands using a scope, and they are sent correctly.

What's weird is the flash works fine but once I try to modify that register the flash starts sending ones and nothing works until I power off and on the board.

As you can see the first tests works fine, then I try to modify the volatile enhanced register and then things get messy.

 

Someone has an idea of what's happening ?

[JColvin]

Hi @AryA7_user,

I'm guessing you are using the Arty A7 35T (based on your name)?

Based on what you describe and what I see in the datasheet you linked (there's a slightly different datasheet on the Pmod SF3 resource center, that references a 3V 256 Mb module which should be what is loaded on the Pmod SF3, otherwise no Digilent board would actually be able to communicate with the 1.8V module you linked), it seems you are following the correct directions: send write enable (0x06) holding CS# low until the 8th bit of the command code has been latched in and then driving CS# high again (page 58), followed by the write enhanced volatile configuration register command (0x61), though this should be the same for the write nonvolatile configuration register. The datasheet is a bit cryptic on if the CS# needs to be driven high again after the write enhanced volatile configuration register command or if that is just reiterating what needs to be done on the write enable command.

As per Table 18 (page 30) both of these should not need any extra dummy clock cycles, though it is noted that if the number of dummy clock cycles is insufficient for the operating frequency, the memory reads wrong data.

I guess the things I would be looking for is if you are attempting to read from a protected area or if your are writing more data than necessary to the enhanced volatile command register and that is messing something up somehow. I guess it also wouldn't hurt to double check bitwise operations on the software end to make sure nothing is being unintentionally overwritten with 1's.

I'd have to look into this a lot more for any further debugging.

Thanks,
JColvin

[AryA7_user]

Thank you for your answer @JColvin. Yes I am using an Arty A7 35T.

Quote

I guess the things I would be looking for is if you are attempting to read from a protected area or if your are writing more data than necessary to the enhanced volatile command register and that is messing something up somehow. I guess it also wouldn't hurt to double check bitwise operations on the software end to make sure nothing is being unintentionally overwritten with 1's.

I do check all the commands I send or the response I get  using a logic analyzer, and they all seem correct which validates the software end. I don't do any write operations to protected areas, furthermore my status register is all zeros which means all memory areas are unprotected. And as I said, what's really weird, is the flash works fine but once I write that register, it starts sending ones.

I am really stuck at this point because I don't have any ideas about further steps that should be done to debug the problem. I am thinking about writing the non-volatile configuration register directly, but I'm afraid the same problem happens and in that case turning off and on the flash will probably get it back to normal functioning.

 

 

 

Edited May 5, 2021 by AryA7_user

[AryA7_user]

I just asked my supervisor, and he said that the flash he gave me had some problems ? . Anyway, thank you a lot for your response.

[JColvin]

Hi @AryA7_user,

I'm glad to hear you learned the reason for why the part isn't working, though it is unfortunate that it doesn't resolve the issue. I don't have a Pmod SF3 at my home office so I can't readily test this to see if I get a similar result (ideally indicating if it's singular part problem or a problem with the micron chip in general).

Thanks,
JColvin