QSPI block device issue with S25FS flash part

RE: QSPI block device issue with S25FS flash part

bartoszmichalak19 — Tue, 04 Oct 2022 06:19:35 GMT

I am reproducing simmilar problems on nrf52840 devkit (PCA10056) with qspi memory MX25R6435F. The result is that if I write something(block size=256) to 16 block and then write something to 17 block the previous one(16 block) is corrupted (full of zeros). I dont reproduce this behavior on any of other blocks (I checked almost all flash memory space). The solution you proposed seems to fix this issue.

"bypassing unnecessary write when erase_unit_dirty_blocks is zero, the IRQ should reload erase_unit_idx with the correct value.

Please replace your qspi_block dev driver file with the below"

I am using sdk 15.3.0. As I see the most important diff from your solution is in block_dev_qspi_write_start function (the rest are additional asserts). I checked that any of further SDK versions does not contain this fix. My question is if you already fixed this issue in futher SDK's >15.3 ? If yes could you point me how? I am wondering whether fix you proposed 3 years ago is final solution or I should upgrade something else in my sdk version?

RE: QSPI block device issue with S25FS flash part

CheMax — Tue, 25 Feb 2020 08:46:26 GMT

Thank you very much.

Yesterday I tried the solutions suggested by the links and everything worked out.

In addition, I would like to suggest the following change to the file nrf_block_dev_qspi.c.

static ret_code_t block_dev_qspi_init(nrf_block_dev_t const * p_blk_dev,
                                      nrf_block_dev_ev_handler ev_handler,
                                      void const * p_context)
{
    ...
    // Enable 32bit address mode if need
    #if QSPI_CONFIG_ADDRMODE == 1
        #if QSPI_FLASH_USE_EN4B_CMD == 1
            // in sdk_config or another place
            #define QSPI_STD_CMD_EN4B  0xB7 // for example for mx66u2g45g
    
            nrf_qspi_cinstr_conf_t cinstr_cfg = {
                    .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_cfg, NULL, NULL);
            APP_ERROR_CHECK(err_code);
        #endif
    #endif
    
     /* Get 3 byte identification value */
    uint8_t rdid_buf[3] = {0, 0, 0};
    cinstr_cfg.opcode = QSPI_STD_CMD_READ_ID;
    cinstr_cfg.length = NRF_QSPI_CINSTR_LEN_4B;
    ret = nrf_drv_qspi_cinstr_xfer(&cinstr_cfg, NULL, rdid_buf);
    if (ret != NRF_SUCCESS)
    {
        NRF_LOG_INST_ERROR(p_qspi_dev->p_log, "QSPI get 3 byte id error: %"PRIu32"", ret);
        return ret;
    }
    ...
}

The universality of the driver is preserved, but it is becoming more flexible. Now the developer can specify the instructions for switching to 32-bit mode, if necessary.

Nordic team, when to expect the correct driver version with unchecked changes:

/ * Bypass write .... * / ?

RE: QSPI block device issue with S25FS flash part

Sumanth Murali — Fri, 21 Feb 2020 16:11:29 GMT

RE: QSPI block device issue with S25FS flash part

CheMax — Fri, 21 Feb 2020 12:19:52 GMT

Hi Susheel,

I have a similar problem, but with a different memory chip (Macronix, mx66u2g45g, 1 Gb):
when viewing the contents of the disk through the utility "WinHex", I see that the data is repeated every 16 MB (offset 0x0100 0000).

e.g. original file location is 0x0004 6000, but in memory address 0x0104 6000, 0x0204 6000, ... are located dublicate of my file.

This patch solves the problem of repeating the file table during formatting, but does not solve the problem of writing files.

Also, at some point, the record is made in sector 0 and grinds the file table. Because of this, the data on the map is not available.

When testing, I used SDK 16.0.0
I really hope for an ambulance in this matter, since a batch of devices has already been made ...

Additional information, after full disk format some sectors have the correct content (for NAND flash) for the cleared state (FF), others have an incorrect value (00).

best Regards,

Max

RE: QSPI block device issue with S25FS flash part

Susheel Nuguru — Thu, 17 Oct 2019 06:41:21 GMT

Sumanth,

64KB erase unit size is something we haven't tested. The implementation assumes that the erase unit is stored in RAM and not sure if you are seeing any behaviour that could be caused by data overflows in RAM. Additionally this implementation supports (maximum) 32 write blocks inside one erase unit. It means that block_size fields in qspi_bdev_config has to be set to 2kB

It should theoretically work but like I mentioned, we haven't tested those sizes yet.

RE: QSPI block device issue with S25FS flash part

Sumanth Murali — Mon, 14 Oct 2019 19:07:56 GMT

Hi Susheel,

Thanks for the update. However i still see issues when i change the NRF_BLOCK_DEV_QSPI_ERASE_UNIT_SIZE to 64KB and m_sflash_params.erase_size = 64KB.

For some reason the code only works for 4KB erase unit size. The flash part we are using has 64 KB erase size. Any idea why?

RE: QSPI block device issue with S25FS flash part

Susheel Nuguru — Thu, 03 Oct 2019 10:29:08 GMT

Hi Sumanth,

All the concerns you had with wrong initialization values were converging into a bug where there could be unnecessary write writes. So we opted for a simple solution now to avoid unnecessarily writes and adding a few more checks.

erase_unit_idx initialized with -1 could provide extra write to memory, but now with bypassing unnecessary write when erase_unit_dirty_blocks is zero, the IRQ should reload erase_unit_idx with the correct value.

Please replace your qspi_block dev driver file with the below

devzone.nordicsemi.com/.../nrf_5F00_block_5F00_dev_5F00_qspi.c

The team is also reconsidering to refactor most of the code, but that is something that is long on the roadmap, so please do not wait for that in the near term.

/Susheel

RE: QSPI block device issue with S25FS flash part

Sumanth Murali — Wed, 02 Oct 2019 19:50:25 GMT

Any ETA? Also can we get the patch so we can try it out?

RE: QSPI block device issue with S25FS flash part

Kenneth — Wed, 25 Sep 2019 20:25:49 GMT

They have found the root cause and understood the issue. This issue may have a broader impact on the behavior of the driver. They need a few more days to prepare software test harness, investigation and solving the issue.

RE: QSPI block device issue with S25FS flash part

Kenneth — Mon, 23 Sep 2019 13:02:41 GMT

Hi, latest is that we expect to have a fix tomorrow.

Best regards,
Kenneth

RE: QSPI block device issue with S25FS flash part

Kenneth — Thu, 19 Sep 2019 16:12:10 GMT

This is taking longer than anticipated, I likely won't have an update until next week.

Kenneth

RE: QSPI block device issue with S25FS flash part

Kenneth — Wed, 18 Sep 2019 07:26:03 GMT

I will ping the team again. Sorry for the delay.

Kenneth

RE: QSPI block device issue with S25FS flash part

Sumanth Murali — Wed, 18 Sep 2019 03:38:52 GMT

Any updates??

RE: QSPI block device issue with S25FS flash part

Kenneth — Mon, 09 Sep 2019 13:45:03 GMT

The SDK team is looking into this this week.

RE: QSPI block device issue with S25FS flash part

Sumanth Murali — Wed, 04 Sep 2019 21:00:13 GMT

Any update on this?

RE: QSPI block device issue with S25FS flash part

Susheel Nuguru — Mon, 19 Aug 2019 07:07:31 GMT

Hi Sumanth, The SDK team said they will look into this querry as soon as they get some time (with escalated priority)
I will update you as soon as I get some information from them.

Sorry for the inconvenience caused by these delays.

RE: QSPI block device issue with S25FS flash part

Susheel Nuguru — Wed, 07 Aug 2019 10:55:47 GMT

Unfortunately, this is taking longer to get a response from the team. Please contact clay.hine@nordicsemi.no (your Regional Sales Manager) to escalate this if it is very urgent for you to get an answer for this.

RE: QSPI block device issue with S25FS flash part

Sumanth Murali — Tue, 06 Aug 2019 21:14:20 GMT

Any updates? This is very important for us.

RE: QSPI block device issue with S25FS flash part

Sumanth Murali — Thu, 01 Aug 2019 17:57:15 GMT

Yes, thanks, it will be good to have some sort of documentation on how this block device interface works along with answers for the above questions.

RE: QSPI block device issue with S25FS flash part

Susheel Nuguru — Thu, 01 Aug 2019 12:28:05 GMT

Your questions seem very valid, and I do not have answers to them, I have asked the experts to pitch in and help us to understand the code you provided. I hope they respond soon.