_fx_version_id[] is not set because FX_SYSTEM_INIT is not defined

[MButsch]

Hello,

I am trying to implement a FileX SRAM disk (using STM32H723) and getting a error FX_NOT_IMPLEMENTED from _fx_media_open().

Tracing into the code, I find that the variable _fx_version_id[] is not set because FX_SYSTEM_INIT is not defined in fx_port.h. Searching the code, I see FX_SYSTEM_INIT defined in file fx_system_initialize.c, but that is local to that file.

How/where should FX_SYSTEM_INIT be #defined so that _fx_version_id[] gets set correctly?

Thank you,

Mark

[Haithem Rahmani]

Hi @MButsch​ 

Doesn't the "fx_stm32_sram_driver" provided with the X-CUB-AZRTOS-H7 fit your needs?

there is, BTW, a sample project using that driver in "BareMetal Mode" w/o ThreadX.

for your issue, you should call the "fx_system_initialize()" before calling any other FileX API.

regards

Haithem.

[MButsch]

Hello @Haithem Rahmani​ ,

Yes, I am using the "fx_stm32_sram_driver". I have it working now by disabling the check to see if _fx_version_id[] has been initialized.

I still don't know How/where FX_SYSTEM_INIT should be #defined so that _fx_version_id[] gets set correctly,

Thanks,

Mark

[Haithem Rahmani]

you should call the "fx_system_initialize()" in your application.

[MButsch]

 "fx_system_initialize()" is being called.

I think I found the issue with _fx_version_id[] looking like it hasn't been set.

It does get set (eclipse ifdef "highlighting" was confusing me), it just gets overwritten in fx_stm32_sram_driver() when the driver is initialized with this line of code:

        _fx_utility_memory_set((UCHAR *)FX_SRAM_DISK_BASE_ADDRESS, '\0', FX_SRAM_DISK_SIZE);

This references a specific memory address which appears to be used by the compiler for variables as well.

How/where should the SRAM disk memory be allocated so that the compiler "knows" about it?

Thanks,

Mark

[tec683]

I also encountered this error and can elaborate. It makes me question ST's regression testing and quality control as this is happening with generated code using default options.

When using FileX with an SRAM disk, the SRAM disk defaults to being located at D1_AXISRAM_BASE as set in STM32CubeMX in the Middleware FileX options.  Unfortunately, the default linker file, for a Nucleo H723 board at least, allocates variables starting at this address as well.  It's a wonder things didn't crash harder as 8192 bytes are getting set to 0.

Hard coding the buffer address like this seems like a horrible idea.  It is for an example, why not just use a statically allocated buffer?

I set the 'SRAM Disk Address' to D2_AHBSRAM_BASE which is a memory space not used in my sample application. Keep in mind that the many of the DMA controllers need to use this memory space. I'm just using the RAM disk to start my learning curve on FileX.

[tec683]

Here is a safer solution that does not rely on a hard coded SRAM disk buffer address.

In fx_stm32_sram_driver.h, add the code after /* USER CODE BEGIN EC */

/* Exported constants --------------------------------------------------------*/
#define FX_SRAM_DISK_BASE_ADDRESS         D2_AHBSRAM_BASE
#define FX_SRAM_DISK_SIZE                 (2*8192)

/* USER CODE BEGIN EC */
#undef FX_SRAM_DISK_BASE_ADDRESS
extern UCHAR fx_stm32_sram_disk_buffer[FX_SRAM_DISK_SIZE];
#define FX_SRAM_DISK_BASE_ADDRESS (&fx_stm32_sram_disk_buffer)

/* USER CODE END EC */

In a convenient file such as app_filex.c, allocate the buffer.

/* USER CODE BEGIN PV */
UCHAR fx_stm32_sram_disk_buffer[FX_SRAM_DISK_SIZE];

/* USER CODE END PV */

[tec683]

The adventure continues. I have become wise to the dysfunctional ways STM32CubeMX examples and code generation. The LevelX NOR Simulator Driver also uses a hard coded address that is the same as the default FileX SRAM disk sample driver.  Using the standard options, they will not coexist peacefully with each other or the example application.

I admit this is somewhat artificial as in practice you probably will not have both instantiated. I'm doing this mainly to see how the generated code deals with 2 different media types.

Since I moved the FileX SRAM disk buffer to the heap (see previous comment), the quick fix to the LevelX NOR simulator driver for an H723 processor is to move it to D2_AHBSRAM_BASE in the CubeMX LevelX settings.