QSPI Flash file system problem 'Not a BS' with MicroPython on STM32F722IEK6

[RichardB-RT]

Hello, i am trying to use MicroPython on a custom hardware board based on a STM32F722IEK6 chip.
The board contains 2 external QSPI flash chips (AT25SF641B) and is programmed using a Segger j-link using j-flash.
First mboot.hex is flashed, after that micropython.hex.

When connected using PuTTY to the REPL, the messages "MPY: can't create filesystem" and "MPY: can't mount flash" are printed.
Searching in the MicroPython codebase this error is caused by function 'check_fs()' called by 'find_volume()' in \lib\oofatfs\ff.c.
This function returns the value 3 (line 3091) which indicates 'Not a BS'.

This line:
if (ld_word(fs->win + BS_55AA) != 0xAA55) return 3; /* Check boot record signature (always here regardless of the sector size) */

What does this fault 'Not a BS' mean and what causes it? Anyone can help me with this?

Further investigation revealed that MicroPython tries to create the FAT partition (MBR is signed with special code 0xAA55) . No errors are returned in the process, but when an attempt is made by MicroPython to read the FAT partition the special code 0xAA55 could not be read and 0xCCCC is returned and hence "MPY: can't create filesystem" is printed. It seems like a timeout occurs while writing data to the QSPI but this error does not always bubble up. This timeout occurs in the mp_spiflash_wait_wip0() function in spiflash.c. In this function it waits for the QSPI to become idle, but times out.

Any help is appreciated, i am still trying to find the root cause...

[robert-hh]

The code expects the Flash to be formatted as FAT file sytem and complain, that it is not. It should then format it as FAT. Maybe that failed. Maybe you could try to create the file sytem from the REPL command line. See https://docs.micropython.org/en/latest/reference/filesystem.html#fat

import os, vfs, pyb
vfs.umount('/flash')
vfs.VfsFat.mkfs(pyb.Flash(start=0))
vfs.mount(pyb.Flash(start=0), '/flash')
os.chdir('/flash')

[RichardB-RT]

Thank you for the reply. The command vfs.VfsFat.mkfs() hangs the moment i press enter. The red led stays on for a long period of time, then goes off. Soft reset does not work and the only way to get connected again using PuTTY is to reconnect the usb cable.
The QSPI flash extension chips are not connected to a dedicated SPI bus of the STM32 and hence difficult to use separately. They are used by Micropython as a memory mapped device.
What do you suggest to try next? Is it possible to communicate to the QSPI chips on a low level?

[bidrohini]

The fault "Not a BS" in the context of the check_fs() function from the MicroPython codebase refers to an issue with the Boot Sector (BS) of the filesystem. This fault usually occurs when the memory (in this case, the QSPI flash) does not contain a valid filesystem. It could mean that the flash is unformatted or corrupted.

[RichardB-RT]

The flash is not formatted because the vfs.VfsFat,mkfs() call fails. The strange thing is that J-Link is able to program a hex file into the QSPI flash and verify it, so i guess this means communications with the QSPI is working. Could it be that MBoot fails to create the FAT?

[RichardB-RT]

Yesterday i soldered wires to the QSPI pins to make the data visible on Picoscope. Micropython can communicate with the QSPI flash, so no hardware problem there.
The board contains 2 QSPI flash chips. One at address 0x90000000 (firmware extension) and one at address 0x80000000 (file system).
How can i manually give the command in the REPL to create a file system on the flash with address 0x80000000 ? Because i think the vfs.VfsFat.mkfs() call will use the flash at address 0x90000000...

[RichardB-RT]

MicroPython version: 1.24
Yesterday i added printf() statements to MicroPython firmware to see what goes wrong with QSPI communication and the file system in general. It seems that MicroPython builds a partition table (writes the 0xAA55 at the end of partition) but when this code is read it is read as 0xcccc. Sometimes a timeout occurs during the write to the QSPI flash during the flush.
One things i find very strange and cannot find an answer to:

1. somehow MicroPython seems to think the QSPI flash contains only 1 block. Why is that? I use the standard configuration of PYBD_SF2.

Below REPL output (with printf statements). sr = status register of the QSPI.
`
▒▒R▒,oR▒,oV3-#▒R▒$▒́▒

storage_init() >>
sr: 2, mask:1, val:0
OK => sr: 2, mask:1, val:0
mp_vfs_blockdev_init() >>
fat_vfs_make_new() >>
mp_vfs_blockdev_init() >>
mp_vfs_blockdev_ioctl() >>
check_fs() start
storage_read_blocks(0, 1) >>
storage_read_block(0): FAKE MBR!
build_partition(0, 1, 256, 4096) >>
build_partition(0, 0, 0, 0) >>
build_partition(0, 0, 0, 0) >>
build_partition(0, 0, 0, 0) >>
check_fs(sig = aa55)
check_fs() end
check_fs() start
storage_read_blocks(256, 1) >>
storage_read_blocks(): PART1 read
spi_rb(0, 1) >>
mp_spiflash_cached_read() >>
<< mp_spiflash_cached_read()
spi_rb():0
check_fs(sig = cccc)
mp_vfs_blockdev_ioctl() >>
storage_read_blocks(0, 1) >>
storage_read_block(0): FAKE MBR!
build_partition(0, 1, 256, 4096) >>
build_partition(0, 0, 0, 0) >>
build_partition(0, 0, 0, 0) >>
build_partition(0, 0, 0, 0) >>
storage_write_blocks() >>
spi_wb() >>
result:0
storage_write_blocks() >>
spi_wb() >>
result:0
storage_write_blocks() >>
spi_wb() >>
result:0
storage_write_blocks() >>
spi_wb() >>
result:0
storage_write_blocks() >>
spi_wb() >>
result:0
storage_write_blocks() >>
spi_wb() >>
result:0
storage_write_blocks() >>
spi_wb() >>
result:0
storage_write_blocks() >>
spi_wb() >>
result:0
storage_write_blocks() >>
spi_wb() >>
mp_spiflash_cache_flush_internal() >>
mp_spiflash_erase_block_internal() >>
OK => sr: 0, mask:1, val:0
mp_spiflash_cache_flush_internal() end >>
result:0
storage_write_blocks() >>
spi_wb() >>
result:0
storage_write_blocks() >>
spi_wb() >>
result:0
storage_write_blocks() >>
spi_wb() >>
result:0
storage_write_blocks() >>
spi_wb() >>
result:0
storage_write_blocks() >>
spi_wb() >>
result:0
storage_write_blocks() >>
spi_wb() >>
result:0
storage_write_blocks() >>
spi_wb() >>
result:0
storage_write_blocks() >>
spi_wb() >>
mp_spiflash_cache_flush_internal() >>
mp_spiflash_erase_block_internal() >>
OK => sr: 0, mask:1, val:0
mp_spiflash_cache_flush_internal() end >>
result:0
storage_write_blocks() >>
spi_wb() >>
result:0
storage_write_blocks() >>
spi_wb() >>
result:0
storage_write_blocks() >>
spi_wb() >>
result:0
storage_write_blocks() >>
spi_wb() >>
result:0
storage_write_blocks() >>
spi_wb() >>
result:0
storage_write_blocks() >>
spi_wb() >>
result:0
storage_write_blocks() >>
spi_wb() >>
result:0
storage_write_blocks() >>
spi_wb() >>
mp_spiflash_cache_flush_internal() >>
mp_spiflash_erase_block_internal() >>
OK => sr: 0, mask:1, val:0
mp_spiflash_cache_flush_internal() end >>
result:0
storage_write_blocks() >>
spi_wb() >>
result:0
storage_write_blocks() >>
spi_wb() >>
result:0
storage_write_blocks() >>
spi_wb() >>
result:0
storage_write_blocks() >>
spi_wb() >>
result:0
storage_write_blocks() >>
spi_wb() >>
result:0
storage_write_blocks() >>
spi_wb() >>
result:0
storage_write_blocks() >>
spi_wb() >>
result:0
storage_write_blocks() >>
spi_wb() >>
mp_spiflash_cache_flush_internal() >>
mp_spiflash_erase_block_internal() >>
OK => sr: 0, mask:1, val:0
mp_spiflash_cache_flush_internal() end >>
result:0
storage_write_blocks() >>
spi_wb() >>
result:0
storage_write_blocks() >>
spi_wb() >>
result:0
storage_write_blocks() >>
spi_wb() >>
result:0
storage_write_blocks() >>
spi_wb() >>
result:0
storage_write_blocks() >>
spi_wb() >>
result:0
storage_write_blocks() >>
spi_wb() >>
result:0
storage_write_blocks() >>
spi_wb() >>
result:0
storage_read_blocks(0, 1) >>
storage_read_block(0): FAKE MBR!
build_partition(0, 1, 256, 4096) >>
build_partition(0, 0, 0, 0) >>
build_partition(0, 0, 0, 0) >>
build_partition(0, 0, 0, 0) >>
storage_write_blocks() >>
succes
mp_vfs_blockdev_ioctl() >>
mp_spiflash_cache_flush_internal() >>
mp_spiflash_erase_block_internal() >>
OK => sr: 0, mask:1, val:0
mp_spiflash_cache_flush_internal() end >>
mp_vfs_blockdev_ioctl() >>
check_fs() start
storage_read_blocks(0, 1) >>
storage_read_block(0): FAKE MBR!
build_partition(0, 1, 256, 4096) >>
build_partition(0, 0, 0, 0) >>
build_partition(0, 0, 0, 0) >>
build_partition(0, 0, 0, 0) >>
check_fs(sig = aa55)
check_fs() end
check_fs() start
storage_read_blocks(256, 1) >>
storage_read_blocks(): PART1 read
spi_rb(0, 1) >>
mp_spiflash_cached_read() >>
<< mp_spiflash_cached_read()
spi_rb():0
check_fs(sig = cccc)
mp_vfs_blockdev_ioctl() >>
check_fs() start
storage_read_blocks(0, 1) >>
storage_read_block(0): FAKE MBR!
build_partition(0, 1, 256, 4096) >>
build_partition(0, 0, 0, 0) >>
build_partition(0, 0, 0, 0) >>
build_partition(0, 0, 0, 0) >>
check_fs(sig = aa55)
check_fs() end
check_fs() start
storage_read_blocks(256, 1) >>
storage_read_blocks(): PART1 read
spi_rb(0, 1) >>
mp_spiflash_cached_read() >>
<< mp_spiflash_cached_read()
spi_rb():0
check_fs(sig = cccc)
mp_vfs_blockdev_ioctl() >>
check_fs() start
storage_read_blocks(0, 1) >>
storage_read_block(0): FAKE MBR!
build_partition(0, 1, 256, 4096) >>
build_partition(0, 0, 0, 0) >>
build_partition(0, 0, 0, 0) >>
build_partition(0, 0, 0, 0) >>
check_fs(sig = aa55)
check_fs() end
check_fs() start
storage_read_blocks(256, 1) >>
storage_read_blocks(): PART1 read
spi_rb(0, 1) >>
mp_spiflash_cached_read() >>
<< mp_spiflash_cached_read()
spi_rb():0
check_fs(sig = cccc)
mp_vfs_blockdev_init() >>
fat_vfs_make_new() >>
mp_vfs_blockdev_init() >>
mp_vfs_blockdev_ioctl() >>
check_fs() start
storage_read_blocks(0, 1) >>
storage_read_block(0): FAKE MBR!
build_partition(0, 1, 256, 4096) >>
build_partition(0, 0, 0, 0) >>
build_partition(0, 0, 0, 0) >>
build_partition(0, 0, 0, 0) >>
check_fs(sig = aa55)
check_fs() end
check_fs() start
storage_read_blocks(256, 1) >>
storage_read_blocks(): PART1 read
spi_rb(0, 1) >>
mp_spiflash_cached_read() >>
<< mp_spiflash_cached_read()
spi_rb():0
check_fs(sig = cccc)
MPY: can't mount flash
MicroPython v1.24.0-preview.308.g3ca01ecca.dirty on 2024-09-12; PYBD-SF2W with STM32F722IEK
Type "help()" for more information.

`

[RichardB-RT]

This file system problem was actually caused by 2 problems:

1. micropython code tries to write 2 QSPI status registers at once while the newer QSPI chip does not support this. The problem was solved by writing the status registers one at the time.
2. supply 5V instead of 3V3