How to debug multi-threading problems

Kernel
1

ht069 wrote on Sunday, August 19, 2018:

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.

2

rtel wrote on Sunday, August 19, 2018:

You have a lot of software running, and quite a vague report of what the
issue is, so I don’t think anybody will be able to provide a precise
response at this time. Some questions though:

3

ht069 wrote on Monday, August 20, 2018:

Hi Richard Barry.
Thanks for your reply.
About USB i have to say that i used demonstration of discovery f746 and i added all configs related to usb from that demo that’s why i dont have detailed information about USB.

‘What does FR_NOT_ENOUGH_CORE mean?’
When mkdir function returns this value ,this means that there is no enough memory.And there is a question abaut it : Why didn’t this problem happen before adding a new thread?

What does “the running process stuck in RTOS’s functions.” mean?
Before adding a new thread, most of the time the program worked well but sometimes an error occurred and the program didn’t worked anymore.
But this problem didn’t happen regularly.

4

rtel wrote on Monday, August 20, 2018:

‘What does FR_NOT_ENOUGH_CORE mean?’
When mkdir function returns this value ,this means that there is no
enough memory.And there is a question abaut it : Why didn’t this problem
happen before adding a new thread?

Which file system are you using.

What does “the running process stuck in RTOS’s functions.” mean?
Before adding a new thread, most of the time the program worked well but
sometimes an error occurred and the program didn’t worked anymore.
But this problem didn’t happen regularly.

Unfortunately that doesn’t really answer the question - we would need to
know what the MCU was actually doing when it appeared to not be working
any more. If you were to stop it in the debugger for example, what
would you see executing?

5

ht069 wrote on Tuesday, August 21, 2018:

Hi Richard Barry.
Thanks for your reply.

Which file system are you using.

I’m using FatFs.

After several tests i found out the thread is craeted for USB dosen’t free memory.
I just want to know how i can free the memory allocated by thread.

Best Regards,
Hossein Teymouri

6

rtel wrote on Tuesday, August 21, 2018:

Do you mean the memory allocated by the kernel for use as the task’s stack and tcb? That will get freed automatically. Any memory manually allocated by the task would likewise have to be manually freed.

7

ht069 wrote on Tuesday, August 21, 2018:

In our project we have a sd card that some files and folders are saved on it.Now we’ve added USB msc mode in our project and we want when user press the “USB” button those files and folders saved on sd card would be transferred on USB flash memory.

As I mentioned in first post after several times running the routine (send files and folders on USB flash memory), mkdir and fopen functions return FR_NOT_ENOUGH_CORE.

Now we want to delete usbthread when the data are sent completely and when user press “USB” button again the usbthread be created again and in the end of thread, usbthread deleted.Unfortunately we couldn’t do this until now.

I attached the code here.

If it’s possible please take a look at this.

Best Regards

8

rtel wrote on Tuesday, August 21, 2018:

As I’m afraid this is not our code, and the project was not provided by
us, and the libraries you are using are third party and not libraries we
are familiar with (other than the kernel)…there is just too much code
for us to look through here so we can’t offer directed replies. I would
however note that this did catch my eye while skimming:

 vTaskSuspendAll();
 USBThreadId = NULL;
 vTaskDelete( xTask );
 xTaskResumeAll();

As a rule of thumb, FreeRTOS API functions should never be called from
within a critical section or with the scheduler suspended. Not that it
should be an issue in that particular case, but you are venturing out of
documented behaviour.

9

ht069 wrote on Wednesday, August 22, 2018:

Hi Richard Barry.

I am very grateful to your guidance.

I have to read the related documents more carefully again.