• 0

Can't configure flash memory PMODSF3


Question

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.

 

flash.png.b2407e499a02eb43f0b5952373ddb64e.png

Someone has an idea of what's happening ?

Link to post
Share on other sites

4 answers to this question

Recommended Posts

  • 0

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

Link to post
Share on other sites
  • 0
Posted (edited)

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 by AryA7_user
Link to post
Share on other sites
  • 0

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

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now