Issues with fat fs implementation from Nordic SDK on S25FS128S

[MichielS]

Hi,

I'm trying to get the FAT FS implementation running on a system that contains the nRF52840 and the S25FS128S.

I can see that data is being written to the S25FS128S but I can't get beyond the writing and mounting of the file system. I am starting to suspect the issue might be with the non-uniform memory sector layout at the beginning of the flash memory.

I have the memory chip in 32bit addressing mode and I am trying to get it out of the standard hybrid sector mode with the following operation:

//test for non hybrid sectors
uint32_t reg_adr = 0x000004;
uint32_t status = 0;
uint32_t temp;

uint8_t location[5], rdBuf[2];

//location[0] = 0x06; /* Write enable. */
cinstr_cfg2.opcode = 0x06;
cinstr_cfg2.length = NRF_QSPI_CINSTR_LEN_1B;

status = nrf_drv_qspi_cinstr_xfer(&cinstr_cfg2, NULL, NULL);//CyU3PSpiTransferWords (location, 1, 0, 0);

rdBuf[0] = 0x8;

cinstr_cfg2.opcode = 0x71; /* Sector erase. */
cinstr_cfg2.length = NRF_QSPI_CINSTR_LEN_6B;
temp = reg_adr;

location[0] = (temp >> 16) & 0xFF;

location[1] = (temp >> 16) & 0xFF;

location[2] = (temp >> 😎 & 0xFF;

location[3] = temp & 0xFF;

location[4] = 0x08;


status = nrf_drv_qspi_cinstr_xfer(&cinstr_cfg2, location, NULL);//CyU3PSpiTransferWords (location, 5, 0, 0);

nrf_delay_ms(250);

So basically my question is two fold:

1. Is it possible that the hybrid sector layout is what is causing the issues with the FAT FS (It works perfectly well on the flash chip that comes with their development board)
2. Is the piece of code above the correct way to put the flash memory in uniform sector mode or am I missing any steps? (eg do I need to reset the chip after or something)

Thanks In advance,

Michiel

[Apurva_S]

Hi Michiel,

Is it possible that the hybrid sector layout is what is causing the issues with the FAT FS (It works perfectly well on the flash chip that comes with their development board)

>> I shall get back to you on this shortly.

Is the piece of code above the correct way to put the flash memory in uniform sector mode or am I missing any steps? (eg do I need to reset the chip after or something)

>> The below line does not seem to be incorrect.

location[2] = (temp >>  & 0xFF;

You should mention the number of units by which you want the value of 'temp' to be right shifted,  and the closing bracket ')' is missing. The correct sequence of commands for the WRAR operation is as below - 

• Drive CS# LOW
• Send WREN command
• Drive CS# HIGH
• Drive CS# LOW 
• Send WRAR command
• Send 4 bytes of CR3NV register address
• Send the CR3NV register value
• Drive CS# HIGH
• Drive CS# LOW
• Send RDSR1 command
• Read SR1 value
• Drive CS# HIGH
• Check WIP bit and P_ERR bit of SR1. If WIP bit is 1, it indicates that the program operation on CR3NV register is still in progress. The SR1 value should be polled till the time the WIP bit remains HIGH. In case some error occurs while programming, the P_ERR bit will get set and the WIP bit shall also remain HIGH.

Hope this helps you to disable the hybrid sectors. Let me know if you have any questions related to this.

Regards.

[MichielS]

Hi,

Thanks for the reply!

The line you mentioned was indeed incorrect. Might have messed it up editing it for the post. In the code it was:

 location[2] = (temp >> 8 )  &  0xFF;

It's also not correct that I shifted the first two location array elements by the same number but that yields the same result in this case I think.

I'll try the sequence you are describing.

Thanks again and best regards,

Michiel

[MichielS]

Hi,

I tried the following piece of code in an effort to disable the hybrid sectors:

        //test for non hybrid sectors
        uint32_t reg_adr = 0x000004;
        uint32_t status = 0;
        uint32_t temp;

        uint8_t  location[5], rdBuf[2], status_register[1];

        //location[0] = 0x06;  /* Write enable. */
        cinstr_cfg2.opcode = 0x06;
        cinstr_cfg2.length = NRF_QSPI_CINSTR_LEN_1B;
        /*Send the write enable command to the QPSI*/
        status = nrf_drv_qspi_cinstr_xfer(&cinstr_cfg2, NULL, NULL);//CyU3PSpiTransferWords (location, 1, 0, 0);

        rdBuf[0] = 0x8;

        cinstr_cfg2.opcode = 0x71; /* write any register command. */
        cinstr_cfg2.length = NRF_QSPI_CINSTR_LEN_6B;
        temp  = reg_adr;
        
        location[0] = (temp >> 24) & 0xFF;

        location[1] = (temp >> 16) & 0xFF;

        location[2] = (temp >> 8 ) & 0xFF;

        location[3] = temp & 0xFF;

        location[4] = 0x08;
        /*Send the write any command followed by the register address (location[0] ... location[3]) and the 
          value to be written to the register 0x08 in location[4] */ 
        status = nrf_drv_qspi_cinstr_xfer(&cinstr_cfg2, location, NULL);//CyU3PSpiTransferWords (location, 5, 0, 0);
        nrf_delay_ms(250);
       
        cinstr_cfg2.opcode = QSPI_STD_CMD_RDSR1; /* Command read status register 1 0x05*/
        cinstr_cfg2.length = NRF_QSPI_CINSTR_LEN_2B;
        status_register[0] = 0;
        status = nrf_drv_qspi_cinstr_xfer(&cinstr_cfg2, NULL, status_register);

        nrf_delay_ms(250);

If I do not add the 250ms delay before sending the RDSR1 command if get a value of 0 in the status register and if I do add the 250ms delay if get a value of 2 in the status register. So it seems like only the Write Enable Latch bit in the status register is changing? Does this make sense? Can I read directly the whether the hybrid sectors are enabled or not?

Thanks and best regards,

Michiel

[Apurva_S]

Hi Michiel,

I have a few questions and suggestions.

• Can you please tell me whether you have been able to perform any kind of operation on the flash successfully till now? Like reading device id, status register etc. Means, have you confirmed that the SPI interface between the controller and the flash is fine?
• In your first post you have mentioned that you are able to write and perform mounting successfully. How did you confirm the write/program operation was successful? Did you read back the data to confirm?
•  I would suggest you to make the following change in the current code - Read the SR1 value before WREN command, and also after the WREN command. This will confirm that the initial value of SR1 was 0x00 and after WREN it should become 0x02.
• Also, Is it possible for you to send the SPI waveforms for all these operations (your original code, plus the above mentioned modification) ?
• Regarding your first question about file system, can you confirm whether you are using the Flash File System from Infineon (Cypress)?

Regards.

[MichielS]

Hi,

Thanks for your response!

• Can you please tell me whether you have been able to perform any kind of operation on the flash successfully till now? Like reading device id, status register etc. Means, have you confirmed that the SPI interface between the controller and the flash is fine?Yes, during the init of the flash the Nordic library reads the the device ID which is what I expect it to be (0x01, 0x20, 0x18). Previously we also stored data directly on the flash (without a file system abstraction and this way we can reliably store data. The flash interface seems to work just fine, tested on multiple boards.
• In your first post you have mentioned that you are able to write and perform mounting successfully. How did you confirm the write/program operation was successful? Did you read back the data to confirm?If I read-back the "raw" data from the flash memory I can see that things are being written. During the boot process our firmware checks for a filesystem on the flash and mounts it. It can reliably tell the difference to a memory with and a memory without the filesystem present.
•  I would suggest you to make the following change in the current code - Read the SR1 value before WREN command, and also after the WREN command. This will confirm that the initial value of SR1 was 0x00 and after WREN it should become 0x02.OK, I will try this.
• Also, Is it possible for you to send the SPI waveforms for all these operations (your original code, plus the above mentioned modification) ?Like a trace from a logic analyzer? That should be possible but difficult due too remote working situations. I will get back to you in this regard.
• Regarding your first question about file system, can you confirm whether you are using the Flash File System from Infineon (Cypress)?The one I am using can be found in the example code that came with my microcontroller (nrf52840) but our custom hardware is based on the infineon S25FS. It is a FAT implementation. Does Infineon have an implementation that is compatible with this microcontroller as well?

Thanks for your support,

Best regards,

Michiel

[Apurva_S]

Hi Michiel,

• Like a trace from a logic analyzer? Yes.
• The one I am using can be found in the example code that came with my microcontroller (nrf52840) but our custom hardware is based on the infineon S25FS. It is a FAT implementation. Since you are using the file system from Nordic, they would be the correct people to answer the question whether the root cause of your issue is hybrid sector architecture or not. File systems usually have a header file where the device configuration (like erase block size, page size etc.) are defined. They should be able guide you if any modifications are needed in the example code to make it compatible with hybrid sector architecture.
• Does Infineon have an implementation that is compatible with this microcontroller as well? Yes, we do provide a flash file system. The file system comes along with a low level driver for flash. The HAL file of the low level driver needs to modified (updated with the MCU specific APIs) to make it work with the desired microcontroller. 

Kindly let us know the result of your test, and if possible logic analyzer screenshot as well.

Regards.

[MichielS]

Hi,

Sorry for the long wait, due too the situation it took some time to get access to the hardware test points to make a logic analyzer trace. I added it to the thread as a .zip file.

I am also in contact with the Nordic  people. They claim that the file system should work if I am able to configure it correctly and that it will definitely not work with the hybrid sector architecture. So I am hopeful that if I get the S25FS in the correct mode I can keep using this memory chip.

As of now I was not able to get the chip in the desired state.

Thanks for the support and best regards,

Michiel

[Apurva_S]

Hi Michiel,

I am observing some strange issues in the waveform. Please see below - 

• The above snippet is of the first SPI transaction in the attached waveform. Infineon (Cypress) flash devices operate in SPI mode 0 and mode 3. Therefore, sampling happens on the rising edge of the clock and data should change on the falling edge of the clock. However, we can see here that the data changes on the rising of the clock pulse. This is not correct.
• Secondly, we can see that 0x01 is shifted out on MOSI line. 0x01 is the WRR command. WRR command should be preceded by a WREN command SPI transaction, and the WRR SPI transaction should also have the data for status/configuration registers. But in the waveform we see only 0x01 being sent to the flash. This is also not correct.

• The above snippet is of the second SPI transaction. The second clock pulse duration is not same as the other clock pulses. This is incorrect.
• We also see that there are nine clock pulses in one transaction. This should not be done.
• 0x00 is shifted out on MOSI line. This is not a valid flash command.

Please answer my below questions - 

• Could you please let me know the version of Logic (Saleae software) that you are using?
• Is it possible for you to record the waveforms again? And if possible send us the .logicdata file and screenshots of the waveforms that you are observing on your side, both.

Regards.

[MichielS]

Hi,

Sorry it took a while. It seems that my logic analyzer is not getting reliable traces at these speeds. I verified it with my scope and confirmed that the scope is consistent with my expectations but the logic analyzer is not. So unfortunately I had to make due with my 2 channel scope and create separate traces for the MISO and the MOSI. I will add them as attachments for you to look at. 

As a sanity check I also added the chip id request and response. In this command you can verify that communication between the chip and the micro controller is working properly. You can see the 0x9F on the MOSI screenshot and corresponding 0x01 0x20 0x18 on the MISO as the response.

As a side note, I was not able to make traces of the MISO and the MOSI at the same time because I only have 2 channels and I need the CLOCK for triggering.

Let me know if you would need more detailed snap shots of any of the commands.

Thanks and best regards,

Michiel

[MichielS]

And because of the attachment limit here are the other traces

[Apurva_S]

Hi Michiel,

Please see my comments on the waveform below - 

I can see multiple WREN commands before the WRAR (0x71) command. Multiple WREN commands are not required and may also disturb the internal functioning of the flash, hence, it is not recommended to do that.

• I see a WREN command even before the RDAR (0x65) command. There is no requirement of WREN command before the RDAR command. WREN command is required to set the WEL bit (Write Enable Latch) of the Status Register before any program/erase operation can be initiated.
• The RDAR command should be followed by the appropriate number of dummy cycles and clock pulses required to read the value of the register. I don't see clock pulses after the RDAR command and address.

The RSTEN (0x66) command is followed by the RDSR and WREN command. Please see this statement from the datasheet - "Any command other than RST following the RSTEN command, will clear the reset enable condition
and prevent a later RST command from being recognized. " 

I have some more general suggestions - 

• The 4 Byte addressing mode has been enabled in volatile mode. If flash undergoes a power cycle, the 4 byte addressing will have to be enabled again.
• The signal seems to be very noisy. Can you try to reduce the frequency and repeat? Also, I see undershoots in the signals (The signal goes below 0 mark). This may create a problem for the flash. the flash may not accept the commands properly.
• If you are facing difficulty in implementing the different functions of the flash, you can consider using our low level driver for SPI NOR flash. The functions have already been implemented in the LLD and only effort required is to update the HAL file with the microcontroller specific SPI APIs. You can download the LLD from here - https://www.cypress.com/documentation/software-and-drivers/low-level-driver-spi-flash?source=search&.... Let me know if you need help in understanding the LLD.

Regards.

[MichielS]

Hi,

Thanks for your in dept answer!

I made some new traces of the clock and the MOSI @ 2MHz. Still a bit noisy but a lot better compared to the 8MHz.

It seems like the Nordic driver always adds a 0x06 (WREN) to every command send because I'm not actively sending them myself.  Do you suspect this to be a problem?

Maybe a more specific case of the previous case but, as you mention yourself, in between the RSTEN command and the actual reset command there is a WREN command. Based on your remark this would effectively stop the device from being reset, correct?

About the RDAR command, you are correct, I did not add the dummy cycles to read the values back. It does look good in the updates trace.

I will look into the LLD as well.

Thanks again and best regards,

Michiel

[MichielS]

The reset enable trace in the next answer.

[MichielS]

Hi,

So I removed the WREN commands that where redundant. Still no luck getting the device to work with the FS. When I read the CR3NV, it's value seems to be 0 while it should be 8 (I think).

Based on the traces what am I still missing?

Also do these values make sense:

/**
* @brief QSPI block device definition
*/
NRF_BLOCK_DEV_QSPI_DEFINE(
m_block_dev_qspi,
NRF_BLOCK_DEV_QSPI_CONFIG(
512,
NRF_BLOCK_DEV_QSPI_FLAG_CACHE_WRITEBACK,
NRF_DRV_QSPI_DEFAULT_CONFIG
),
NFR_BLOCK_DEV_INFO_CONFIG("Nordic", "QSPI", "1.00")
);

static const nrf_serial_flash_params_t m_sflash_params[] = {
{ /*S25FS128S*/
.read_id = { 0x01, 0x20, 0x18 },
.capabilities = 0x00,
.size = 16 * 1024 * 1024,
.erase_size = 4 * 1024,
.program_size = 256,
}
};

Thanks and best regards,

Michiel

[Apurva_S]

Hi Michiel,

Please see the below points

• It seems like the Nordic driver always adds a 0x06 (WREN) to every command send because I'm not actively sending them myself.  Do you suspect this to be a problem? Sending unnecessary commands to the flash may cause the flash to go into undefined state. It is not recommended.
• Maybe a more specific case of the previous case but, as you mention yourself, in between the RSTEN command and the actual reset command there is a WREN command. Based on your remark this would effectively stop the device from being reset, correct? Correct. Please see this below snippet from datasheet - 

• In the below waveform, I still see the RDSR1 command (05h) and clock pulses between the RSTEN command (66h) and RST command (99h). The device will not reset if there are any other commands between the RSTEN and the RST commands. Please see the snip from datasheet provided above.

• Regarding the values you have provided in your latest response, I will not be able to comment on Nordic driver specific values, you should contact Nordic for it. However, can you explain why have you put erase size as 4KB (4*1024)? If you enable uniform sector architecture, the sector size will be 64KB or 256KB

I have some questions and suggestions - 

• Can you please tell me the exact sequence of commands? At what point in your application are you trying to reset the device? I would like to point out again that the Enable 4-byte address mode command (4BAM B7h) enables 4 byte addressing in the volatile configuration register (CR2V). If you reset the device or give a power cycle to the device, this volatile setting will be lost and is needed to be set again.
• I still see undershoots on the waveform. Can you please try to get rid of those?
• I don't see the SO line output for RDAR command in any of the waveforms, or the SO line output for any other command as well. Can you please try to record the waveforms again using Saleae logic analyzer by reducing the clock frequency, so that we can see all the SPI signals in a single screenshot? You can try reducing the frequency to KHz range and then try to capture all of the SPI signals in a single snippet. Please try to provide the waveforms for the following sequence of commands (with SO line) - WREN, WRAR, SR polling, RDAR.

Regards.

[MichielS]

Hi,

Thanks for all your suggestions. However due to the incompatibilities between the library and the chip, we are considering switching to the Infineon library of the file system implementation. Do you have a download link to the source code so we can evaluate it and decide on which implementation we should go with?

Does Infineon have implementations of other filesystems than FAT? 

Thanks and best regards,

Michiel

[Apurva_S]

Hi Michiel,

You can find FFS related information here - https://www.cypress.com/documentation/software-and-drivers/cypress-flash-file-system?source=search&c...

Let me know if you have more questions.

Regards.

[Apurva_S]

Hi Michiel,

The option to place a request for Infineon FFS is present here - https://www.cypress.com/software-and-drivers-cypress-flash-memory#:%7E:text=The%20Cypress%20Flash%20...

Regards.