RTOS/AM5718: MMCSD_close not called in FATFS

Marco Tinner52

Part Number: AM5718

Tool/software: TI-RTOS

Dear TI-Support

I had trouble using QSPI together with MMCSD in the bootloader on an idkAM571x development Board. The issue was that an assertion was thrown in the QSPI driver during a SPI_osalPendLock(object->mutex, SemaphoreP_WAIT_FOREVER); call in the QSPI_v1.c file. The assertion was thrown because the object-mutex was NULL. After some debugging i found out that the mutex could not be created because in the SemaphoreP_create() method all OSAL_NONOS_CONFIGNUM_SEMAPHORE where allready taken by other drivers (i2c, Uart and MMCSD). After increasing OSAL_NONOS_CONFIGNUM_SEMAPHORE everything worked.

After some more debugging i found out that the MMCSD_close() never get called. FATFS_close() is called but lacks the call to MMCSD_close() i think this is a bug in the pdk. I checked the sources for pdk version 1_0_10 and there is still no close call in the FATFS driver. Can you confirm this behavioral or is there any other method which has to be called during cleaning up of the FATFS System?

Thanks.

Kind regards

Marco

over 7 years ago

0 Biser Gatchev-XID over 7 years ago

TI__Guru**** 393215 points

The RTOS team have been notified. They will respond here.

0 lding over 7 years ago in reply to Biser Gatchev-XID

TI__Guru* 95265 points

Hi,

Thanks for the feedbacks! The individual drivers examples are expected to work standalone. We have some demo software-dl.ti.com/.../Examples_and_Demonstrations.html which exercise multiple driver examples, but they won't cover everything. When integrating multiple drivers together, there may be such kinds of conflicts which need debug and resolve, as you found out.

For the MMCSD, do you test from FATFS level or MMCSD level?
- If MMCSD level, such as the driver examples under mmcsd, see the code ti\drv\mmcsd\test\src\main.c, there is call to mmcsd_close at the end.

- if the FATFS level, the FATFS_open doesn't call the MMCSD_open. MMCSD_open is called inside FATFS function FATFS_diskInitialize() via a function table: if (FATFS_OK != ((FATFS_Config *) handle)->drvFxnTablePtr->openDrvFxn(object->drvInst, object->FATFSConfigParams.drvParams, &drvHandle))
So, similarly, the FATFS_close doesn't call the MMCSD_close as well.

We found some issue if you want to call open/close multiple times. We planned to fix this in the P-SDK RTOS 5.1 release, which will be available by end of this quarter.

Regards, Eric

0 Marco Tinner52 over 7 years ago in reply to lding

Prodigy 210 points

Dear Eric

Thanks for your reply.

I'm using it on the FATFS level:

FATFS_init();

FATFS_open();

FATFS_close();

I saw that the driver calls the MMCSD_open in FATFS_diskInitialize() but should there not somwhere be close call like:

((FATFS_Config *) handle)->drvFxnTablePtr->closeDrvFxn(object->drvInst, object->FATFSConfigParams.drvParams, &drvHandle))

Somthing like FATFS_diskDeInitialize()? otherwise the MMCSD will not be cleaned up correctly if the FATFS is not needed anymore.

In FATFS.h there is only FATFS_open, FATFS_Params_init, FATFS_init, FATFS_close. Where is the MMCSD cleaned up when i'm only using the FATFS level?

Greetings Marco

0 lding over 7 years ago in reply to Marco Tinner52

TI__Guru* 95265 points

Hi,

If you code sequence like:

while {
FATFS_init();

FATFS_open();

<Some code>

FATFS_close();
}

So you want MMCSD level clean up?

Regards, Eric

0 Marco Tinner52 over 7 years ago in reply to lding

Prodigy 210 points

Hi,

Yes during FATFS_open() MMCSD is opened as well and some semaphores are reserved. So i would expect a close function to clean up everything that i can use these resources again.

0 lding over 7 years ago in reply to Marco Tinner52

TI__Guru* 95265 points

Hi,

We have work in progress for this and plan to fix it in 5.1 release, which comes end of this quarter.

Regards, Eric

0 Marco Tinner52 over 7 years ago in reply to lding

Prodigy 210 points

Okey Thanks!

Processors

Processors forum

RTOS/AM5718: MMCSD_close not called in FATFS