FileX help

[KKobe.1]

Platform Nucleo-H563ZI
CubeIDE V1.15.0
ioc file attached

I'm starting with a simple app to get fimilar with the new Middleware.
I created a new STM32 app and enabled ThreadX and FileX.
I also changed the recommended settings for IChache and the system timer (TIM2)

I enabled the BSP LEDs, button, and virtual serial port.

For ThreadX I enabled the core and used static allocation
I tried a pool size of 2048 and 8096 with the same results

For FileX I enabled the core and checked the 'Internal RAM Interface' setting
I tried SRAM3 and SRAM1 with the same results

I created one user thread and put the following in it.

while(1)
{
tx_thread_sleep(10);

BSP_LED_Toggle(LED_GREEN);
BSP_LED_Toggle(LED_YELLOW);
BSP_LED_Toggle(LED_RED);
}

The first thing I noticed is that the BSP init code is placed after
MX_ThreadX_Init(), and does not get executed.
I copied that code before MX_ThreadX_Init()

If the call to create the FileX thread in tx_application_define() is executed,
the code crashes with the cursor at the top of _fx_utility_logical_sector_read()
which is called from _fx_utility_FAT_entry_read()

If I comment the line: status = MX_FileX_Init(memory_ptr); and the return check code,
the code runs and my LEDs blink.

Is there something I missed?

Karl

[SHs]

Hello @KKobe.1 ,

Could you please attach the IOC file associated with your project? 

[potatobandit]

I am having this exact issue. Trying to get Filex working on a basic Threadx project for the Nucleo-H563ZI using SRAM. 
If the call to create the FileX thread in tx_application_define() is executed,
the code crashes with the cursor at the top of _fx_utility_logical_sector_read()

Were you able to solve this issue or does ST have any advice to what is causing the problem?

[potatobandit]

Attached is the ioc for reference.

[DmitryR]

Hi all,

you may check this post of mine. To be short, FileX has a severe error working with cache and nobody is eager to correct it. @KKobe.1 , I think that this may help you. @potatobandit , your project may be not affected by this very bug directly as you use RAM which uses no DMA access so needs no cache invalidation. So I would consider looking on which address it fails and then look if memory contents around this address are changed after calling FileX interface. Maybe there is one another error here.

Regards,

Dmitry

[potatobandit]

Thanks! Disabling cache allowed me to get further into the program. I finally got the basic project working. Turns out the default 'FileX Application Thread Stack Size" is too small to run the base generated code (fx_media_open). After increasing the Stack Size and the Memory Pool Size, I was finally able to get a functioning prototype. 
I made the assumption that the default settings were acceptable:)
If anyone has this same issue, I added my FileX Core Init settings to this post.
Solved: Basic ThreadX / FileX example - STMicroelectronics Community

[DmitryR]

Hi @potatobandit ,

perfect, but without cache your applications will run too slow. I suggest finding the error with cache. As an alternative you may try to align all buffers that you pass to file read and write functions to a cache line (32 bytes). For me that was not possible as the buffers were presented by SQLite, so I had to find the bug.

Regards,

Dmitry