Help Wanted: nRF52840 QSPI + FatFS to Winbond W25N01GV

[blueshifting]

Looking for help creating an example similar to the usbd_msc example that works with the W25N01GV. Currently using SDK 15.0. Would like to see this work with FatFS or possibly another alternative better suited for flash. Please inquire in direct message here. Thanks!

[Mihal]

Hi, have you solved it? I have problems with this memory too

[blueshifting]

I've not, though I've some ideas on how I'm going to do it. Just haven't gotten to that task yet. 

[Edvin]

Hello,

At least in SDK15.2.0 the usbd_msc project uses QSPI. Although it only creates random files (random file names) instead of writing to the files, it is possible to use this project to write in the files as well.

If you replace fatfs_file_create() with this function:

static void fatfs_create_test_file(void)
{
    FRESULT ff_result;
    FIL file;
    uint32_t file_size = 0;

    ff_result = f_open(&file, "my_file.txt", FA_READ);
    if (ff_result != FR_OK)
    {
        NRF_LOG_ERROR("my_file.txt Does not exist\r\n");
        NRF_LOG_INFO("Creating my_file.txt");
        ff_result = f_open(&file, "my_file.txt", FA_CREATE_ALWAYS | FA_WRITE);
        if (ff_result != FR_OK)
        {
            if(!m_usb_connected)
                NRF_LOG_ERROR("Unable to open or create file: my_file.txt");
            NRF_LOG_FLUSH();
            return;
        }
    }

    ff_result = f_close(&file);
    if (ff_result != FR_OK)
    {
        NRF_LOG_ERROR("Unable to close file: %u \r\n", ff_result);
        NRF_LOG_FLUSH();
        return;
    }

    file_size = f_size(&file);
    NRF_LOG_INFO("my_file.txt create SUCCESSFUL; file size = %d\r\n", file_size);
}

To create a specific file, and then you can use a function similar to this to write data to the file:

static void write()
{
    int i = 0;
    char log_record[128] = {0};
    char log_record_r[128] = {0};

    FRESULT ff_result;
    FIL file;
    uint32_t fileSize;

    ff_result = f_open(&file, "my_file.txt", FA_OPEN_APPEND | FA_OPEN_ALWAYS | FA_WRITE | FA_READ);
    if (ff_result != FR_OK)
    {
        if(!m_usb_connected)
            NRF_LOG_INFO("Unable to open or create my_file.txt: %u", ff_result);
        NRF_LOG_FLUSH();
        return;
    }


    sprintf(log_record, "Helloworld!\r\n");


    FSIZE_t ptr = f_tell(&file);

    i = f_printf(&file, log_record);

    i = f_close(&file);
    if (i != 0)
    {
      NRF_LOG_INFO("f_close != 0, %d", i);
    }

    NRF_LOG_INFO("Wrote Data Record");
}

Best regards,

Edvin

[Mihal]

Well. Actually i think my problem is in a different plane. Looks like i can't access memory properly.

Data is valid if i do a simple write/read test like in qspi example. But it does not stay the same after power down and addressing works weird. So i think that problem is in the different set of commands implemented in W25N01GV and in a chip used in PDK. 

But the point is that i don't really understand how qspi driver works and whether i can fix it. Well, it's pretty clear that each function encapsulate a whole set of memory instructions but i guess there are no source in open access

[blueshifting]

I noticed the same thing: basic qspi write and validate read works, but the general state of the Nordic QSPI peripheral seems unsuited for NAND SPI flash. I will also admit not fully understanding how QSPI works - particularly when it comes to opcodes and write-enables, etc. 

Currently I've been thinking about using SPI3 @ 32Mhz instead of QSPI and accessing the flash that way. 

[Mihal]

well, i think it's possible to make a kind of your own driver by encapsulating bunches of nrfx_qspi_cinstr_xfer(). But it's blocking as i can see, so there is another big problem. maybe it's possible to combine them somehow with standard read/write