FATFS working on MXIC MX25R6435F but not on S25FS128S

[MichielSch]

Hello,

We have integrated the FATFS example as shown in the usbd_msc example project into our own firmware application. It works perfectly on the nRF52840dk and when we modify our own hardware with the MX25R6435F chip it also runs fine on our own hardware. Meaning I can mount the filesystem, list the filesystem contents, create files, read files and modify the files.

However when we try to run it on our hardware with S25FS128S (which is the flash chip we use in production) we can only (seemingly) write the filesystem and mount it. When we try to create new files they do seem to get written (the lower level qspi functions are being called) but the filesystem itself does not get updated.

We looked on the devzone and found these examples: https://devzone.nordicsemi.com/f/nordic-q-a/50534/qspi-block-device-issue-with-s25fs-flash-part  and https://devzone.nordicsemi.com/f/nordic-q-a/56928/qspi-32bit-addressing-mode but I was not able to get the FS to behave properly. I am however able to use the memory in both 24 and 32bit addressing mode and get similar behavior.

This are the flash_params we used: 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,
    }
};

The chip ID is being read just fine.

How can it be that i seem to be able to read and write the FS itself but I'm not able to add files, let alone modify them. We are running on sdk 15.2 with softdevice 140 btw. 

Looking forward to your reply,

Best regards,

Michiel

[Simonr]

Hi again

It seems that only uniform block sizes are supported on our side, so the uniform sector options is the one that should be used. Our suggestion is creating the structure describing your Flash Memory by editing the nrf_serial_flash_params.c file in your SDK to make it coincide with the S25FS128S. This should make it work as intended.

Best regards,

Simon

[MichielSch]

Hi Simon,

Thanks for your answer. It's in a sense good news that this uniform block sizes could be the issue. I am also in contact with Infineon and they gave me instructions on how to get the device into uniform block mode but it seems I can't get their instructions "translated".

    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.

In the code snippet in my previous answers I already attempted it but I am not 100% sure the qspi driver is behaving like I'm expecting it to behave.

Thanks again for the support,

Best regards,

Michiel

[Simonr]

I'm sorry, but I'm not sure how I can help you doing this, as we don't have much experience on translating these instructions either. I'm not able to spot any specific issues in your last snippet. 

Best regards,

Simon

[MichielSch]

Hi Simon,

This investigation is still going on and I am also getting support from the Infineon side. For debugging purposes (tracing with a logic analyzer) I would like to reduce the clock speed of the QSPI to 4MHz. I have this line #define NRFX_QSPI_CONFIG_FREQUENCY 7 in the sdk_config. This should reduce the clock frequency to 4MHz right? However it does seem to remain at 8MHz for now. Are there any other settings I should adjust to clock the memory bus down?

Thanks and best regards,

Michiel