Loading...
 

Zephyr project on STM32

   Zephyr Workbench, a VSCode extension to manage Zephyr on STM32.
It enables users to easily create, develop, and debug Zephyr applications.
Main features:
  • Install host dependencies.
  • Import toolchain and SDK.
  • Create, configure, build and manage apps.
  • Debug STM32.
You can directly download it from the VSCode marketplace
For more details, visit the Zephyr Workbench

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.


 

Newest Forum Posts

  1. reservation car service Seattle by Jamesprede, 2025-05-01 10:06
  2. Last day: drone bonus by Danielrug, 2025-04-19 16:55
  3. SPI on Nucleo_STMH533RE by higginsa1, 2025-03-25 07:37
  4. SPI on Nucleo_STMH533RE by royjamil, 2025-03-23 11:31
  5. SPI on Nucleo_STMH533RE by higginsa1, 2025-03-23 09:33
  6. Configuring DMA for ADC in SW? by sam.hodgson, 2025-03-04 12:58
  7. Insightful Perspectives on This Subject by davidsycle, 2025-03-04 05:45
  8. Build a project in "release" mode by info@creosrl.it, 2025-02-20 18:12
  9. Build a project in "release" mode by info@creosrl.it, 2025-02-20 17:05
  10. Build a project in "release" mode by tang, 2025-02-20 10:36

Last-Modified Blogs