RTOS/AM5726: Unexpected file created on the MMCSD

Hi,

Please elaborate what you mean unexpected file? What TI EVM used for this test? For creating files, do you used any test example like the MMCSD_FatfsConsole_EVM_DMA_exampleProject? Do you use shell command like "cat <INPUTFILE> > <OUTPUTFILE> " to create a file?

Regards, Eric

Hi Eric,
Thanks for your reply.

> What TI EVM used for this test?
-On the customer board.

>Please elaborate what you mean unexpected file?
-This unexpected file type is "8.3 type file". it created many same name file and this file name contain "~" .
And it create "0" size file also. When it check SD card on the PC, it encounter some error too.

> For creating files, do you used any test example like the MMCSD_FatfsConsole_EVM_DMA_exampleProject?
Actually, they refer this sample code.

>Do you use shell command like "cat <INPUTFILE> > <OUTPUTFILE> " to create a file?
-No, they doesn't use it on shell command it create Fat file on the PGM.


One more additional information,
This phenomenon occur during "Read SD card".
When it add wait time at read mode, this phenomenon is fixed.

Also, when they changed source code as bellow, this phenomenon improved even if "another DMA load rate" is high.

Original source code : Wait until DMA complete, then wiat SD card Data transmitt
New method : After waiting SD data transmit, it wait DMA complete


<Original code>

pdk_am57xx_1_0_9/packages/ti/drv/mmcsd/src/v1/MMCSD_v1.c
line2355

/*
* Wait for the transfer to complete here.
* It's OK to block from here because the MMCSD's Hwi will unblock
* upon errors
*/
#ifdef MMCSD_EDMA_ENABLED
if(0U != hwAttrs->enableDma && transaction->cmd!=MMCSD_CMD(19U))
{
if (HS_MMCSD_XFER_TYPE_RX == cmdObj.cmd.xferType)
{
MMCSD_osalPendLock(object->readSem, SemaphoreP_WAIT_FOREVER);
}
else
{
MMCSD_osalPendLock(object->writeSem, SemaphoreP_WAIT_FOREVER);
}
}
#endif
if(0U != hwAttrs->enableInterrupt)
{
MMCSD_osalPendLock(object->transferComplete, SemaphoreP_WAIT_FOREVER);
}

<New>
pdk_am57xx_1_0_9/packages/ti/drv/mmcsd/src/v1/MMCSD_v1.c
line2355

/*
* Wait for the transfer to complete here.
* It's OK to block from here because the MMCSD's Hwi will unblock
* upon errors
*/
#ifdef MMCSD_EDMA_ENABLED
MMCSD_osalPendLock(object->transferComplete, SemaphoreP_WAIT_FOREVER); **Move to before DMA complete

if(0U != hwAttrs->enableDma && transaction->cmd!=MMCSD_CMD(19U))
{
if (HS_MMCSD_XFER_TYPE_RX == cmdObj.cmd.xferType)
{
MMCSD_osalPendLock(object->readSem, SemaphoreP_WAIT_FOREVER);
}
else
{
MMCSD_osalPendLock(object->writeSem, SemaphoreP_WAIT_FOREVER);
}
}
#endif


Do you expect any root cause ?

Hi,

it create Fat file on the PGM. >>>>>>> Can you explain what they do to create file?

This phenomenon occur during "Read SD card". =========> how do they simulate the read mode? I knew if you do "cat <INPUTFILE> > <OUTPUTFILE> ", it will read the input, then write to output. This is how we test and we didn't see additional files created.

Regards, Eric

Hi,

>it create Fat file on the PGM. >>>>>>> Can you explain what they do to create file?

-I think customer make File open command as standard FAT command (i.e, f_open) on the program.

Regards,

Kz777

Hi,

Thanks! Our shell application also used the f_open to create a file on FATFS and we also called f_read and f_write API but didn't see the issue. Do you have details how the issue can be reproduced so I can try?

Regards, Eric

I am checking customer. Please wait a while.

I am checking it to customer now. Please wait a while.

Hi Eric,

Sorry for my late response. I checked this detail set up condition.

They didn't re-produce it on the EVM We checked how to re-produce on the EVM. 

1) : Create "folder_A"

2): Create "folder_B" inside of folder_A

3)  :Repeat "folder_C"_xxx and "file_xxxx  inside of folder_B

4): after write data to the file, system run "read" and " verify"

after following 1)-4) step, system is like this.

       folder_A --- folder_B -+- folder_C_00000 --- file_00000  (open, write, read verify)

                           +- folder_C_00001 --- file_00001  (open, write, read verify)

                           +- folder_C_00002 --- file_00002  (open, write, read verify)

                           +- folder_C_00003 --- file_00003  (open, write, read verify)

                           +- folder_C_00004 --- file_00004  (open, write, read verify)

                                ・

                                ・

                                ・

 In this case, these file name is unexpect name and create "zero" size data file

This phenomenon is easy to occur when we create 10 times folder. 

During file  access, system is working another DMA too. 

Here is DMA channel configuration (TI source code didn't change MMCSD side)

          EDMA3_CHA_ OTHER          1   (use another DMA)

        CSL_EDMA3_CHA_MMC1_TX    60   (MMCSD TX)

        CSL_EDMA3_CHA_MMC1_RX    61   (MMCSD RX)

 When we stop EDMA_CHA_OTHER, this phenomenon have never happened.

Acutally, our customer create own program for above step. 

Could you please try above test on the EVM (Try it shell command base )?

Regards,

Kz777

Hi,

I don't understand steps:
3) :Repeat "folder_C"_xxx and "file_xxxx inside of folder_B

4): after write data to the file, system run "read" and " verify"

after following 1)-4) step, system is like this.

My test is based on MMCSD_FatfsConsole_idkAM572x_DMA_armExampleProject. From the UART console,
1) I did a "mkdir folder_a"
2) cd folder_a
3) mkdir folder_b
4) cd folder_b
5) mkdir folder_c
6) cat 0:/file_1 > file_00000 (here file_1 is a UART.docx on the MMCSD card)
7) cat file_00000 > file_00001

I don't have any unexpected file created.

0://folder_a/folder_b/folder_c>cd 0:/
All tests have PASSED
0:/>ls
D-HS- 2019/01/28 17:27 0 System Volume Information
----A 2019/01/21 14:24 106822 UART.docx
D---- 2007/06/05 11:38 0 folder_a

1 File(s), 106822 bytes total
2 Dir(s), 67267K bytes free
All tests have PASSED
0:/>cd folder_a
All tests have PASSED
0://folder_a>ls
D---- 2007/06/05 11:38 0 folder_b

0 File(s), 0 bytes total
1 Dir(s), 67267K bytes free
All tests have PASSED
0://folder_a>cd folder_b
All tests have PASSED
0://folder_a/folder_b>ls
D---- 2007/06/05 11:38 0 folder_c
----A 2007/06/05 11:38 106822 file_00000
----A 2007/06/05 11:38 106822 file_00001

2 File(s), 213644 bytes total
1 Dir(s), 67267K bytes free
All tests have PASSED
0://folder_a/folder_b>

Regards, Eric

Hi Eric,
Appreciate your test.

>I don't understand steps:
>3) :Repeat "folder_C"_xxx and "file_xxxx inside of folder_B
>4): after write data to the file, system run "read" and " verify"

- At folder_b layer, you can try folder C_0001 /file_0001. Then, you open this "file_0001". And write some data on "file_0001" and verify.
Then, you create folder C_0002 /file_0002 and repeat ten times.
until folder C_0010 /file_00010. According to customer, when we repeat around 10 times for this operation, we can re-produce it.
And Please also set to enable "EDMA3_CHA_ OTHER 1 (use another DMA)"



folder_A --- folder_B -+- folder_C_00000 --- file_00000 (open, write, read verify)

+- folder_C_00001 --- file_00001 (open, write, read verify)

+- folder_C_00002 --- file_00002 (open, write, read verify)

+- folder_C_00003 --- file_00003 (open, write, read verify)

+- folder_C_00004 --- file_00004 (open, write, read verify)

Do you make sense what I mean ?

Regards,
Kz777

Hi,

Sorry, I tried and I still can't reproduce the issue. Maybe you have some automated way to generate file but I used the shell command and timing is different.

As you mentioned some code change can affect this behavior, I will discuss with the dev team.

Regards, Eric

HI Thanks. Customer is now trying to re-produce it on the EVM. When they done, I will let you know.

Hi,

Do you have info from customer?

Regards, Eric

Hi Eric,


Sorry , we are still waiting their information.

I understand to close this thread. Whenever I got additional information, I will launch another thread.