E_stackOverflow: ti.sysbios.knl.Task

Hi Weber,

Have you tried looking at ROV?  This tool will give you some more information on the Tasks in your system.  You can open ROV within CCS by selecting "tools -> ROV".  Note that ROV only works when the target is halted.

weber de souza calixto

1 - How can I get the 'name' of the reffered Task 0x80003e28? This way I could try increasing its stack size

How are you creating your Task instances?  Are you doing that at runtime, or statically via the BIOS configuration (*.cfg) file?

The Task parameter structure has a field for setting the name of the Task instance. For example, the following configuration code creates a Task instance named "tsk0".  At runtime, when the target is halted, ROV would show this task as "tsk0":

 var params = new Task.Params;
 params.instance.name = "tsk0";
 params.arg0 = 1;
 params.arg1 = 2;
 params.priority = 1;
 Task.create('&tsk0_func', params);

ROV will also tell you the address of the Task instances.  So, you could look for 0x80003e28 in ROV to find it and see which function is associated with the Task instance.  Once you know the function, you can find the Task creation code that uses that function and then you would know where to increase the stack size?

weber de souza calixto

2 - Is there anyway that I can 'purge' the task stack, in order to 'clean' any garbage that this external (big) library has left?

Not for a running Task (in fact, this would have undesirable results and cause undefined behavior, probably a system crash).

If you dynamically created a Task, its stack will be allocated from the heap.  If you then delete the Task, the memory should be available again.

However, I suspect you just need to increase the stack size, as the stack is automatically un-wound when function calls return, etc.

weber de souza calixto

3 - How do I edit the 'linkcmd.xdt in the ti.targets.elf package'? Everytime I edit the bios .cfg file, the linker.cmd file is overwritten, and I have to edit it again to put some objects on DDR3.

Your application has a generated linker command file.  It is overwritten each time you build, so, as you've discovered, any modifications to it will be lost once you build.

What are you trying to accomplish?  Are you trying to place certain sections into different memory segments?  You can do that from within your *.cfg file.

For example, to move the .text section into DDR3 you could do this:

Program.sectMap[".text"] = "DDR3";

For more information on that, please refer to the "Memory" chapter of the SYS/BIOS Users Guide.

Steve

Hi Steve,

I didnt knew about ROV. Unfortunately, CCS3 had so many problems with these kind of tools, that I gave up even before working with CCS4 and CCS5. I'll give it a try by next wednesday.

My tasks are created using the .cfg file.

I really tried to increase the stack size. But, because of the libraries size, I must allocate a few sections on DDR3 instead of L2 and so on.

I've edited the .cfg file to put, for example, .far on DDR3. However, .fardata (a big one, as far as I remember) still goes to somewhere else that isnt DDR3 (I cant remember exactly now). So, what I've been doing is to edit .cfg, compile and let the allocation problems happen, then edit the dinamically generated linker.cmd in order to fully meet my alocation points and finally get a successfull. As you can see, this is boring and time-consuming, once that to compile and link a code this big takes a lot of time.

The point is, my final code is so big (.out for only the master core is ~18MBytes), that I must redirect the bigger sections to DDR3. There is anyway that I can edit the .fardata section definition, and others that doesnt show up on .cfg file?

Just to let you know, the 'gigantic' library is a proprietary opencv port + other accessory libraries.

What should be my approach to sections allocation and stack size, in order to release as much space as possible to stack size? My final goal is to run 'number_of_cores' instances of this big library in order to implement real time OCR for traffic surveillance IP cameras.

Weber,

weber de souza calixto

I've edited the .cfg file to put, for example, .far on DDR3. However, .fardata (a big one, as far as I remember) still goes to somewhere else that isnt DDR3 (I cant remember exactly now).

Did you know about the map file that's generated?  This file is created during your application build and will have the extension ".map".  You should see it under the "Debug" folder of your project.

You can use the map file to see which sections are placed where, and also to see how much space is being used in each memory segment.

weber de souza calixto

then edit the dinamically generated linker.cmd

Weber, you *should not* be editing the auto-generated linker.cmd file!  If you make edits to this file, they will be overwritten!  Since you are putting in a lot of effort to make such changes, it would be unfortunate for all of that work to get lost.  All of your edits should be done in either the *.cfg file, or you should make a custom linker command file for your application (more on this below).

weber de souza calixto

So, what I've been doing is to edit .cfg, compile and let the allocation problems happen, then edit the dinamically generated linker.cmd in order to fully meet my alocation points and finally get a successfull. As you can see, this is boring and time-consuming, once that to compile and link a code this big takes a lot of time.

As I just mentioned, you can also create a custom linker command file to place sections as needed.  This may speed up your build because you won't have to rebuild the *.cfg file and all of the rest of your sources each time.  However, if you do this, you will still need to have a change to your *.cfg file (hence requiring you to rebuild all of your code again) but after that you should only need to make edits to your linker command file.

To do this, you should use the configuration parameter Program.sectionsExclude.  This parameter takes a regular expression that will allow you to specify the sections placement that you *do not* want to be auto-generated into the (auto-generated) linker command file.  For example, you could specify a regular expression as follows which would tell the tool that *no section placement* should be auto generated.  In this case, your custom linker command file would need to handle the placement:

    // Note: the '.' below represents _any_ character, not just "." Program.sectionsExclude = ".*";

To make your own linker command file, you just need to create a new file with ".cmd" extension and add it to your project.

For more information on this, please see the documentation on Program.sectionsExclude: http://rtsc.eclipse.org/cdoc-tip/xdc/cfg/Program.html#sections.Exclude

Also, please see this forum post in which another customer faced a similar issue:

http://e2e.ti.com/support/embedded/bios/f/355/p/140179/506295.aspx#506295

Steve

Steve,

I do understand that I shouldn't edit the linker.cmd file (mainly because of the big warning at its beginning). However, at the moment, this was the only solution until someone replied to this post. About the .map file, I've already checked it, that is how I discovered the biggest sections (the ones that I've moved to DDR3).

By next wednesday I will check ROV and make a custom linker command file to meet my section allocation requirements.

Thanks for the tips.

Weber

Steve,

I've tried to put ROV to work, but seems to be a issue on eclipse. I've created another thread on CCS section of this forum, to see if someone can help:

http://e2e.ti.com/support/development_tools/code_composer_studio/f/81/t/186182.aspx

Meanwhile, there is any other way that I can see the Task name by its identifier?

Weber,

The best method to view a Task by name is through ROV.  There is no better way than that.  You should try to resolve your ROV issue because it will really come in handy when you need to debug a problem.

Judah

At this moment, I'm not looking for the better way. I really need ANY way.

A guy on the ROV post just asked me to create a new workspace to see if ROV works, which doesnt. I don't think that will any valuable help will come out from there.

Weber,

I think I need to rephrase my post as "The only way to view a task based upon the name is through ROV".

The name string isn't stored on the target memory.  It is extrapolated from some rov file.

Judah