• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Answers 1 answer
  • Subscribers 55 subscribers
  • Views 983 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CCS/CC3220SF-LAUNCHXL: How do I get finished threads from the system?

Franz Schellhase
Expert 3605 points
Part Number: CC3220SF-LAUNCHXL
Other Parts Discussed in Thread: CC3220SF, CC3200

Tool/software: Code Composer Studio

Hi team,

a customer has the following question:

"I ran the example TCP-Echo from TI in the variant TI Toolchain + TI-RTOS in the debugger.
In this example, a new thread is started for each accepted client request, in which the communication with the respective client then takes place.
According to the program code, the thread terminates if the recv returns an error or 0.
In my test, I started a client, aborted it with CTRL-C, restarted it and so on. Only one client was active at a time.

Client program:
- TI PythonScript
- Call:
python tcpSendReceive.py 192.168.178.30 1000 test -s1000 -n10
- Termination CTRL-C

Already the third connection attempt failed here. The module was then no longer in the network (the router lists the WiFi subscribers).

The RunTime Object Viewer also shows the actually finished threads. These had priority 3, now -1 and still occupy memory/ stack. This inevitably means that with an increasing number of clients and/or logins the system runs out of memory.

If more threads are created, then their stack pointer is always higher than that of the previous, already completed process.
Is it possible to free this "dead" RAM area again? Or is the stack memory of the finished threads "free" for the system and is it provided on demand?

Hence my question: How do I get the finished threads from the system?
A pthread_exit at the end of the tcpWorker thread does not help."

Thank you,

Franz

  • 0
    TI__Genius 12025 points

    Franz,

    Looks like the software is not behaving correctly. The tcpWorker tasks should terminate and then be deleted by the Idle task. I see that the expired tasks are in the inactive state; this probably explains why the Idle task is not deleting them.

    I will have to setup a test bench and investigate. Which SDK release are you using?

    SimpleLink CC32xx SDK 3.20.0.06 is the latest release.

    One suggestion is to modify the example to make the tcpWorker task place itself on a delete list before it expires. Then, write your own idle function to delete all tasks on the delete list.

    ~Ramsey

  • 0 in reply to Ramsey
    TI__Genius 12025 points

    Franz,

    First data point. I tested SimpleLink MSP432E4 SDK 3.20.00.10 and it behaves correctly. There must be a difference between the NDK and Wi-Fi stacks. I'll continue to investigate.

    ~Ramsey

  • 0 in reply to Ramsey
    Expert 2051 points

    Hello all,

    my name is Roman and i am the customer.

    First of all, thanks for your help.

    I used the unmodified tcpEcho example from the SDK simplelink_cc32xx_sdk_3_20_00_06. The sample is also linked against this SDK version.

    For a second run i set "Task.deleteTerminatedTasks = true;" in the release.cfg but the result is the same.

    For additional information: I also flashed the service pack coming with the SDK. But I think that's not the problem.

    Best wishes,
    Roman

  • 0 in reply to Roman Jordan
    Guru 39650 points

    Hi Roman,

    I use option Task.deleteTerminatedTasks = true; inside my code based on latest CC32XX SDK and it works without any issue.

    I use multi-client TCP servers with separate tasks for clients socket. I did not create again and again new task because it is wasting of resources. When is client connection closed, I suspend a task and resume when is needed for new client.

    Jan

  • 0 in reply to Hnz
    Expert 2051 points

    Hi Jan,

    many thanks for your response.

    I have already set the option Task.deleteTerminatedTasks = true in the file release.cfg of the tirtos project.

    Yes you are right always creating new tasks needs a lot of ressources. Your way is a better one, of course. I think I will also use this way as well. Later ;)

    But the behavior I described  (task is terminated but still uses ressuorces) is not correct.

    I also have a lot of problems with the tcpEcho. After some minutes sometime hours the python based echo test stops and the module says Goodby to my network. Without any comment. I inserted some DebugOutputs in the error/ status callback  functions but I can't see any output.

    Do you have WiFi problems, like disconnects?

    I notices disconncts on different places, different WiFi networks with different TI evalboards.

    Many Thanks,
    Roman

  • 0 in reply to Roman Jordan
    Guru 39650 points

    Hi Roman,

    I use CC3220SF with really big project (many features, more than 300k lines of my code). I haven't any significant issue which I was not be able solve. From my point of view is CC3220 a very stable platform. Much better than older CC3200. There may to be a few thing which should be improved, few thing should be done by different way, but nothing is perfect. I started using CC32xx devices many years ago. I use CC32XX longer than many members of TI SimpleLink Wifi App team actually.

    I think there is a one issue with SDK examples. SDK examples are not such bulletproof than should be. Many things should be handled in examples by different way. Idea behind these examples is to be code as simple as possible. But I think this approach may to be counterproductive. But this is my opinion only.

    There may to be many reasons for such of behaviours. At first step you should make sure that you not stuck at hard fault handler. If you be sure than your host code is still running, you can capture NWP log. This log you can upload into WiFi forum. Guys from TI App team are able decode this log and are able say what is gonging on. My experience with CC3220 is that, more than 99% issues I created by yourself. Only small number of issues are due to CC2XX platform itself.

    Jan

  • 0 in reply to Hnz
    TI__Genius 12025 points

    Franz, Roman,

    I have found the problem; it is a bug in the tcpEcho example, not in the Wi-Fi stack. This means you can fix it easily.

    The problem is that the tcpEcho example creates each tcpWorker thread in the 'attached' state. This means that when the tcpWorker thread is ready to terminate, it will wait to join with the parent thread. However, the parent thread never joints with the tcpWorker thread, so it waits forever.

    The fix is to create the tcpWorker thread in the 'detached' state. This means it will terminate without waiting to join with the parent.

    Edit the file platform.c (in the tcpEcho example). Look for the function TaskCreate(). Insert the following lines:

    int detachState;

    detachState = PTHREAD_CREATE_DETACHED;
    pthread_attr_setdetachstate(&pAttrs_tcp, detachState);

    Do this after the call to pthread_attr_init() and before the call to pthread_create().

    I will file a bug on this so it will get fixed in an upcoming SDK release.

    ~Ramsey

  • 0 in reply to Hnz
    Expert 2051 points

    Hi Jan,

    many thanks for your information. It's giving me a good feeling.

    I know not that in the very most cases the problem is sitting in front of the computer and not inside it.
    Thats's life.

    Best wishes,
    Roman

  • 0 in reply to Ramsey
    Expert 2051 points

    Hi Ramsey,

    I can't say why I didn't see it in the example code.

    I my program I created the tasks as detachable and have no problem with this. Because I had some problems with my program I switched back to the example code. ;)

    At least I was able to make first experiences with ROV.

    Many thanks to you all,
    Roman