Multiple nandflash access

[arnogir]

Hello

I'm using MQX 4.1 on K70 with an external Nandflash linked to the NFC.

I installed the MFS then the nandflash is seen like a disk on letter "a:"

Then I read/write some files on this until:

MyFileHandler = fopen("a:\\Myfile.xxx", r+), read(), write, fclose(MyFileHandler ).

I have some questions about this, because sometime during the life of the product, some files are corrupted with bad value. So I try to found possible source of this problem.

1- My code is protected against multiple access on the same file. If a task access to a file, before open file, I call:

_lswem(MyFileSemaphore)

Then after close file I call _lswem_post(MyFileSemaphore).

But I'm not protected against other file access.

Is a task can access to a file (read/write), be interrupted by higher priority task in which an access to an other file is done?

I don't know how the MFS manage this, but in exemple, on other project, I managed an external SPI flash. This is some simple access to a read/write instructions. To write, I send the command write, then the address and then all the bytes to be written from the given address. If I interrupted during transmission of the Data bytes, an other task can access to the flash, start a new dial by give another address and write data byte. So when I back into the original task, the write continue but not on the desired address! Then I protect against multiple access. Is similar with the Nandflash on the NFC with MQX and MFS?

2-  For a big file, I must call fflush on the system nandflash after fclose(MyFileHandler ). But I think I must also (or only?) call a flush on the file before close it : fflush(MyFileHandler ). What is your opinion?

3 - Is there need some delay after Open / Read / Write /(Flush) / Close operation? and/or Flush Nandflash ?

4- What happen if Power become off during a open/ Read/Write / flush/close? Is file could be corrupted or the integrity is keeped?

5- By looking for in this forum, I find the following method. This could be fine in my case? This could say the call to fflush is not necessary?

ioctl ( fat_handle, IO_IOCTL_DEFAULT_FORMAT, NULL );
cache_mode = MFS_WRITE_THROUGH_CACHE;
_io_ioctl ( fat_handle, IO_IOCTL_SET_FAT_CACHE_MODE, &cache_mode );
_io_ioctl ( fat_handle, IO_IOCTL_SET_WRITE_CACHE_MODE, &cache_mode );
_io_ioctl ( fat_handle, IO_IOCTL_FAT_CACHE_OFF, NULL );

Thank for your back, this is very critical for our project.

[arnogir]

Hello,

It seems there are some big modification into the MFS between the 4.1.1 and the 4.2.

But it is not a very quick solution for us to migrate all MQX from 4.1 to 4.2 on a project done many years ago and in which all time is already spent!.

It seems also difficult to integrate only the MFS 4.2 into the 4.1 due too many changes.

But I seen a strange thing:

In bsp_nandflash_io_init, there are:

SIM_SPOT_REG(SIM_BASE_PTR) |= SIM_SOPT2_NFCSRC(0x00) => To use BusClk.

But the default value of NFCSRC is 0x01.. THen the OR (0x00) has no effect and stay on the PLL0!

But the PLL0 was not activated (MCG_C5 = 0x04)!!! How this can work?

After that, during developpement, I modified the Div by 8 to Div By 5 to increase clock.

It is difficult to me to know if the Nandflash clock is to high or not accordinf its datasheet. THere are not CLock signal. And I don't know how is use the source clock to generate Nandflash signal.

Then, with a BusClock to 150MHz, what is the minimum div to apply to not be to fats for the flash?

SIM_CLKDIV4 &= 0x00FFFFFF; /* clear 8 most significant bits */
SIM_CLKDIV4 |= SIM_CLKDIV4_NFCDIV(4);

[danielchen]

Hi Arnaud:

Yes, the MFS modification in MQX 4.2 is big.  But the API interface is the same.  I think you can try to port mfs from MQX 4.2 to 4.1.

For PLL0, you can check the MCG_S.  MCG_S->lock0 = 1,  PLL0 is  enabled

Regards

Daniel

[arnogir]

I try to integrate MFS 4.2 into 4.1 but at compile time, the structure IO_DRVIF_STRUCT is unknown.

This structure is defined in psp/io.h with also other change:

IO_DEVICE_STRUCT has a field in more (IO_LSEEK_FPTR..)

Is I can only add IO_DRVIF_STRUCT??

[danielchen]

Yes, I think you can add IO_DRVIF_STRUCT.

Regards

Daniel

[arnogir]

I directly migrate from MQX 4.1 to 4.2 because I think this is too hasardous to integrate only MFS.

[danielchen]

Please also remember there is a patch 4.2.0.2. it also fixed one important MFS issue.

Regards

Daniel

[arnogir]

Yes I taken it.

Thank

[arnogir]

Hi,

PLL is locked, so on Figure 5-1 of datasheet, this is not explicit where is the effect of the PLLCLKEN0 set to 1 or 0.. ?

On figure 25-1 we could imagine the PLLCLKEN0 not enable the entiere PLL0! Then I not understand how LOCK0 could be set while PLLCLKEN0 is 0! ?

[Hui_Ma]

Hi,

Yes, you are right. From K70 reference manual, if enable PLL0, the MCG_C5[PLLCLKEN0] bit should be set.

While, I did some test, whatever MCG_C5[PLLCLKEN0] bit status, the PLL0 still works as MCG output, when MCG works in PEE mode.

I think there with some design issue at K70 MCG module.

best regards,

Mike

[arnogir]

I remember me read some time ago into the datasheet, the PLL0 was enable if PLLCLKEN0 was set OR an other condition which not remember. (Something like if PLL0 selected for some thing…)

But I think there are an issue in the nandflash io init which made Register |= NFCSRC(0) to set the clock source. But this has no effect because already set by default to 1.

MQX should first make MASK on the bit and then make the OR to set the source...

[danielchen]

Yes, it is a good coding style to first MASK on the bit and then OR the bit. thank you for your feedback. I will report this issue to soft team.

Regards

Daniel

[arnogir]

Hi.

Any body has an Idea ?

[danielchen]

HiArnaud:

I would suggest you try to use MQX 4.2.   It fixed one issue about the concurrent readers and writers of the same file

Please refer to MQX 4.2 release note for MFS bug fix:

• MFS FAT file system - version 4.2.0 (same as in KSDK 1.2.0)
• Support for multiple concurrent readers/writers of the same file
• Support of mutex in addition of lwsem - solution to priority inversion
• Locking mechanism reviewed
• Read only checks - improved efficiency
• Better abstraction of FAT chain handling – better performance of random seek
• Scalable sector cache layer – dedicated directory and FAT sector buffers were removed
• True file append mode – seek to end of file atomically prior each write operation
• Directory search using FAT chain abstraction - improved efficiency
• Extension to find first/next API for direct long filename extraction - significant performance boost
• Path parsing redesigned to avoid unnecessary allocation of path buffers - lower RAM footprint
• Unicode support - UTF

Regards

Daniel