I've been having a difficult dsp/bios kernel crashing problem. It always
comes, when kernel changes running task to another one. I release currently
running task by function like SEM_postBinary(). Then a task with a higher
priority should start.
Normally everything works well, but when I put one more line into a code, x +=
1, or similar, whole thing crashes. It looks like memory fault (stack overflow),
but Kernel/Object Viewer doesn't show any memory leak. Not even close.
Compiler says everything goes ok while compiling, output.map doesn't show
any leak.
Could someone tell me any hints how to solve this out. Would it be helpful if I
sent two different map files. Another one works well but another one crashes.
Only one code line is different and it is not even used.
--
amppa
Kernel crashes
Started by ●December 17, 2008
Reply by ●December 18, 20082008-12-18
Aimo-
> I've been having a difficult dsp/bios kernel crashing problem.
> It always comes, when kernel changes running task to another one.
> I release currently running task by function like SEM_postBinary().
> Then a task with a higher priority should start.
>
> Normally everything works well, but when I put one more line into
> a code, x += 1, or similar, whole thing crashes. It looks like
> memory fault (stack overflow), but Kernel/Object Viewer doesn't
> show any memory leak. Not even close. Compiler says everything
> goes ok while compiling, output.map doesn't show any leak.
>
> Could someone tell me any hints how to solve this out. Would it
> be helpful if I sent two different map files. Another one works
> well but another one crashes. Only one code line is different and
> it is not even used.
Here are some typical guesses:
-you're writing one index beyond the end of an array
-call to memset() or similar "mass write" operation
doesn't do what you think, for example whatever
pointer you cast to void* is not quite what you
expect
-one .c file declares an array of short int and
another externs the same array as int, or similar
"mis match"
-an uninitialized variable "happens" to end up in a
bad spot when you slightly shift code/data around
One thing you can do is compare the two .map files to find any data structures that
shift slightly because of the extra line of code. Then scrutinize those very
carefully. Code sections that move slightly can't be ruled out, but are less likely
than a data section problem.
The fact that it seems to be kernel-related (task switch) is probably a false path.
Mostly likely the issue is something in your code.
-Jeff
> I've been having a difficult dsp/bios kernel crashing problem.
> It always comes, when kernel changes running task to another one.
> I release currently running task by function like SEM_postBinary().
> Then a task with a higher priority should start.
>
> Normally everything works well, but when I put one more line into
> a code, x += 1, or similar, whole thing crashes. It looks like
> memory fault (stack overflow), but Kernel/Object Viewer doesn't
> show any memory leak. Not even close. Compiler says everything
> goes ok while compiling, output.map doesn't show any leak.
>
> Could someone tell me any hints how to solve this out. Would it
> be helpful if I sent two different map files. Another one works
> well but another one crashes. Only one code line is different and
> it is not even used.
Here are some typical guesses:
-you're writing one index beyond the end of an array
-call to memset() or similar "mass write" operation
doesn't do what you think, for example whatever
pointer you cast to void* is not quite what you
expect
-one .c file declares an array of short int and
another externs the same array as int, or similar
"mis match"
-an uninitialized variable "happens" to end up in a
bad spot when you slightly shift code/data around
One thing you can do is compare the two .map files to find any data structures that
shift slightly because of the extra line of code. Then scrutinize those very
carefully. Code sections that move slightly can't be ruled out, but are less likely
than a data section problem.
The fact that it seems to be kernel-related (task switch) is probably a false path.
Mostly likely the issue is something in your code.
-Jeff
