Open ThomasGmeinder opened 5 years ago
You will need to have written a FAT filesystem to the data partition of the flash first. There is a simple host utility included which can be used to create filesystem images and write files to it, see https://github.com/xmos/lib_filesystem/blob/master/lib_filesystem/disk_image_creators/fat/src/make_fat.c.
IIRC the filesystem image expected by the tests can be built using these files: https://github.com/xmos/lib_filesystem/tree/master/tests/test_fat_image_creator.
Did you have any luck with the image creator @ThomasGmeinder?
I created a disk image using ./fat_image_creator fat_image ../../../tests/test_fat_image_creator/hello.txt
But now I don't know how to write the resulting fat_image binary into the flash. Please documentation that shows the required command to write this into flash and make test_file_system_basic.xe work.
Also, can I use binary files as input to fat_image_creator or does the data have to be provided as test files.
To write the fat image to flash (assuming a 2MB flash, where half is to be used for boot images):
xflash <your_xe_file> --boot-partition-size 1003520 --data <your_fat_image>
Writing binary files to the fat image should work fine, it's not restricted to text files.
Also worth noting that when creating a disk image that multiple file paths can be passed to the fat_image_creator, should you need more than one file in your filesystem.
I tried this on the xCORE-200 eXplorer.
Create file system in lib_filesystem/disk_image_creators/fat
./fat_image_creator fat_image_46 ../../../tests/test_fat_image_creator/46.txt
xflash bin/test_filesystem_basic.xe --boot-partition-size 1003520 --data ../../lib_filesystem/disk_image_creators/fat/fat_image_46
xrun --xscope bin/test_filesystem_basic.xe
Mounting filesystem...
result = 2
Mounting the file system is still failing.
Hmm that's strange. If you run xflash --read-all
do you see your disk image correctly read off the flash? I wonder if you're using a later version of the XMOS tools from when this test was developed?
I tried tools 14.3.3 and 14.4. on xCORE-200 explorer no avail.
Examining the output of xflash --read-all
shows that at least the beginning of the disk image data is contained in the flash. See below.
I guess I have to dig into why this call fails: result = i_fs.mount();
Disk image: The Project Gutenberg EBook of A Christmas Carol, by Charles Dickens
This eBook is for the use of anyone anywhere at no cost and with almost no restrictions whatsoever.
Corresponding ASCII code read from flash: 5468 6520 5072 6f6a 6563 7420 4775 7465 6e62 6572 6720 4542 6f6f 6b20 6f66 2041 2043 6872 6973 746d 6173 2043 6172 6f6c 2c20 6279 2043 6861 726c 6573 2044 6963 6b65 6e73 0d0a 0d0a 5468 6973 2065 426f 6f6b 2069 7320 666f 7220 7468 6520 7573 6520 6f66 2061 6e79 6f6e 6520 616e 7977 6865 7265 2061 7420 6e6f 2063 6f73 7420 616e 6420 7769 7468 0d0a 616c 6d6f 7374 206e 6f20 7265 7374 7269 6374 696f 6e73 2077 6861 7473 6f65 7665 722e 20
Note: before the above data the flash contains all 0. So I presume that the beginning of the text in the disk image aligns with the beginning of the data partition.
I think Tools 14.2.1 would have been the latest at the time this test was written (I've just been looking at the git history of various repos), though I'm not suggesting this is the issue - just providing this FYI.
I'd expect that the FAT table etc. would come before the start of the first file in the data partition. It might look something like:
EBFE904D 53444F53 352E3000 02010100
01000274 0DF05F00 3F00FF00 00000000
00000000 80002900 0021464E 4F204E41
4D452020 20204641 54202020 20200000
ëþMSDOS5.0
t ð_ ? ÿ
) !FNO NA
ME FAT
I think you're right that looking into how far the call to i_fs.mount()
is getting seems like the correct next step, assuming that the start of the FAT image has been written to the data portion of your flash.
i_fs.mount() fails here:
at qspi_flash.xc:19
19 if (fl_connectToDevice(qspi_flash_ports, &qspi_spec, 1)) {
I see the start of the FAT image in line 62721 in the output file of xflash --read-all
:
ebfe 904d 5344 4f53 352e 3000 0201 0100
Data starts a lot later on line 66817 which seems strange.
XCORE-200-EXPLORER uses a 1 MBit flash so I changed xflash command to use --boot-partition-size 524288 (making half of the flash data partition).
fl_connectToDevice
still failed.
But when I use fl_connect
instead of fl_connectToDevice
then it works.
Somehow it doesn't like the qspi_spec FL_QUADDEVICE_SPANSION_S25FL116K
Using fl_connect seems like a better idea anyway as this will support more flashes and therefore more boards.
But then it fails in the next access:
Opening file...
Error 3. Exiting...
That failed because test_filesystem_basic assumes filename char filename[] = "HELLO.TXT";
but I used 46.txt to create the filesystem
After creating a filesystem with hello.txt
./fat_image_creator fat_image_hello ../../../tests/test_fat_image_creator/hello.txt
and using that the test_filesystem_basic app seems to work: Mounting filesystem...
Opening file...
Getting file size...
Reading part of file...
Attempted to read 5 byte(s) of 14 byte file.
Read 5 byte(s) of file:
Hello
Seeking back to beginning of file...
Reading whole file...
Attempted to read all of 14 byte file.
Read 14 byte(s) of file:
Hello, World!
I've just looked up which flash the xCORE-200 explorer uses (as the Spansion S25FL116K is 2MB), and it appears to be the IS25LQ080B-JNL.
So, the problem is that the fl_QuadDeviceSpec
set in test_filesystem_basic/src/main.xc and the TARGET
set in test_filesystem_basic/Makefile and test_filesystem_basic/wscript are out of sync.
I suspect that if you update the SPI spec used in main.xc to suit the ISSI part the call to fl_connectToDevice
would work correctly.
Using fl_connectToDevice
rather than fl_connect
should result in smaller binaries, as just the required SPI spec will be included rather than the whole set supported by the tools.
I build and run test_filesystem_basic.xe with tools 14.3.3 The console prints Mounting filesystem... result = 2
2 means FS_RES_NOT_READY
I guess I have to prepare the flash somehow with xflash but can find no documentation for that.