MFS files not writing to memory.

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

MFS files not writing to memory.

Jump to solution
3,146 Views
ironsean
Contributor V

MFS is still NOT doing anything after formatting, and I can not figure out why.

---

I am having trouble reading and writing any files onto internal flash with MFS. I can write and read with FlashX, I can detect that an MFS install is not formatted, and then format it, but I can not write and/or read a file after doing so. I'm not sure which part breaks down, but I've attempted to manually read the first 500 memory locations on the flash using FlashX and can't see anything other than a basic MFS string likely related to the formatting process.

My (stripped down to remove excess comments and error checking which passes) code is, including some commented toggles I've enabled and disabled while testing:

Code

    #define         FLASH_NAME "flashx:storage" //custom bank from 0x0006000 to 0x0007FFFF

  #define BUFFER_SIZE (80)

  static char_ptr buffer, buffer2;

  MQX_FILE_PTR   flash_file, pm_file, mfs_file, working_file;

  uint_32 error, len;

  buffer = (char_ptr)_mem_alloc_zero(BUFFER_SIZE);

  buffer2= (char_ptr)_mem_alloc_zero(BUFFER_SIZE);

  buffer = "\nThis is a test string";

  _int_install_unexpected_isr();

  /* Open the flash device */

  flash_file = fopen(FLASH_NAME, NULL);

  /* Get the size of the flash file */

  fseek(flash_file, 0, IO_SEEK_SET);

  printf("\nSize of the flash file: 0x%x Bytes", ftell(flash_file)); //Doesn't actually work for some reason, but also broken with flashx:bank1

  /* Disable sector cache */

  //ioctl(flash_file, FLASH_IOCTL_ENABLE_SECTOR_CACHE, NULL);

//Determine base memory address

// uint_32 memlocation = 0;

// ioctl(flash_file, FLASH_IOCTL_GET_SECTOR_BASE, &memlocation);

// printf("\nThe base memory location is 0x%08x", memlocation); //confirms starts at 0x60000

  /* Unprotecting the the FLASH might be required */

  //uint_32 ioctl_param = 0;

  //ioctl(flash_file, FLASH_IOCTL_WRITE_PROTECT, &ioctl_param);

  /*

  * Attempt to install MFS Partition manager.

  */

  fseek(flash_file, 0, IO_SEEK_SET);

  error = _io_part_mgr_install(flash_file, "PM:", 0);

  pm_file = fopen("PM:", 0);

  /*

  * Attempt to install MFS

  */

  error = _io_mfs_install(pm_file, "MFS:", 0);

  /*

  * Open MFS

  */

  mfs_file = fopen("MFS:", NULL);

  error = ferror(mfs_file);

  printf("\nOpening the file system. The error recieved is %d", error);

  if ((error != MFS_NO_ERROR) && (error != MFS_NOT_A_DOS_DISK))

          _task_block();

  // Check for format

  if (error == MFS_NOT_A_DOS_DISK)

  {

  printf("\nMFS not formatted, formatting to continue.");

         ioctl(mfs_file, IO_IOCTL_DEFAULT_FORMAT, NULL);

  }

  else

  printf("\nMFS is formatted.");

  fclose(mfs_file);

     

  //ioctl( mfs_file, IO_IOCTL_FAT_CACHE_OFF, NULL);    // without CACHE

  /*

  * Test the MFS

  */

  buffer = "Testing the MFS filesystem write";

  working_file = fopen("MFS:myfile.txt", "n");

  if (working_file == NULL ) printf("Error creating file.");

  //write(working_file, buffer, strlen(buffer));

  fprintf(working_file, buffer);

  /* Close the file: */

  //ioctl( working_file, IO_IOCTL_FLUSH_FAT, NULL);

  //fflush(working_file);

  error = fclose(working_file);

  printf("\nThe contents bring written to file are: %s\n and the error code of closing is: %d", buffer, error);

  working_file = fopen("MFS:myfile.txt", "r");

  read(working_file, buffer2, strlen(buffer));

  /* Close the file: */

  error = fclose(working_file);

  printf("\nThe contents of the written file are: %s\n and the error code of closing is: %d", buffer2, error);

  return 0;

No errors are thrown from any of the function calls to error (aside from a NOT_A_DOS_DISK when the flashX is not formatted. Also no task errors are thrown.

Labels (1)
0 Kudos
Reply
1 Solution
2,416 Views
ironsean
Contributor V

This was solved by, as mentioned above, bypassing the partition manager and installing MFS with default settings directly to the flashX device. Then setting both the file and FAT cache modes to Write-through (0, no cache) allowed files and FAT changes to be written instantly instead of waiting for a manual call later.

View solution in original post

0 Kudos
Reply
6 Replies
2,416 Views
ironsean
Contributor V

By bypassing the Partition Manager stage, and just using MFS directly on the FlashX, I found one problem: There seems to be some caching occurring, and by properly closing the MFS and FlashX devices it writes the contents of the file to flash. However, after rebooting the device and changing the code to read mode it can not read the file by name anymore.

0 Kudos
Reply
2,417 Views
ironsean
Contributor V

This was solved by, as mentioned above, bypassing the partition manager and installing MFS with default settings directly to the flashX device. Then setting both the file and FAT cache modes to Write-through (0, no cache) allowed files and FAT changes to be written instantly instead of waiting for a manual call later.

0 Kudos
Reply
2,416 Views
ironsean
Contributor V

Reworking my memory traversing code, I've pulled a detailed dump of Flash content which shows that the Files are NOT being written to flash with MFS. I can paste the detailed dump, but the general format is as follows:

flashx:storage is defined as 0x00060000 to 0x0007FFFF

// MFS format information:

Location: 0x00060000 contains: ë<MFS30000

Location: 0x0006000c contains:

Location: 0x00060010 contains: p

Location: 0x00060014 contains: ø

Location: 0x00060024 contains:

Location: 0x00060026 contains: )

Location: 0x0006002b contains: NO NAME FAT12 3Àм

Location: 0x00060044 contains: |üè-

Location: 0x00060049 contains:

Non-System disk

Press any key to reboot

Location: 0x00060076 contains: ^ëÍ´»

Location: 0x00060080 contains: .¬

  ÀuóÍÍë±

Location: 0x000601fe contains: Uªøÿÿ

0x00060200 to  0x00061200: ALL NULL CHARACTERS, appears to be formatted and cleared.

0x00061200 to 0x0007f800: ALL the invalid character 'ÿ'. Appears it may not have been formatted?

//FNET paramaters, from a previous install of an FNET bootloader, not a part of this build and should not be still here, should be allocated and formatted to Partition Manager and MFS.

Location: 0x0007f800 contains: FNET02

Location: 0x0007f80c contains: ˬ

Location: 0x0007f80f contains: ÿÿÿ

Location: 0x0007f814 contains: ˬ

Location: 0x0007f817 contains: þ

Location: 0x0007f828 contains:

Location: 0x0007f830 contains: dhcp; erase all; tftp; set boot go; save; go

Location: 0x0007f86c contains:

Location: 0x0007f870 contains:

nx

Location: 0x0007f87c contains: intflash.afx.s19

Location: 0x0007f8a4 contains: ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ

Location: 0x0007f8f4 contains: ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ

...

// TESTMAN was a sample value written to the end of flashx:bank1 after importing the flashx example project.

Location: 0x0007ffe8 contains: ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿTESTMAN

0 Kudos
Reply
2,416 Views
Luis_Garabo
NXP TechSupport
NXP TechSupport

Hi Sean,

Installing FAT onto internal flash is not good except in cases where "write" access is occurring very rarely. FAT is quite sector intensive - you are going to burn the flash after few hundreds of writes and your application will no longer work. That is why it is not recommended.

I strongly recommend having another memory doing this storage behavior, like a SD card or USB memory key instead of the flash memory.


Regards,
Garabo

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

0 Kudos
Reply
2,416 Views
ironsean
Contributor V

Thank you for the warning. I am well aware of the write intensive nature of FAT filesystems, but for my use case write access will be relatively infrequent, and this is only for a testing prototype. A later board design will have external memory and appropriate wear-levelling in place. But for now, we are trying to get the MFS working to move forward with other aspects of the project which require a way to write and read information, and build up implementation code which can be brought to other memory forms as we iterate on the hardware.

0 Kudos
Reply
2,416 Views
ironsean
Contributor V

However, if you want to recommend any other methods of getting filesystems up and running short of creating our own custom scheme for hard saving data in flash locations which seems like a lot of work which will not be portable elsewhere. Ideally we'd like to have data in files already so things like exporting csv files via web interface or transferring to SD cards can be possible.

0 Kudos
Reply