Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
8 years ago

Signal Tap II reading a "1" from SO of FLASH CHIP always, without changes. why?

I'm creating a very simple Flash controller as a school project. The flash chip is MX25L3206E and the FPGA is 5CEFA4F23C8. I created the code attached and routed the proper pins from the chip. After compiling everything I run the Logic Tap II analyzer and it shoes me the image attached. The code is basically running as expected as it can see in the second attached imag, but I'm receiving this "1" from the SO pin from the beginning of the time without changes, so I'm not able to pick up the "supposedly" data from SO.

any thoughts about this? Chip might be malfunctioning?

7 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    8 years ago

    I haven't looked through your code in detail. However, I notice you've defined parameters for the read and write commands for the FLASH device, but not the write enable command. Without this you'll never be able to write to the device. So it follows that you'll only ever read out 1's.

    I suggest you work with the Read Identification command. This only requires you to issue one byte for which you'll get two back. This command works stand alone, no need for any write enable. That way you can make 'SO' do something and prove your low level code without the need to worry about the higher level command sequences the device needs to be written to.

    Cheers,

    Alex
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    8 years ago

    --- Quote Start ---

    I haven't looked through your code in detail. However, I notice you've defined parameters for the read and write commands for the FLASH device, but not the write enable command. Without this you'll never be able to write to the device. So it follows that you'll only ever read out 1's.

    I suggest you work with the Read Identification command. This only requires you to issue one byte for which you'll get two back. This command works stand alone, no need for any write enable. That way you can make 'SO' do something and prove your low level code without the need to worry about the higher level command sequences the device needs to be written to.

    Cheers,

    Alex

    --- Quote End ---

    Alex really appreciated, I will try this immediately, let me understand something, SO pin naturally by default outputs "1", is not a malfunction of the chip, I mean either command or not, the SO is static in "1" since power on? Besides write enable command, are there other mandatory commands for a simple write and read operation? You gave me great ideas, thanks.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    8 years ago

    SO idling HIGH wouldn't worry me. You may have a pull-up in the FPGA by default. Even if you don't I wouldn't be surprised if a tri-state line drifts up high, not low.

    The Write Enable command is the only one I can think of that'll get you. You need it before you issue any command that can modify the contents of the FLASH - write, sector erase, bulk erase, write status, etc...

    Cheers,

    Alex
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    8 years ago

    Also w/o having written anything to the FLASH it will be "empty", which - for at least some devices - is a "1" :-)

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    8 years ago

    I have been able to communicate with the CHIP, through 9Fh command.

    https://www.alteraforum.com/forum/attachment.php?attachmentid=14813

    https://www.alteraforum.com/forum/attachment.php?attachmentid=14814

    The problem was because my SI was slightly too forward (half period) to the SCLK. So, the chip actually listen each rise of SCLK, if I don't feed it timely, it does not work. And the "1" is indeed an stand by signal, once SO is actually sending something, it change to 0 or 1.

    I still keep having the problem that even tho 9Fh (chip identification) and 05h (read status of "still writting" and "write enable active") seems to be working, and using the 02h (write data), only zero comes out from the chip after using 03h (read data) command.

    I ran out of ideas.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    8 years ago

    I finally solved the problem, Datasheet does not mention it, it is necessary to erase the sector everything it is intended to write anything to it, so if you want to write something, prior to the command write you also have to properly send the command SE sector erase. So I have to work with the onchip ram to backup and rewrite the sector everytime, I don't understand exactly the reason for this, maybe someone else know why, maybe I'm wrong.

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    8 years ago

    The subtle part of the datasheet you're missing is the phrase

    --- Quote Start ---

    The Page Program (PP) instruction is for programming the memory to be "0".

    --- Quote End ---

    The PP command will only allow you to change the state of any given bit from a 1 to a zero. To change it back to a 1 you need to issue a sector/page/device erase command.

    You can continue to issue PP commands, and they will 'work', providing you're only ever writing more zeros to the device than are currently in there.

    Cheers,

    Alex