problems switching from S70FL01GS to S70FS01GS

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
StVe_3722716
Level 1
Level 1
First like given

Good morning,

I am developing an embedded application on a soft MPU instantiated in a FPGA. One of the thing the fw should do is to read/write data from/to a flash, 16-pin spi memory. For my project I need to test several SPI flash brands, including Micron, Macronix and Cypress, on the same hardware. Luckily I managed to obtain some high-level drivers (i.e. drivers based on the vendor SPI driver that allow me to perform operations like erase sectors, program the flash and so on)  written for the Micron, which I easily adapted to the macronix and the Cypress S70FL01GS (3.3V) by changing a few registers.

I would now like to use the S70FS01GS (1.8V. Of course the voltage has been switched to 1.8) and I am encountering some problems since, in spite of the similar names, the access to some information is different. For example the STATUS REGISTER (0x05), which I used on the S70FL01GS to check if a write/erase operation is over, has become obsolete and was replaced by an access to register x00800000 using the "read any register" register (0x65). As a consequence, where in my code I have to wait for an erase operation to conclude, I replaced this function (that works correctly with Micron, Macronix and Cypress S70FL01GS):

 

static void wait_ready( void )

{

    uint8_t ready_bit;

    uint8_t command = READ_STATUS; // =0x05

    SPI_set_slave_select(SPI_INSTANCE, SPI_SLAVE); //SPI_INSTANCE is the SPI driver handle, SPI_SLAVE the slave index (which determines the chip select)

    do {

        SPI_transfer_block(SPI_INSTANCE, &command, 1, &ready_bit,1);

        ready_bit = ready_bit & READY_BIT_MASK; // READY_BIT_MASK=0x1

    } while( ready_bit == 1 );

    SPI_set_slave_select(SPI_INSTANCE, SPI_SLAVE);

}

with:

static void wait_ready( void)

{

    uint8_t ready_bit;

    uint8_t command[5];

    command[0]=READ_ANY_REG; // =0x65

    command[1]=0;

    command[2]=0x80;

    command[3]=0;

    command[4]=0;

    SPI_set_slave_select(SPI_INSTANCE, SPI_SLAVE);

    do {

        SPI_transfer_block(SPI_INSTANCE, command,5,&ready_bit,1);

        ready_bit = ready_bit & READY_BIT_MASK;

    } while( ready_bit == 1 );

    SPI_set_slave_select(SPI_INSTANCE, SPI_SLAVE);

}

which in principle should read the LSB of register x00800000 in a loop and exit when the erase operation is over. However the function exits immediately, even when operations that take long (e.g. erasing a 256k sector, that on the S70FL01GS takes approximately 1sec) are performed. The 4-byte addressing mode is set.

What am I doing wrong?

Thanks,

Stefano

0 Likes
1 Solution
Apurva_S
Moderator
Moderator
Moderator
100 likes received 500 replies posted 250 solutions authored

Dear Stefano,

I am answering your below query here -

>> Concerning your last comment, yes we want to use the flash in SPI mode, and not in QPI mode, that is why IO2/3 lines are pulled up. Does your answer mean that in SPI (legacy) mode the SR1V[0] bit to poll a program/erase operation status is non-working? If so, how can you poll the end of such operations in the SPI legacy mode?

As mentioned in my previous response, once the QPI mode has been enabled, all the instructions will require 4 IO lines for proper communication between the host and the memory. As we know from your schematic that IO2/3 lines are not available and pulled up. Hence, all the operations that are being performed after enabling QPI mode will not be executed properly and the data that you are receiving on your SO line cannot be relied upon. For example you have mentioned the following statement in your previous response "I set the CR2V register to 0x80, i.e. I disable the QPI protocol. Automatically the SR1V register goes to 0x00 and I am thus allowed to write on the flash." The WRAR operation that would have been performed to set CR2V register to 0x80 and the SR1V register value being obtained on SO line cannot be guaranteed since the IO2/3 lines are not connected in the schematic.

Coming to your question whether SR1V[0] (WIP) bit can be polled in Single SPI mode to determine the status of any erase/program operation or not. Yes, SR1V[0] (WIP) bit can be polled in all SPI modes (Single SPI mode, Quad mode, QPI mode etc.) provided that all the IO lines required for that particular mode are connected properly in the schematic. In your case, since the QPI mode is enabled and the IO2/3 lines are not connected the SR1V value being read cannot be guaranteed.

It is highly recommended that the Status and Configuration Registers be programmed only when necessary. Any unexpected power down while performing the program operation on SR and CR registers can corrupt the SR and CR register values and the device can become unusable. Please go through the following App Note to know about SR and CR Register programming best practices.

Please feel free to ask if you have any further queries.

Best Regards,

Apurva

View solution in original post

0 Likes
8 Replies
Apurva_S
Moderator
Moderator
Moderator
100 likes received 500 replies posted 250 solutions authored

Hi Stefano,

Thank you for contacting Cypress Semiconductor. I would like to ask you a few questions -

  1. Have you given the WREN (0x06) command to the flash before starting the program/erase operation?
  2. Did you try to read the sector which you were trying program/erase after exiting the above function? Are you not getting the desired output from the flash?
  3. Are you getting valid Status Register value from the RDAR command? As per my understanding of the code snippet provided by you, I don't see dummy cycles after address. What is the frequency that you are working on? If you go to page 84 of the datasheet and read the explanation for RDAR command and see the timing diagram for it, you can see that the command requires dummy cycles. The appropriate number of dummy cycles required for your application can be obtained from Table 25 on page 52 of the datasheet. You will also have to update CR2NV[3-0] bits according to the required number of dummy cycles.
  4. If you are able to get valid data for Status Register, can you please tell me what is the Status Register value initially before program/erase operation is initiated and also the Status Register value after the program exits the above mentioned function? Are any of the error bits set after exiting the above function?

Best Regards,

Apurva

0 Likes

Dear Apurva,

Thank you for your answer. Please find the answers/comments to your questions below:

1) yes, I issue a wren command before any write operation in my code

2) I did not read the sector content directly (I can do it though) but I tried to upload and subsequently fetch a MP firmware after the erase, without success. The exact same procedure works well on boards with different flash chips (including the S70FL), so I am pretty confident that the code is fine (except for a different behaviour of the flash of course)

3) I read about the dummy cycles and I am not 100% sure I understood them. I am working at 10 MHz, a very low frequency. At this frequency the latency (i.e. the number of dummy cycles, i.e. the value of CR2NV bits) should be 0, right? Do you know which is the default CR2NV value? In case this value should be different from 0, should I expect the status register datum from the SPI to be shifted by an amount of bytes equal to the CR2NV bits value within the data returned by a SPI read command?

4) I can do that, but unfortunately not before Monday.

Meanwhile, it would be great if you could confirm that I am dealing with the dummy cycles correctly and that at 10 MHz the CR2NV value must be 0.

Thank you.

Kind regards,

Stefano

0 Likes

Hi Stefano,

Thank you so much for your response.

Your understanding of dummy cycles as mentioned in point #3 is absolutely correct. Yes, the number of required latency cycles for your application (10 MHz frequency) should be equal to 0. If you go to page 51 of the datasheet you will find that Table 24 mentions the default state of each of the CR2NV bits, and you will also notice that CR2NV[3] bit is set to 1 by default. Which means the device expects 8 latency cycles after the address (by default). Therefore, the actual Status Register value gets shifted by 8 cycles. I would also like to point out that the CR2NV register is One Time Programmable (OTP) and hence CR2NV[3] bit can be programmed from 1 to 0 only once and cannot be returned to 1 subsequently. In such a case, we can either program CR2NV register to set the latency cycles to 0, or if there is no time constraints we can provide 8 number of latency cycles after sending the address.

  • Are you able to read the Status Register value correctly at any point in the entire code? E.g. upon power up the Status Register value should be 0x00, or after sending WREN command the Status Register value should change to 0x02.

I would like to suggest you to do the following -

  1. Set the CR2NV[3-0] bits appropriately according to your application requirement or modify the firmware to provide the required number of latency cycles after sending the address in RDAR command..
  2. Try to read and confirm the Status Register value upon power up (the value should be 0x00).
  3. Send the WREN command. Read the Status Register value again and confirm (the value should be 0x02).
  4. If all the above experiments give desired result, then try to erase any sector and try to read back the value from that sector and confirm that it is erased (the data in that sector should be all 0xFFs). Also check that none of the error bits are getting set in the Status Register.

Kindly update me about the results of the above steps. If the issue persists we will try to capture the SPI signals.

Best Regards,

Apurva

0 Likes

Dear Apurva,

Thank you for your help. I started working on it today, more news asap (hopefully tomorrow).

Kind regards,

Stefano

0 Likes

Dear Apurva,

Thanks again for your answer.

According to your advice, in my code I implemented functions to do the following:

a) read any register (0x65) (address is provided at runtime)

b) write any register (0x71) (address and value are provided at runtime)

c) SPI write enable (0x06)

Concerning registers accessible through a) and b), my attention focused on 0x00800000 (SR1V, status register 1) and 0x00800003 (CR2V, configuration register 2), as you advised in your last email

I went through several modifications, including the one-time writing of the CR2NV register and the present status is the following:

1) When I switch the board off/on, the register values are: SR1V=0x80, CR2V=C0. The latter might be due to the one-time programming that I did. In my understanding, the flash cannot be written in this situation, given the MSB of the SR1V register to 1.

2) I set the CR2V register to 0x80, i.e. I disable the QPI protocol. Automatically the SR1V register goes to 0x00 and I am thus allowed to write on the flash.

3) In spite of that being the configuration you suggested, if I try to issue a 256 block erase command (0xDC) the erase does not seem to take place, as the LSB of SR1V is always 0 (and my wait function from my initial message immediately exits, while with S70LS it loops approximately 1 sec)

Last but not least, since a couple of hours I cannot read/write the aforementioned internal registers through 0x65, 0x71 (but I still can read the flash ID and manufacturer, and the board performs the usual operations it is supposed to) and I really don't know why... I am really puzzled and I start thinking there is smtg wrong in my hw. In attachment you can find the circuitry around the flash, can you please confirm that it is suitable for the S70FS? The S70FL and the other two flashes were mounted on the same PCB and they all work well (with different access routines of course)

Many thanks.

Kind regards,

Stefano

PS: Isn't there any way at all to make the S70FS work exactly like the S70FL? I understand that the S70FL is the older family, but isn't there a legacy mode that for example allows me to check for the end of an erase operation the old, S70FL way?

flash.jpg

0 Likes

Hi Stefano,

Thank you so much for the update.

I would like to inform you that the Volatile SR and CR registers obtain their initial values from their Non Volatile counterpart SR and CR registers upon power up. Which means 0x80 and 0xC0 are actually the values of SR1NV and CR2NV registers respectively. Now, if you go to page 51 of the datasheet and go through the explanation for QPI Non-volatile CR2NV[6] bit you will see the following -

pastedImage_0.png

When the device is in QPI mode, all the instructions will require 4 IO lines for proper communication between the host and the memory. In the schematic provided by you, I see that the IO2 and IO3 lines are pulled up. Since all four IO channels are not available we will not be able to read/write to the flash in QPI mode. WRAR command also would not work.

Another possibility could also be that their was an unexpected power down while performing the program operation on SR and CR registers and the SR and CR register values got corrupted. Please go through this Application Note for more detailed information.

PS: Isn't there any way at all to make the S70FS work exactly like the S70FL? I understand that the S70FL is the older family, but isn't there a legacy mode that for example allows me to check for the end of an erase operation the old, S70FL way?

>> I would like to inform you that S70FS01GS is a dual die package of two S25FS512S dies. However, it has a single CS# line. Where as in the S70FL01GS device we have two separate CS# lines for each die. Hence, reading/writing to SR and CR registers is different for both devices. there is no way to make both devices work in a similar way.

Please let me know if you have any more queries.

Best Regards,

Apurva

0 Likes
Apurva_S
Moderator
Moderator
Moderator
100 likes received 500 replies posted 250 solutions authored

Dear Stefano,

I am answering your below query here -

>> Concerning your last comment, yes we want to use the flash in SPI mode, and not in QPI mode, that is why IO2/3 lines are pulled up. Does your answer mean that in SPI (legacy) mode the SR1V[0] bit to poll a program/erase operation status is non-working? If so, how can you poll the end of such operations in the SPI legacy mode?

As mentioned in my previous response, once the QPI mode has been enabled, all the instructions will require 4 IO lines for proper communication between the host and the memory. As we know from your schematic that IO2/3 lines are not available and pulled up. Hence, all the operations that are being performed after enabling QPI mode will not be executed properly and the data that you are receiving on your SO line cannot be relied upon. For example you have mentioned the following statement in your previous response "I set the CR2V register to 0x80, i.e. I disable the QPI protocol. Automatically the SR1V register goes to 0x00 and I am thus allowed to write on the flash." The WRAR operation that would have been performed to set CR2V register to 0x80 and the SR1V register value being obtained on SO line cannot be guaranteed since the IO2/3 lines are not connected in the schematic.

Coming to your question whether SR1V[0] (WIP) bit can be polled in Single SPI mode to determine the status of any erase/program operation or not. Yes, SR1V[0] (WIP) bit can be polled in all SPI modes (Single SPI mode, Quad mode, QPI mode etc.) provided that all the IO lines required for that particular mode are connected properly in the schematic. In your case, since the QPI mode is enabled and the IO2/3 lines are not connected the SR1V value being read cannot be guaranteed.

It is highly recommended that the Status and Configuration Registers be programmed only when necessary. Any unexpected power down while performing the program operation on SR and CR registers can corrupt the SR and CR register values and the device can become unusable. Please go through the following App Note to know about SR and CR Register programming best practices.

Please feel free to ask if you have any further queries.

Best Regards,

Apurva

0 Likes

Dear Apurva,

After many checks I have finally found, if not a solution, at least a workaround. Thanks to your advice from some weeks ago, I noticed that after the erase sector command the write enable bit (00800003, second LSB) was still at 2, which implied an unsuccessful (or not issued) erase command, whereas the same code worked fine with the other aformentioned chips. Unfortunately I don't have a decent oscilloscope here, so I tried different code solutions and in the end I found out that if I deselect the SPI slave after the write enable command (through the MCU drivers) and then select it again before the erase command the erase operation works and I am able to correctly reprogram my flash through the MCU. I am aware that this is just a patch and unfortunately I don't have time to look deeper into the question, but your help was extremely useful in finding a solution, thanks!

Kind regards,

Stefano

0 Likes