Eheh i done it :) . The problems were in code generated from the matlab real-time workshop from a simulation i have with blocks working at different rates. So now i tried to run the model advisor tool and fixed some code generation process options that were wrong. For instance, it was generating code for emulation, which was not needed in the final implementation. And it was set for single-tasking instead of multitasking. I then attached this OK generated code to my communications layer, all under RTEMS as i was doing before but with the bad generated code, and now it works perfectly.<br>
<br>Basically it was a RTW code generation problem.<br><br><br>Sincerely, thank you all.<br><br>Best,<br>JM<br><br><div class="gmail_quote">On Tue, Nov 16, 2010 at 12:09 PM, Joćo Rasta <span dir="ltr"><<a href="mailto:freakforever@gmail.com">freakforever@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">I increased the stack sizes, but now i seem to be having trouble with the register windows. Now gdb complaints when performing a "ret" after getting out of a function:<br>
<br>0x4000a534 <mdlOutputs+328>: std %f8, [ %l5 + 8 ]<br>
}<br>0x4000a53c <mdlOutputs+336>: ret <<<<---- SEG FAULT<br>0x4000a540 <mdlOutputs+340>: restore <br><br>Here's the Stack copy:<div class="im"><br><br>Thread [3] (Suspended: Signal 'SIGSEGV' received. Description: Segmentation fault.) <br>
</div>
6 mdlOutputs() C:\opt\build\Real_GNC\code\GNC\source\guidance_s.c:373 0x4000a53c <br> 5 gnc_output() C:\opt\build\Real_GNC\model\backups\gnc_linux\gnc.c:307 0x40008d80 <br> 4 Execute_gnc() C:\opt\build\Real_GNC\model\backups\gnc_linux\gnc_wrapper.c:116 0x4000a180 <br>
3 task_main() C:\opt\build\Real_GNC\src\shell\gnc_scheduler_task.c:125 0x40006144 <br> 2 _Thread_Handler() c:\opt\rtems-4.10-mingw\src\rtems-4.10\cpukit\score\src\threadhandler.c:156 0x4003bdb0 <br> 1 _Thread_Handler() c:\opt\rtems-4.10-mingw\src\rtems-4.10\cpukit\score\src\threadhandler.c:87 0x4003bc88 <br>
<br>What could be generating such a problem? Do i need to change any RTEMS configuration related to the register windows?<br><br><br>Best,<br>JM<div><div></div><div class="h5"><br><br><br><br><br><div class="gmail_quote">
On Mon, Nov 15, 2010 at 9:18 PM, Gedare Bloom <span dir="ltr"><<a href="mailto:gedare@gwmail.gwu.edu" target="_blank">gedare@gwmail.gwu.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">That should work with posix, at least to increase the amount of space pre-allocated for task stacks. You will also need to ensure that you use a large enough value of pthread_attr_t->stacksize when you call pthread_create().<br>
<br>The suggestion to declare your large arrays as static can work in case your function is non-reentrant, otherwise you have to worry about sharing.<br><font color="#888888"><br>-G</font><div><div></div><div>
<br><br><div class="gmail_quote">On Mon, Nov 15, 2010 at 3:15 PM, Joćo Rasta <span dir="ltr"><<a href="mailto:freakforever@gmail.com" target="_blank">freakforever@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">Hi Gedare,<br><br>Will CONFIGURE_EXTRA_TASK_STACKS also work with the POSIX API?<br><br><br>
Best,<br>JM<div><div></div><div><br><br><div class="gmail_quote">On Mon, Nov 15, 2010 at 6:34 PM, Gedare Bloom <span dir="ltr"><<a href="mailto:gedare@gwmail.gwu.edu" target="_blank">gedare@gwmail.gwu.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">Joćo,<br><br>You can configure extra space for all of your tasks like this:<br> #define CONFIGURE_EXTRA_TASK_STACKS (RTEMS_MINIMUM_STACK_SIZE * ??)<br>
Where you put ?? to make it a multiple of min stack size, or you can just put an arbitrary number of bytes.<br>
<br>Otherwise you can increase the stack_size argument to rtems_task_create for a particular task.<br><br>You might also try configuring with CONFIGURE_STACK_CHECKER_ENABLED defined. It does some extra checks for stack bounds and might give you a tighter window for debugging where the problem is occurring.<br>
<font color="#888888">
<br>-Gedare</font><div><div></div><div><br><br><br><div class="gmail_quote">On Mon, Nov 15, 2010 at 1:13 PM, Joćo Rasta <span dir="ltr"><<a href="mailto:freakforever@gmail.com" target="_blank">freakforever@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Hi Joel,<br><br>Good point. I have a task that is heavy on memory operations (multi-size array operations and so on). It also has a lot of doubles so it can also be corrupting its stack. Too bad it is 'silent' when corrupting the memory one way or another.. <br>
<br>To eliminate the stack overflow issue, i guess it is not enough to increase the initial task stack size. Is there a way to control the subsequent called task stack sizes?<br><br><br>Best,<br>JM<div><div></div><div>
<br><br><br><div class="gmail_quote">
On Mon, Nov 15, 2010 at 5:43 PM, Joel Sherrill <span dir="ltr"><<a href="mailto:joel.sherrill@oarcorp.com" target="_blank">joel.sherrill@oarcorp.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div>On 11/15/2010 11:24 AM, Joćo Rasta wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
After some hard debuggin' with gdb i found out that this error is occurring at _Semaphore_Translate_core_mutex_return_code() but i still don't know why it happens. Here's the disassembly of the code where the error is generated<br>
<br>
0x40040d88 <rtems_semaphore_obtain+192>: ld [ %l3 ], %g1<br>
0x40040d8c <rtems_semaphore_obtain+196>: call 0x400410c8 <_Semaphore_Translate_core_mutex_return_code><br>
0x40040d90 <rtems_semaphore_obtain+200>: ld [ %g1 + 0x34 ], %o0<br>
0x40040e20 <rtems_semaphore_obtain+344>: b 0x40040d8c <rtems_semaphore_obtain+196><br>
0x40040e24 <rtems_semaphore_obtain+348>: ld [ %l3 ], %g1<br>
0x40040ed8 <rtems_semaphore_obtain+528>: b 0x40040d8c <rtems_semaphore_obtain+196><br>
0x40040edc <rtems_semaphore_obtain+532>: ld [ %l3 ], %g1<br>
<br>
And Stack copy:<br>
<br>
Thread [3] (Suspended: Signal 'SIGSEGV' received. Description: Segmentation fault.)<br>
3 rtems_semaphore_obtain() c:\opt\rtems-4.10-mingw\src\rtems-4.10\cpukit\rtems\src\semobtain.c:90 0x40040edc<br>
2 <symbol is not available> 0x00000008<br>
1 <symbol is not available> 0x0000000c<br>
<br>
</blockquote></div>
If this is the backtrace, somehow the stack pointer has gotten<br>
corrupted.<div><br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
The last value i could get from %g1 is 0. <br>
</blockquote></div>
If this task is not blowing its stack, then we are left with a couple<br>
of guesses:<br>
<br>
+ another task is blowing its stack and corrupting memory<br>
that impacts this task.<br>
+ stray write is corrupting something.<br>
<br>
When did you see the %g1 have 0? What was the last instruction?<br>
Where was it loading from?<div><br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Here's how i'm configuring semaphores:<br>
<br>
#define CONFIGURE_MAXIMUM_POSIX_SEMAPHORES 15<br>
<br>
</blockquote></div>
This only affects POSIX semaphores sem_XXX.<div><br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
Any hints on what it can be failing? Should i set CONFIGURE_MAXIMUM_SEMAPHORES as well?<br>
<br>
</blockquote></div>
I doubt it since you appear to be completing a semaphore_obtain.<br>
That means (probably) that a semaphore_create worked.<br>
<br>
Do a backtrace in gdb. I suspect you will find you are coming from a subsystem<br>
like termios.<br>
<br>
-joel<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
Best,<br>
JM<div><br>
<br>
<br>
<br>
<br>
On Fri, Nov 12, 2010 at 7:34 PM, Joel Sherrill <<a href="mailto:joel.sherrill@oarcorp.com" target="_blank">joel.sherrill@oarcorp.com</a> <mailto:<a href="mailto:joel.sherrill@oarcorp.com" target="_blank">joel.sherrill@oarcorp.com</a>>> wrote:<br>
<br>
On 11/12/2010 01:05 PM, Joćo Rasta wrote:<br>
<br>
Hi Daron,<br>
<br>
It is running on a LEON-3. The application exits raising the<br>
following exception:<br>
<br>
IU in error mode (tt = 0x07)<br>
<br>
which is a memory access to an unaligned address. The last<br>
instruction is this:<br>
<br>
4003bd74 d0006034 ld [%g1 + 0x34], %o0<br>
<br>
What is the value of g1? Is it unaligned?<br>
<br>
I don't understand why i have this error. The code where this<br>
error is being reported is compiled independently and then put<br>
in a library, but it uses the same cross-compiler as the main<br>
source code. I don't think i'm doing something wrong while<br>
compiling the library files, i use the same compilation flags..<br>
<br>
What can i be missing to have unaligned memory accesses?<br>
<br>
<br>
Best,<br>
JM<br>
<br>
<br>
<br>
On Fri, Nov 12, 2010 at 6:43 PM, Daron Chabot<br>
<<a href="mailto:daron.chabot@gmail.com" target="_blank">daron.chabot@gmail.com</a> <mailto:<a href="mailto:daron.chabot@gmail.com" target="_blank">daron.chabot@gmail.com</a>><br>
<mailto:<a href="mailto:daron.chabot@gmail.com" target="_blank">daron.chabot@gmail.com</a><br>
<mailto:<a href="mailto:daron.chabot@gmail.com" target="_blank">daron.chabot@gmail.com</a>>>> wrote:<br>
<br>
<br>
On Fri, Nov 12, 2010 at 11:50 AM, Joćo Rasta<br>
<<a href="mailto:freakforever@gmail.com" target="_blank">freakforever@gmail.com</a> <mailto:<a href="mailto:freakforever@gmail.com" target="_blank">freakforever@gmail.com</a>><br></div>
<mailto:<a href="mailto:freakforever@gmail.com" target="_blank">freakforever@gmail.com</a><div><div></div><div><br>
<mailto:<a href="mailto:freakforever@gmail.com" target="_blank">freakforever@gmail.com</a>>>> wrote:<br>
<br>
Hi,<br>
<br>
I have an RTEMS POSIX API application which comes to a<br>
point<br>
that if a small function (with some doubles passed as<br>
arguments) is called, the application exits with an<br>
error. At<br>
first i thought of increasing the stack space. I did<br>
this with<br>
CONFIGURE_POSIX_INIT_THREAD_STACK_SIZE but the problem<br>
remains<br>
even if i remove all the contents of the function.<br>
<br>
1) Am i setting up the stack size correctly? I think i<br>
am, but<br>
i ask just in case..<br>
<br>
2) Is there any other explanation to why a function call<br>
crashes the application besides having a full stack?<br>
Again, i<br>
erased the function contents..<br>
<br>
<br>
What architecture is this running on ?<br>
<br>
What is the application exit error (message and/or return<br>
code)?<br>
<br>
It looks like all POSIX threads are created as floating-point<br>
tasks (FP state saved across context switches), so there<br>
"shouldn't" be a problem on that aspect...<br>
<br>
<br>
<br>
Best,<br>
JM<br>
<br>
<br>
<br>
_______________________________________________<br>
rtems-users mailing list<br>
<a href="mailto:rtems-users@rtems.org" target="_blank">rtems-users@rtems.org</a> <mailto:<a href="mailto:rtems-users@rtems.org" target="_blank">rtems-users@rtems.org</a>><br></div></div>
<mailto:<a href="mailto:rtems-users@rtems.org" target="_blank">rtems-users@rtems.org</a> <mailto:<a href="mailto:rtems-users@rtems.org" target="_blank">rtems-users@rtems.org</a>>><div><br>
<br>
<a href="http://www.rtems.org/mailman/listinfo/rtems-users" target="_blank">http://www.rtems.org/mailman/listinfo/rtems-users</a><br>
<br>
<br>
<br>
<br>
<br>
-- Joel Sherrill, Ph.D. Director of Research& Development<br>
joel.sherrill@OARcorp.com On-Line Applications Research<br>
Ask me about RTEMS: a free RTOS Huntsville AL 35805<br>
Support Available (256) 722-9985<br>
<br>
<br>
<br>
</div></blockquote><div><div></div><div>
<br>
<br>
-- <br>
Joel Sherrill, Ph.D. Director of Research& Development<br>
joel.sherrill@OARcorp.com On-Line Applications Research<br>
Ask me about RTEMS: a free RTOS Huntsville AL 35805<br>
Support Available (256) 722-9985<br>
<br>
<br>
</div></div></blockquote></div><br>
</div></div><br>_______________________________________________<br>
rtems-users mailing list<br>
<a href="mailto:rtems-users@rtems.org" target="_blank">rtems-users@rtems.org</a><br>
<a href="http://www.rtems.org/mailman/listinfo/rtems-users" target="_blank">http://www.rtems.org/mailman/listinfo/rtems-users</a><br>
<br></blockquote></div><br>
</div></div></blockquote></div><br>
</div></div></blockquote></div><br>
</div></div></blockquote></div><br>
</div></div></blockquote></div><br>