Bug: STM32CubeIDE code generation with FatFS/FreeRTOS is using a deprecated API

[jblai.1]

STM32CubeIDE Version: 1.1.0

Build: 4551_20191014-1140 (UTC)

Processor STM32F103C8

Options chosen in configurator: FreeRTOS using CMSIS_V2 and FatFS enabled.

In the generated file Middlewares/Third_Party/FatFS/src/option/syscalls.c the following deprecated CMSIS_V1 function calls are made which causes a linking failure:

osSemaphoreCreate()

osSemaphoreWait()

They need to be replaced with:

osSemaphoreNew()

osSemaphoreAcquire()

Additional note: if compiling the as generated code with FatFS and FreeRTOS included in the project it builds. It's only when adding some FatFS API function calls in the code that the linking fails as this is when the functions in syscalls.c are actually referred to in the call tree. (ST's test department fail!)

Update:

This is what the generated functions should be...

int ff_cre_syncobj ( /* TRUE:Function succeeded, FALSE:Could not create due to any error */

BYTE vol, /* Corresponding logical drive being processed */

_SYNC_t *sobj /* Pointer to return the created sync object */

)

{

 *sobj = osSemaphoreNew(1U, 1U, NULL);

 return (*sobj != NULL);

}

and...

int ff_req_grant ( /* TRUE:Got a grant to access the volume, FALSE:Could not get a grant */

_SYNC_t sobj /* Sync object to wait */

)

{

 int ret = 0;

 if (osSemaphoreAcquire(sobj, _FS_TIMEOUT) == osOK)

 {

  ret = 1;

 }

 return ret;

}

Some further observations:

1) In file fatfs.c these variables are being inserted by the code generator...

uint8_t retUSER;  /* Return value for USER */

char USERPath[4];  /* USER logical drive path */

FATFS USERFatFS;  /* File system object for USER logical drive */

FIL USERFile;    /* File object for USER */

This is not helpful. I want to decide where, when and how my file system variables are created and what they are called.

2) When setting up the parameters for FatFS the FS_RENTRANT is not adjustable. It's fixed at disabled if I'm not also using FreeRTOS and fixed as enabled if I am. This limits flexibility. I might be using FatFS with another RTOS and want re-entrancy on without FreeRTOS enabled, or I might be using FatFS and FreeRTOS but only accessing FatFS functions from one thread and not need re-entrancy.

3) With FatFS and without FreeRTOS the init function MX_FATFS_Init is called from main in generated code. With FreeRTOS it is generated to be called from the first task defined in the task list in the configurator. This is unhelpful as another thread may start first or I may not want it to be called in that thread. As the call only needs to be made once at startup I consider it better to leave it in the main function before threading has started.

In conclusion the generated code with the combination FatFS and FreeRTOS is not really usable.