Loading...
 

SW4STM32 and SW4Linux fully supports the STM32MP1 asymmetric multicore Cortex/A7+M4 MPUs

   With System Workbench for Linux, Embedded Linux on the STM32MP1 family of MPUs from ST was never as simple to build and maintain, even for newcomers in the Linux world. And, if you install System Workbench for Linux in System Workbench for STM32 you can seamlessly develop and debug asymmetric applications running partly on Linux, partly on the Cortex-M4.
You can get more information from the ac6-tools website and download (registration required) various documents highlighting:

System Workbench for STM32


How to debug multi-threading problems

Hi everyone.

we had performed a project with discovery f746 board that within it there just was a GUI task to run emwin functions.

Another functions(such as reading and writing in sd card by fatfs , usb, spi and stuff) were placed in the routines of Buttons.

After several times the process of USB (writing in USB flash memory) was ran ,

the running process stuck in RTOS’s functions.

After that we decided to add another thread for USB In such a way that, after pressing related button ,a message is sent to this thread.

At the first it works fine but after several times running this thread, mkdir function (for creating a folder in USB flash memory) returns FR_NOT_ENOUGH_CORE value and the program stops running.

For resolving this problem we increased stack and heap size and memory that is assigned to the thread but it didn’t affect.

In new version of our project we just added a new thread and the routine that was placed in Notification sent by related button was moved into new thread and another sections of projects haven’t changed.

In old version of project that there just was one thread , mkdir function never had returned FR_NOT_ENOUGH_CORE value.

It seems this problem is related to multi threading but we don’t know how to find out running process and fix problem.

Could anyone help us to resolve this problem?

We’ll appreciate your suggestions.

FatFS has some requirements as far as re-entrant behaviour goes (eg: FF_FS_REENTRANT) and constraints about what exactly can be called concurrently.

Also from memory the HAL USB stuff has requirements for being called concurrently.

Debugging concurrent stuff is not trivial - for example you write “after several times running this thread” - does that mean you create and destroy a new thread each time? Or that the thread is blocked, waiting for your message?
The former possibly leads to memory issues, the latter is how I’d do it personally.

You write “the program stops running” - does it crash or is your thread just blocked for some reason?


You appear to be creating but not destroying your dialog box; maybe this is your memory issue?
I’m not familiar with the Segger windowing stuff but maybe ending the dialog from another thread (your usb thread) is not correct.

Thanks for your reply.

I changed code and put ending the dialog in “cancel” button from GUI thread, but that problem happened again and it didn’t affect.