MQX 4.2.0.2 with MFS and USBv2 data not flushing on fclose

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

MQX 4.2.0.2 with MFS and USBv2 data not flushing on fclose

Jump to solution
2,540 Views
twong
Contributor II

Hello,

Has anybody else had problems where the data does not flush to the USB stick on fclose?

I am having problems where the data I am writing to the USB stick is not persistent even after I do fflush and fclose on the file unless I close the filesystem (usb_filesystem_uninstall).

It's similar to this FFS fsclose required?  except with USB and now on MQX 4.2. I have tried this with SD card and the SD card data has been persistent.

My development environment consists of IAR with a Vybrid VF65GS10 based system with MQX 4.2.0.2 mfs (not mfsv1) usbv2(not usb).

For example, what I have seen is that:

1) fopen, fwrite("abc"), fclose

2) "abc" will be on the file in the USB stick

3) fopen, fwrite("def"), fclose

4) only "abc" will be on the file in the USB stick

5) fopen, fwrite("ghi"), fclose

6) only "abcdef" will be on the file in the USB stick

...

So, other than the first fwrite, the last fwrite to the USB stick will not be flushed into the USB stick until I close the filesystem.

I have tried doing the following and the data is not persistent after fclose:

1) fflush file

fopen, fwrite, fflush, fclose

2) fflush device before fclose

fopen

fwrite

_io_get_fs_by_name(...); //get filesystem_pointer

fflush(filesystem_pointer) //MFS_Flush_Device function tries to flush the whole device

fclose

3) fflush device after fclose

fopen

fwrite

fclose

_io_get_fs_by_name(...); //get filesystem_pointer

fflush(filesystem_pointer) //MFS_Flush_Device function tries to flush the whole device

4) set mfs to MFS_WRITE_THROUGH_CACHE

usb_filesystem_install(...);

_io_get_fs_by_name(...); //get filesystem_pointer

ioctl(filesystem_pointer, IO_IOCTL_WRITE_CACHE_OFF, NULL);

As well, I ran the msd_fatfs example in the usbv2 directory (\Freescale\Freescale_MQX_4_2\usb_v2\example\host\msd\msd_fatfs) with the same results using the following steps:

1) Change #define  HIGH_SPEED (1) to get it working for Vybrid.

2) Change USBCFG_HOST_BUFF_PROPERTY_CACHEABLE in usb_host_config.h to 1 when running from ddr or to 0 when running from sram

3a) Debug example

3b) Insert USB stick

3c) In shell, write tmp 5

3d) In shell, write tmp 5 end 0

3e) Remove USB stick

4) Can only see 01234, Expect to see 0123401234

Is there something I can look at doing so the data will be persistent after an fclose to a USB file without having to close and reopen the filesystem each time?

Labels (2)
1 Solution
1,892 Views
danielchen
NXP TechSupport
NXP TechSupport

We have a ioctl command "IO_IOCTL_FLUSH_OUTPUT" to do this, unfortunately, this command not work with usb stack now. This issue is only related with FAT32.  I agree with Johannes, call the ioctl for ALLOW MEDIA REMOVAL when needed.

Regards

Daniel

View solution in original post

6 Replies
1,892 Views
twong
Contributor II

Thanks Daniel,

If you would like more information from my end, please let me know.

Regards,

Thomas

0 Kudos
Reply
1,892 Views
johannesschock
Contributor II

Hello Thomas, hello Daniel,

there are USB-Sticks available that don't always flush their internal Flashmanager.

I learned that you can force these Sticks to flush by issuing the PREVENT-ALLOW MEDIUM REMOVAL command with prevent set to 0.

I implemented this command in an IOCTL and call it when needed. This solves the above mentioned problem in many cases.

Attention: There are however Sticks in the wild that have problems with calling PREVENT-ALLOW MEDIUM REMOVAL command with prevent set to 1. So only use it with 0 after fclose and/or fflush.

1,892 Views
twong
Contributor II

Hello Johannes,

Thank you for the information. I tried your suggestion and it looks like the data will flush after the ALLOW MEDIUM REMOVAL command is sent. If you don't mind, can you tell me whether you are running a vybrid system? The reason I ask is because I don't remember having this problem on a K64 system but I will need to try it specifically to confirm. In the meantime, I am going to try more types of usb sticks to see if the data will still flush.

Hello Daniel,

I would be interested to know if in your investigation this is a recommended solution or does the root cause lie elsewhere?

In the example code, I called the ioctl I created for ALLOW MEDIUM REMOVAL after the final fclose and the data flushes to the USB. It looks like ALLOW MEDIUM REMOVAL must be called after the fclose and not prior.

With my main project, I modified _io_usb_mfs_write in usbmfs.c to call the the ALLOW MEDIUM REMOVAL function at the end of the function and that looks like it works as well. This way, I should be able to avoid having to call the ioctl at the end of every usb fclose.

Thanks,

Thomas

0 Kudos
Reply
1,892 Views
johannesschock
Contributor II

Hello Thomas,

I don't run Vybrid, but K61,K64 and K70 and all three processors have the same behaviour. (With all versions of usb stack: EHCI old, KHCI old, and KHCI v2.)

But not every USB-Stick shows this behaviour. Some Sticks flush more often by themselves.

I don't like to issue the command in the _io_usb_mfs_write because I fear that this can wear out the USB Stick because it flushes too often. But in applications where the USB-Stick isn't used regularly this could be a convenient solution.

I keep using my PREVENT-ALLOW MEDIUM REMOVAL after fclose.

1,893 Views
danielchen
NXP TechSupport
NXP TechSupport

We have a ioctl command "IO_IOCTL_FLUSH_OUTPUT" to do this, unfortunately, this command not work with usb stack now. This issue is only related with FAT32.  I agree with Johannes, call the ioctl for ALLOW MEDIA REMOVAL when needed.

Regards

Daniel

1,892 Views
danielchen
NXP TechSupport
NXP TechSupport

Hi Thomas:

I did a quick test with msd_fatfs demo according to your steps. Yes, sometimes I can got the same results as your said. Let me do some investigation and update to you when I have results

Regards

Daniel