FATFS working on MXIC MX25R6435F but not on S25FS128S

RE: FATFS working on MXIC MX25R6435F but not on S25FS128S

Simonr — Fri, 25 Jun 2021 08:17:07 GMT

Very sorry about the delayed reply, but I have not seen the replies as they are in the middle of the thread on my end.

Can you try to turn on logging for the block device driver to see what that log returns? Alternatively, you can try scoping the QSPI lines to see what commands are sent to the flash as well so we can see what kind of state the driver is in.

Best regards,

Simon

RE: FATFS working on MXIC MX25R6435F but not on S25FS128S

MichielSch — Thu, 24 Jun 2021 13:33:37 GMT

Hi,

Any suggestions on the questions above?

Best regards,

Michiel

RE: FATFS working on MXIC MX25R6435F but not on S25FS128S

MichielSch — Thu, 03 Jun 2021 13:59:01 GMT

Hi Simon,

I got as an answer from infineon that:

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

If I understand correctly this means I should change the params to the following:

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

However when I run my code like this, I get the following error message:

<error> app: QSPI FLASH erase unit size not supported

So I changed this as well:

/**
* @brief QSPI block device internal erase unit buffer size
* */
#define NRF_BLOCK_DEV_QSPI_ERASE_UNIT_SIZE (4096*16)

Now the erase unit size not supported error is no longer there, but I fail to mount the fs now. When changing the erase size what other buffer sizes and settings should I change? For example I can imagine that the buffer sizes to do a read modify write on a drive with 4k erase needs substantially smaller buffer compared to a drive with 64k erase blocks...

Best regards,

Michiel

RE: FATFS working on MXIC MX25R6435F but not on S25FS128S

MichielSch — Thu, 27 May 2021 13:07:04 GMT

My bad, I think I see it, you can set the WREN to false in the config!

RE: FATFS working on MXIC MX25R6435F but not on S25FS128S

MichielSch — Wed, 26 May 2021 21:26:54 GMT

Hi Simon,

Is it correct that the QSPI driver always sends a 0x06 (write enable) command. I don't think this is necessary and in some cases prevents the actual command from running. Eg. A reset enable should be followed by a reset command but there should not be a write enable in between.

Is there away to avoid this behavior?

Thanks and best regards,

Michiel

RE: FATFS working on MXIC MX25R6435F but not on S25FS128S

MichielSch — Thu, 20 May 2021 14:50:19 GMT

Hi,

Thanks for the clarification!

Best regards,

Michiel

RE: FATFS working on MXIC MX25R6435F but not on S25FS128S

Simonr — Thu, 20 May 2021 10:43:55 GMT

Indeed, the example does not use this sdk_config.h configuration. This is a result of the implementation of the NRFX drivers, that does not seem entirely completed on the QSPI end of things, I will report this internally, as I didn't realize this myself until now. Seems like a bug on our side. Thank you for notifying us!

As for your addressing, all memory access by the QSPI peripheral memories should be word-aligned to the external memory address space, so you can only write/read in full 32 bit words.

Best regards,

Simon

RE: FATFS working on MXIC MX25R6435F but not on S25FS128S

MichielSch — Wed, 19 May 2021 19:23:38 GMT

Hi Simon,

Also as a follow up question with regards to the default config and device FS compatibility: Is the FatFS compatible with 24bit addressing as well or only with the 32bit addressing?

Where can I find these requirements for the FS? I probably looked over them in the example but I can't quite find them.

Thanks,

Michiel

RE: FATFS working on MXIC MX25R6435F but not on S25FS128S

MichielSch — Wed, 19 May 2021 10:06:11 GMT

Hi Simon,

Thanks for the reply.

I am using the default config (NRF_DRV_QSPI_DEFAULT_CONFIG) just as the example does. When I trace this to the config actually used in the nrfx_qspi_init function I do see that he is using NRF_QSPI_FREQ_32MDIV4. This explains the 8MHz, but it does seem that the code completely ignores the sdk_config setting. Also why is the value in the NRF_DRV_QSPI_DEFAULT_CONFIG not the same as the default value in the sdk_config?

I checked with both a logic analyzer and scope. The logic analyzer is an older Saleae model and seems to have some trouble with the 8MHz. Here is a screenshot of the trace, taken by the scope, of the clock and the MISO line, in this particular trace you can see the chip idea being read.

It seems like the values used in the NRF_DRV_QSPI_DEFAULT_CONFIG lead to a file called apply_old_config and this file is all greyed out.

Best regards,

Michiel

RE: FATFS working on MXIC MX25R6435F but not on S25FS128S

Simonr — Wed, 19 May 2021 08:19:56 GMT

Can you make sure that NRFX_QSPI_CONFIG_FREQUENCY is actually called by your application? What was this set to before? By default it's set to 15, which should set the speed to 2MHz. Also, how are you checking the clock speed of the QSPI? Are you using a logic analyzer or oscilloscope for example?

Best regards,

Simon

RE: FATFS working on MXIC MX25R6435F but not on S25FS128S

MichielSch — Mon, 17 May 2021 09:41:27 GMT

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

RE: FATFS working on MXIC MX25R6435F but not on S25FS128S

Simonr — Fri, 23 Apr 2021 07:45:20 GMT

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

RE: FATFS working on MXIC MX25R6435F but not on S25FS128S

MichielSch — Thu, 22 Apr 2021 09:04:15 GMT

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

RE: FATFS working on MXIC MX25R6435F but not on S25FS128S

Simonr — Thu, 22 Apr 2021 08:54:13 GMT

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

RE: FATFS working on MXIC MX25R6435F but not on S25FS128S

Simonr — Mon, 19 Apr 2021 08:25:20 GMT

Hi Michiel, I'm currently awaiting a reply from our QSPI driver developers as I hope they're able to make some sense out of this issue.

Best regards,

Simon

RE: FATFS working on MXIC MX25R6435F but not on S25FS128S

MichielSch — Fri, 16 Apr 2021 09:07:37 GMT

Hi,

As an addition to my last question, is this the correct way to put the S25FS memory in uniform sector mode:

//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 >> 8) & 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);

Thanks and best regards,

Michiel

RE: FATFS working on MXIC MX25R6435F but not on S25FS128S

MichielSch — Thu, 15 Apr 2021 17:32:40 GMT

Hi,

I found another piece of information that might be interesting to consider.

On the website of the manufacturer of the flash I found (I could share the link if you deem this appropriate):

By default, the S25FS128S flash device comes with hybrid sectors (the first sector of 64KB divided into 9 sectors (8 sectors of 4KB and one 32KB sector). All remaining sectors are uniform (64KB each).

When you use the Control Center application from the FX3 SDK, the internal programming utility (CyBootProgrammer.img) assumes uniform sector size for the flash device; this leads to corrupted data in the first sector, which is a hybrid sector.

To prevent this, configure the flash device to use uniform sectors of 64KB each by modifying the Configuration Register 3 (CR3NV) – see Figure 1.

Figure 1. Configuration Register 3 (CR3NV): Address = 0x00000004

To configure the flash with uniform 64KB sectors, write ‘1’ to CR3NV[3] and ‘0’ to CR3NV[1] using the WRAR 71h command (write 0x08 into the CR3NV register). After updating this register, use the default Control Center application to load the firmware image to the flash.

Could it be that these so called "hybrid sectors" are confusing the file system implementation? I would assume the implementation expects uniform sectors? I am currently trying to modify the settings of the memory chip.

Best regards,

Michiel

RE: FATFS working on MXIC MX25R6435F but not on S25FS128S

MichielSch — Thu, 15 Apr 2021 13:39:36 GMT

Hi Simon,

I tried to modify the nrf_block_dev_qspi.c with the suggested file in the other thread without any luck. I tried for with my flash memory both in 24 and 32bit addressing mode.

As for the read_id I triple checked it and cross referenced it with the s25f data sheet and it is correct. Also if I make this value to be anything else the memory will not initialize and in that case I cannot mount the file system, which I currently can so I am pretty positive this is not the culprit.

It would be nice if you could open an internal ticket. As by this time I really have no clue what could still be going wrong. Specially since it does work fine with the other memory chip and there are no more obvious things to try and verify as far as I can see.

I did also make a log of the read and write addresses used by the firmware during the creation of the filesystem both on the working device and our custom hardware. Here I can see that at the end of the creation of the file system the working device writes to the front of the memory (starting from address 0 up to address 3584) and on our hardware it only reads address 0 but does not perform the writes. Maybe this is a good indication for you on what is going on?

Thanks again for your support,

Michiel

<info> app: Initializing disk 0 (QSPI)...
<info> app: Mounting volume...
<info> app: reading from: 0
<error> app: Mount failed. Filesystem not found. Please format device.
<info> app: 
Creating filesystem...
<info> app: reading from: 28672
<info> app: writing to: 28672
<info> app: writing to: 29184
<info> app: writing to: 29696
<info> app: writing to: 30208
<info> app: writing to: 30720
<info> app: writing to: 31232
<info> app: writing to: 31744
<info> app: writing to: 32256
<info> app: reading from: 32768
<info> app: writing to: 32768
<info> app: writing to: 33280
<info> app: writing to: 33792
<info> app: writing to: 34304
<info> app: writing to: 34816
<info> app: writing to: 35328
<info> app: writing to: 35840
<info> app: writing to: 36352
<info> app: reading from: 36864
<info> app: reading from: 40960
<info> app: reading from: 45056
<info> app: reading from: 49152
<info> app: writing to: 49152
<info> app: writing to: 49664
<info> app: writing to: 50176
<info> app: writing to: 50688
<info> app: writing to: 51200
<info> app: writing to: 51712
<info> app: writing to: 52224
<info> app: writing to: 52736
<info> app: reading from: 53248
<info> app: reading from: 57344
<info> app: reading from: 61440
<info> app: reading from: 0
<info> app: writing to: 0
<info> app: writing to: 512
<info> app: writing to: 1024
<info> app: writing to: 1536
<info> app: writing to: 2048
<info> app: writing to: 2560
<info> app: writing to: 3072
<info> app: writing to: 3584
<info> app: Mounting volume...
<info> app: reading from: 0
<info> app: reading from: 32256
<info> app: Done

<info> app: Initializing disk 0 (QSPI)...
<info> app: Mounting volume...
<info> app: reading from: 0
<error> app: Mount failed. Filesystem not found. Please format device.
<info> app: 
Creating filesystem...
<info> app: reading from: 28672
<info> app: writing to: 32256
<info> app: reading from: 32768
<info> app: writing to: 32768
<info> app: writing to: 33280
<info> app: writing to: 33792
<info> app: writing to: 34304
<info> app: writing to: 34816
<info> app: writing to: 35328
<info> app: writing to: 35840
<info> app: writing to: 36352
<info> app: reading from: 36864
<info> app: writing to: 36864
<info> app: writing to: 37376
<info> app: writing to: 37888
<info> app: writing to: 38400
<info> app: writing to: 38912
<info> app: writing to: 39424
<info> app: writing to: 39936
<info> app: writing to: 40448
<info> app: reading from: 40960
<info> app: writing to: 40960
<info> app: writing to: 41472
<info> app: writing to: 41984
<info> app: writing to: 42496
<info> app: writing to: 43008
<info> app: writing to: 43520
<info> app: writing to: 44032
<info> app: writing to: 44544
<info> app: reading from: 45056
<info> app: writing to: 45056
<info> app: writing to: 45568
<info> app: writing to: 46080
<info> app: writing to: 46592
<info> app: writing to: 47104
<info> app: writing to: 47616
<info> app: writing to: 48128
<info> app: writing to: 48640
<info> app: reading from: 49152
<info> app: writing to: 49152
<info> app: writing to: 49664
<info> app: writing to: 50176
<info> app: writing to: 50688
<info> app: writing to: 51200
<info> app: writing to: 51712
<info> app: writing to: 52224
<info> app: writing to: 52736
<info> app: reading from: 53248
<info> app: writing to: 53248
<info> app: writing to: 53760
<info> app: writing to: 54272
<info> app: writing to: 54784
<info> app: writing to: 55296
<info> app: writing to: 55808
<info> app: writing to: 56320
<info> app: writing to: 56832
<info> app: reading from: 57344
<info> app: writing to: 57344
<info> app: writing to: 57856
<info> app: writing to: 58368
<info> app: writing to: 58880
<info> app: writing to: 59392
<info> app: writing to: 59904
<info> app: writing to: 60416
<info> app: writing to: 60928
<info> app: reading from: 61440
<info> app: writing to: 61440
<info> app: writing to: 61952
<info> app: writing to: 62464
<info> app: writing to: 62976
<info> app: writing to: 63488
<info> app: writing to: 64000
<info> app: writing to: 64512
<info> app: writing to: 65024
<info> app: reading from: 65536
<info> app: writing to: 65536
<info> app: writing to: 66048
<info> app: writing to: 66560
<info> app: writing to: 67072
<info> app: writing to: 67584
<info> app: writing to: 68096
<info> app: writing to: 68608
<info> app: writing to: 69120
<info> app: reading from: 69632
<info> app: writing to: 69632
<info> app: writing to: 70144
<info> app: writing to: 70656
<info> app: writing to: 71168
<info> app: writing to: 71680
<info> app: writing to: 72192
<info> app: writing to: 72704
<info> app: writing to: 73216
<info> app: reading from: 73728
<info> app: writing to: 73728
<info> app: writing to: 74240
<info> app: writing to: 74752
<info> app: writing to: 75264
<info> app: writing to: 75776
<info> app: writing to: 76288
<info> app: writing to: 76800
<info> app: writing to: 77312
<info> app: reading from: 77824
<info> app: writing to: 77824
<info> app: writing to: 78336
<info> app: writing to: 78848
<info> app: writing to: 79360
<info> app: writing to: 79872
<info> app: writing to: 80384
<info> app: writing to: 80896
<info> app: writing to: 81408
<info> app: reading from: 0
<info> app: writing to: 0
<info> app: Mounting volume...
<info> app: reading from: 0
<info> app: reading from: 32256
<info> app: Done

RE: FATFS working on MXIC MX25R6435F but not on S25FS128S

Simonr — Thu, 15 Apr 2021 09:28:44 GMT

Hi again

Seeing as you use SDK v15.2, this could be related to the bug mentioned in this case. Please try implemenitng the nrf_blovk_dev_qspi.c driver file uploaded by my colleague Susheel instead of the one you're using now to see if that helps. If that doesn't help either. This was the only other case in the DevZone archive mentioning the S25FS family, so if you have no luck here either, please double and triple check that the read_id is correct in your case, and if the problem persists, I'll open an internal ticket on the matter, so the developers of our QSPI driver can look at this issue.

Best regards,

Simon

RE: FATFS working on MXIC MX25R6435F but not on S25FS128S

MichielSch — Wed, 14 Apr 2021 14:27:56 GMT

Hi Simon,

Thanks for your response.

I too find it strange. Indeed all or nothing behavior would make way more sense.

What you mention with regards to the 4-byte addressing mode is correct. To get the device working in 4-byte addressing mode one does indeed need to issue the 4BAM command. Which I did like this (based on one of the threads is mentioned above).

            #define QSPI_STD_CMD_EN4B  0xB7 
    
            nrf_qspi_cinstr_conf_t cinstr_cfg2 = {
                    .opcode    = QSPI_STD_CMD_EN4B,
                    .length    = NRF_QSPI_CINSTR_LEN_1B,
                    .io2_level = true,
                    .io3_level = true,
                    .wipwait   = true,
                    .wren      = true
            };
            
            uint32_t err_code = nrf_drv_qspi_cinstr_xfer(&cinstr_cfg2, NULL, NULL);
            APP_ERROR_CHECK(err_code);

I used the following sdk_config.h setting:

// <e> NRFX_QSPI_ENABLED - nrfx_qspi - QSPI peripheral driver
//==========================================================
#ifndef NRFX_QSPI_ENABLED
#define NRFX_QSPI_ENABLED 1
#endif
// <o> NRFX_QSPI_CONFIG_SCK_DELAY - tSHSL, tWHSL and tSHWL in number of 16 MHz periods (62.5 ns).  <0-255> 


#ifndef NRFX_QSPI_CONFIG_SCK_DELAY
#define NRFX_QSPI_CONFIG_SCK_DELAY 1
#endif

// <o> NRFX_QSPI_CONFIG_XIP_OFFSET - Address offset in the external memory for Execute in Place operation. 
#ifndef NRFX_QSPI_CONFIG_XIP_OFFSET
#define NRFX_QSPI_CONFIG_XIP_OFFSET 0
#endif

// <o> NRFX_QSPI_CONFIG_READOC  - Number of data lines and opcode used for reading.
 
// <0=> FastRead 
// <1=> Read2O 
// <2=> Read2IO 
// <3=> Read4O 
// <4=> Read4IO 

#ifndef NRFX_QSPI_CONFIG_READOC
#define NRFX_QSPI_CONFIG_READOC 0
#endif

// <o> NRFX_QSPI_CONFIG_WRITEOC  - Number of data lines and opcode used for writing.
 
// <0=> PP 
// <1=> PP2O 
// <2=> PP4O 
// <3=> PP4IO 

#ifndef NRFX_QSPI_CONFIG_WRITEOC
#define NRFX_QSPI_CONFIG_WRITEOC 0
#endif

// <o> NRFX_QSPI_CONFIG_ADDRMODE  - Addressing mode.
 
// <0=> 24bit 
// <1=> 32bit 

#ifndef NRFX_QSPI_CONFIG_ADDRMODE
#define NRFX_QSPI_CONFIG_ADDRMODE 1
#endif

// <o> NRFX_QSPI_CONFIG_MODE  - SPI mode.
 
// <0=> Mode 0 
// <1=> Mode 1 

#ifndef NRFX_QSPI_CONFIG_MODE
#define NRFX_QSPI_CONFIG_MODE 0
#endif

// <o> NRFX_QSPI_CONFIG_FREQUENCY  - Frequency divider.
 
// <0=> 32MHz/1 
// <1=> 32MHz/2 
// <2=> 32MHz/3 
// <3=> 32MHz/4 
// <4=> 32MHz/5 
// <5=> 32MHz/6 
// <6=> 32MHz/7 
// <7=> 32MHz/8 
// <8=> 32MHz/9 
// <9=> 32MHz/10 
// <10=> 32MHz/11 
// <11=> 32MHz/12 
// <12=> 32MHz/13 
// <13=> 32MHz/14 
// <14=> 32MHz/15 
// <15=> 32MHz/16 

#ifndef NRFX_QSPI_CONFIG_FREQUENCY
#define NRFX_QSPI_CONFIG_FREQUENCY 15
#endif

// <s> NRFX_QSPI_PIN_SCK - SCK pin value.
#ifndef NRFX_QSPI_PIN_SCK
#define NRFX_QSPI_PIN_SCK NRF_QSPI_PIN_NOT_CONNECTED
#endif

// <s> NRFX_QSPI_PIN_CSN - CSN pin value.
#ifndef NRFX_QSPI_PIN_CSN
#define NRFX_QSPI_PIN_CSN NRF_QSPI_PIN_NOT_CONNECTED
#endif

// <s> NRFX_QSPI_PIN_IO0 - IO0 pin value.
#ifndef NRFX_QSPI_PIN_IO0
#define NRFX_QSPI_PIN_IO0 NRF_QSPI_PIN_NOT_CONNECTED
#endif

// <s> NRFX_QSPI_PIN_IO1 - IO1 pin value.
#ifndef NRFX_QSPI_PIN_IO1
#define NRFX_QSPI_PIN_IO1 NRF_QSPI_PIN_NOT_CONNECTED
#endif

// <s> NRFX_QSPI_PIN_IO2 - IO2 pin value.
#ifndef NRFX_QSPI_PIN_IO2
#define NRFX_QSPI_PIN_IO2 NRF_QSPI_PIN_NOT_CONNECTED
#endif

// <s> NRFX_QSPI_PIN_IO3 - IO3 pin value.
#ifndef NRFX_QSPI_PIN_IO3
#define NRFX_QSPI_PIN_IO3 NRF_QSPI_PIN_NOT_CONNECTED
#endif

// <o> NRFX_QSPI_CONFIG_IRQ_PRIORITY  - Interrupt priority
 
// <0=> 0 (highest) 
// <1=> 1 
// <2=> 2 
// <3=> 3 
// <4=> 4 
// <5=> 5 
// <6=> 6 
// <7=> 7 

#ifndef NRFX_QSPI_CONFIG_IRQ_PRIORITY
#define NRFX_QSPI_CONFIG_IRQ_PRIORITY 6
#endif

But like I said when I properly configure the addressing mode and I create the file system within the same addressing mode I get the same behavior: A mountable filesystem to which I cannot seem to write anything.

Do you know if there are cases where somebody successfully used the fatfs with this memory chip or at least one in the same "family"? We are really confused about what could be wrong since I would guess with all the checks in the nrf_block_dev_qspi.c code actual malfunctioning on the qspi level would be caught (I am thinking timeouts, non responsive qspi, etc).

Thanks and best regards,

Michiel

RE: FATFS working on MXIC MX25R6435F but not on S25FS128S

Simonr — Wed, 14 Apr 2021 13:05:43 GMT

Hi Michiel

This sounds strange indeed, as I would assume it would be all or nothing. I think the SDK configuration for addressing mode (I.E. 32-bit addressing mode) only changes the addressing mode in the QSPI peripheral. The external flash also needs to be told what mode it's expected to work in somehow. This command can be different from flash vendor to flash vendor, so it's hard to implement in one of our drivers.

To do that for the S25FS series, I think you need to issue the 4BAM (see S25FS128S datasheet) command using a custom instruction (which is described in our QSPI peripheral documentation in the nRF52840 PS).

When both the flash and QSPI peripheral are in 4-byte addressing mode, our peripheral uses the commands from the Flash part's datasheet with 4-byte addresses.

Best regards,

Simon