I'm working with the EVM6678LE board, impleting a really big library (to do real-time car plate recognition, the library has near 15MB of binary code).
After I call its single external function, it returns the expected results.
The problem happens after, when I post some MessageQ_create to 8 other threads (in other cores), or happens when I post MessageQ_get to only one thread in other core:
[C66xx_0] ti.sysbios.knl.Task: line 330: E_stackOverflow: Task 0x80003e28 stack overflow.[C66xx_0] xdc.runtime.Error.raise: terminating execution
I think that this big library is consuming almost the entire stack size, and after it there isnt enough stack left.
I already tried to edit the generated linker.cmd file, to put the biggest symbols on DDR3. Without success.
My questions are:
1 - How can I get the 'name' of the reffered Task 0x80003e28? This way I could try increasing its stack size
2 - Is there anyway that I can 'purge' the task stack, in order to 'clean' any garbage that this external (big) library has left?
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.
Any help will be really apreciated.
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 calixto1 - 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 calixto2 - 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 calixto3 - 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.
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 de souza calixtoI'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 calixtothen 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 calixtoSo, 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:
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.
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:
Meanwhile, there is any other way that I can see the Task name by its identifier?
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.
If my reply answers your question please mark the thread as answered
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.
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.
Ok, got it.
I've moved to linux, were I can run ROV and set things in motion. This was some weird problem with Idle task.
Just by removing it the code worked.
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with respect to these materials. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.