MT29 filesystem mount problems (IEC-169)

[mttcarbone]

Answers checklist.

• I have read the documentation of the component in question and the issue is not addressed there.
• I have searched the issue tracker for a similar issue and not found a similar issue.

General issue report

I am using this library on a project with MT29F2G01ABAGD, I am experiencing problems starting esp32-s3:
returns this warning vfs_fat_nand: f_mount failed (13)
the flash is formatted, and proceeds to write and read the hello.txt file

What can I do to avoid formatting the flash every boot?

Doing other tests, if I unmounted and mount the flash the hello.txt file is read incorrectly, and it truncates "HELLO TXT" as its contents, what can I do to avoid this?

[igrr]

Could you please try to verify that basic read and write operations to flash work correctly? FatFS error 13 usually indicates that the filesystem is corrupted. The most common case is that the underlying Flash driver isn't transferring some data correctly in one of the directions. You can try calling spi_nand_flash_write_sector and spi_nand_flash_read_sector to write some test data and then verify that the read back result is the same.

By the way, since this flash chip is not on the list of supported ones, it might make sense to check its datasheet and see if there is any difference related to timing, compared to other supported chips.

[Teesmo]

@igrr What Micron Chips do you support? (There are none listed here), but provision has been made for Micron chips in this header file. There's also an implentation here that caters for multiple vendors, including Micron.

[igrr]

AFAIK we haven't tested this component on any of the Micron chips. Micron support was contributed by @UnTraDe in #327. I guess @UnTraDe used it successfully, maybe there is something slightly different in your hardware setup. As I mentioned above, I would recommend doing a basic write/readback sanity check to make sure that the data is being written correctly.

By the way, do you folks work on the same project or it just so happened that you both need Micron NAND flash support? If it's the latter, we can try to get some samples of that chip and test them...

[mttcarbone]

@igrr Thank you for the support!
We are different team, I chose micron because of cost issue, comparing with the nand flash on the market it has good prices.
It would be great to have your support, extend support to micron like the MT29F2G01ABAGDWB in my possession and share it with the community and help other teams!

[igrr]

Okay, we'll order some boards with MT29 chips, might take some time (worst case, 2 weeks) to get them.

In the meantime perhaps you could do the test I have suggested above and share the result you get.

[mttcarbone]

Great! Thank you!
I'm following your directions, hope to share some valuable considerations and update on my evidence as early as the next few days.

[UnTraDe]

Hi, we are currently using this driver with MT29F4G01ABAFDWB successfully, it should work on the rest of the MT29F series. As far as I understand the differences between the chips in this series is the size and organization of the memory itself (page size, block size, etc), so the only thing needed to add support for them is the ID of the model and the different sizes. Take a look at the changes here: https://github.com/espressif/idf-extra-components/pull/327/files

[mttcarbone]

I report here the part of code that I added to the library:

• flash device id,
• extended the switch cases log2_page_size and num_blocks, as seen in the code below.

I have several doubts:

• About the 2 plane structure of the flash and the "Block RA6 controls the plane selection" handling reported in the datasheet of the board;
• about the delay_us delays.

static esp_err_t spi_nand_micron_init(spi_nand_flash_device_t *dev)
{
    uint8_t device_id;
    spi_nand_transaction_t t = {
        .command = CMD_READ_ID,
        .dummy_bits = 16,
        .miso_len = 1,
        .miso_data = &device_id
    };
    spi_nand_execute_transaction(dev->config.device_handle, &t);
    dev->read_page_delay_us = 115;
    dev->erase_block_delay_us = 2000;
    dev->program_page_delay_us = 240;
    switch (device_id) {
    case MICRON_DI_34:
        dev->dhara_nand.num_blocks = 2048;
        dev->dhara_nand.log2_ppb = 6;        // 64 pages per block
        dev->dhara_nand.log2_page_size = 12; // 4096 bytes per page
        break;
    case MICRON_DI_24:
        dev->dhara_nand.num_blocks = 1024;
        dev->dhara_nand.log2_ppb = 6;        
        dev->dhara_nand.log2_page_size = 11; 
        break;
    default:
        return ESP_ERR_INVALID_RESPONSE;
    }
    return ESP_OK;
}

Looking at the flash structure, is there anything wrong in the configuration?
@UnTraDe Thanks for your input and for helping me!

[mttcarbone]

Hi @igrr ,
I did the tests you mentioned, I used the spi_nand_flash_read_sector function to see if it wrote correctly to the sectors. The thing does not return any errors.

By increasing .allocation_unit_size = 32 * 1024 from 16 to 32 when I go to re-read the file it comes back correct. There remains the problem that at each reboot of the esp32-s3 the memory is formatted because the file system mount goes errorre.

Analyzing SPI, I saw that QSPI WP and HD pins are not working, is this normal? My spi configuration is this:

#define HOST_ID SPI3_HOST
#define PIN_MOSI (16) 
#define PIN_MISO (14) 
#define PIN_CLK (15) 
#define PIN_CS (13) 
#define PIN_WP (40) 
#define PIN_HD (41) 
#define SPI_DMA_CHAN SPI_DMA_CH_AUTO 

I chose SPI3_HOST, because in the future SPI2_HOST will be used for a display

[igrr]

I did the tests you mentioned, I used the spi_nand_flash_read_sector function to see if it wrote correctly to the sectors. The thing does not return any errors.

Could you please clarify how you tested this? spi_nand_flash_read_sector doesn't write sectors, you need to call spi_nand_flash_write_sector in order to do that. To check if the data has been written correctly, compare the data you read back to the one you originally wrote.

You can check this code from the test app:

idf-extra-components/spi_nand_flash/test_app/main/test_spi_nand_flash.c

Lines 129 to 153 in 0603d10

	static void do_single_write_test(spi_nand_flash_device_t *flash, uint32_t start_sec, uint16_t sec_count)
	{
	uint8_t *temp_buf = NULL;
	uint8_t *pattern_buf = NULL;
	uint32_t sector_size, sector_num;
	TEST_ESP_OK(spi_nand_flash_get_capacity(flash, &sector_num));
	TEST_ESP_OK(spi_nand_flash_get_sector_size(flash, &sector_size));
	TEST_ESP_OK((start_sec + sec_count) > sector_num);
	pattern_buf = (uint8_t *)heap_caps_malloc(sector_size, MALLOC_CAP_DEFAULT);
	TEST_ASSERT_NOT_NULL(pattern_buf);
	temp_buf = (uint8_t *)heap_caps_malloc(sector_size, MALLOC_CAP_DEFAULT);
	TEST_ASSERT_NOT_NULL(temp_buf);
	fill_buffer(PATTERN_SEED, pattern_buf, sector_size / sizeof(uint32_t));
	for (int i = start_sec; i < sec_count; i++) {
	TEST_ESP_OK(spi_nand_flash_write_sector(flash, pattern_buf, i));
	memset((void *)temp_buf, 0x00, sector_size);
	TEST_ESP_OK(spi_nand_flash_read_sector(flash, temp_buf, i));
	check_buffer(PATTERN_SEED, temp_buf, sector_size / sizeof(uint32_t));
	}
	}

Analyzing SPI, I saw that QSPI WP and HD pins are not working, is this normal?

Yes, that's normal, currently the library doesn't make use of DIO or QIO related commands, there is a discussion about that in another issue: #375 (comment).

[mttcarbone]

Hi @igrr ,
I ran the following code in the main:

    uint32_t sector_num, sector_size;
    spi_nand_flash_device_t *nand_flash_device_handle;
    spi_device_handle_t spi;
    setup_nand_flash(&nand_flash_device_handle, &spi);

    TEST_ESP_OK(spi_nand_flash_get_capacity(nand_flash_device_handle, &sector_num));
    TEST_ESP_OK(spi_nand_flash_get_sector_size(nand_flash_device_handle, &sector_size));
    printf("Number of sectors: %" PRIu32 ", Sector size: %" PRIu32 "\n", sector_num, sector_size);

    do_single_write_test(nand_flash_device_handle, 1, 16);
    do_single_write_test(nand_flash_device_handle, 16, 32);
    do_single_write_test(nand_flash_device_handle, 32, 64);
    do_single_write_test(nand_flash_device_handle, 64, 128);
    do_single_write_test(nand_flash_device_handle, sector_num / 2, 32);
    do_single_write_test(nand_flash_device_handle, sector_num / 2, 256);
    do_single_write_test(nand_flash_device_handle, sector_num - 20, 16);

    deinit_nand_flash(nand_flash_device_handle, spi);

With the following flash configuration:

static esp_err_t spi_nand_micron_init(spi_nand_flash_device_t *dev)
{
    uint8_t device_id;
    spi_nand_transaction_t t = {
        .command = CMD_READ_ID,
        .dummy_bits = 16,
        .miso_len = 1,
        .miso_data = &device_id
    };
    spi_nand_execute_transaction(dev->config.device_handle, &t);
    switch (device_id) {
    case MICRON_DI_34:
        dev->read_page_delay_us = 115;
        dev->erase_block_delay_us = 2000;
        dev->program_page_delay_us = 240;
        dev->dhara_nand.num_blocks = 2048;
        dev->dhara_nand.log2_ppb = 6;        // 64 pages per block
        dev->dhara_nand.log2_page_size = 12; // 4096 bytes per page
        break;
    case MICRON_DI_24:
        dev->read_page_delay_us = 55;
        dev->erase_block_delay_us = 2000;
        dev->program_page_delay_us = 220;
        dev->dhara_nand.num_blocks = 2048;
        dev->dhara_nand.log2_ppb = 6;        
        dev->dhara_nand.log2_page_size = 11; 
        break;
    default:
        return ESP_ERR_INVALID_RESPONSE;
    }
    return ESP_OK;
}

I get this error back:

Reading the datasheet, I saw this part here:

As you can see the 12bit is passed the plane of the flash, unlike the 4Gb model, where it is not needed.
Looking at the library I can't figure out where to pass the plane bit, could you direct me?

[igrr]

I don't think any special handling is needed for the plane index. The driver is sending a 16-bit block address to the flash chip:

• Three MSBs (15-13) are ignored by the flash chip since they are above the 2GB capacity
• Bit 12 of the column address sets the plane index
• The rest of the bit set the block index within the plane

The only thing which looks odd is that according to figure 7, the plane index should be the LSB of the address, not MSB. However this only changes the mapping of addresses to the physical blocks in Flash, aside from some performance difference it should still work either way.

The exception you got seems unrelated to this problem, but I can't tell what specifically is wrong since the exception output is cut off in your screenshot. Please check https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-guides/fatal-errors.html for instructions on how to interpret exception output. If you post the logs, please do post them in text format rather than as images. It might also help to decrease the log level from "verbose" to "info" or "debug" since there seems to be a lot of unrelated messages in the log.

[mttcarbone]

Sorry @igrr ,
I'll fix this right away, I'll send you a file with monitor output, with debug functions turned on.
I hope it can give you enough information.

debug_output.txt