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.

Issues between Tasks/Semaphores creation and code execution

Other Parts Discussed in Thread: TMS320F28027

Hello,

I'm a newbie on TI Sys/Bios.. I was trying to create a program with Sys/Bios using two tasks and semaphores, the lowest priority task was created to send some float values to the PC using sprintf function.

This sprintf function was causing a stack overflow error, while I was looking for clues to solve the problem (namely heap size, memory allocation, stack size) I found that the error was dependent on the way that I create the project.

If I create the project using sample CCS project C28x "Task" example it would gave me no error, otherwise, if I create a CCS generic project using "Task Mutex" example the sprintf function would block the code execution due to overflow.

Then I've found, through ROV, that my tasks wouldn't show up (in ROV) unless I create them in the configuration file (*.cfg).

I this normal? Which is the best way to create tasks?? Main code (*.c file) or *.cfg file?

It seems to happen with the semaphores too, when I create semaphores in the main file I can't see them in ROV.

Does anyone knows why?

Is the initialization of semaphores and tasks inside *.cfg file a better pratice?

Now that created a task o the *.cfg file and the semaphores are still initialized on the main file, the code seems not to respect the semaphore and the timing respecting the task initialized in the *.cfg file. (instead of sending to the PC every 500 ms it keeps sending without stop)

Thanks in advance.

Mário Silva

  • Mário,

    What version of SYS/BIOS are you using?


    Todd

  • Hi Todd,

    thanks for spending your time.

    My SYS/BIOS version is 6.35.1.29.

    Regards,

    Mário

  • Yes, dynamically created Tasks do show up in ROV. Did you halt the target. ROV only refreshes when the target is halted.

    The advantage of creating things in the .cfg file (also called creating it statically) is that you save code footprint. For example, Task_create code is not in the target application.

    The advantage of creating things dynamically is flexibility. During runtime you determine something is not needed, you just don't create it.

    Todd

  • Thank you Todd for the answer.

    I got the idea about the creation of tasks and semaphores..

    Nevertheless, I've managed to pass my two tasks and two semaphores creation to the configuration file in order to give it a try.. Unfortunately I'm getting an error, now its on .ebbs line of the TMS320F28027.cmd file.

    It seems that I'm getting almost all the errors related to memory (my idea)..Is it too much a code with two tasks and two semaphores for the F28027 LaunchPad?

    Do you think that my problems might be related to the sprintf function inside the real-time tasks??

    Regards,

    Mário

  • Are they build errors or runtime errors?

    If they are build errors, I except you probably need to decrease the stack size of the tasks. A good trick is to get the system running and then look in ROV->Task->Detailed to see the stack peak. Samething in ROV->Hwi->Module for the system stack peak. If the peaks are well below the size, you can decrease them.

    Todd

  • Hi Todd,

    thank you very much for telling me that trick, it was very helpful.. Is there any way to keep eye on the overall memory available to know how much is being used?

    Meanwhile I'll keep complicating the code ;)

    Thanks again..

    Regards,

    Mário

  • Are you talking about heap memory? If so, you can enable HeapTrack (BIOS.heapTrackEnabled = true) to sit on top of the default heap. HeapTrack adds some over-writing detection, high-water marks and memory leak detection. Refer to the HeapTrack documentation for more details.

    Todd