Hello experts!
I am working on amulti tasking systemwhich is using ucosii on RCM3100 core.
I have 10 tasks using 9 os_events.
when i run my program i got this message from dynamic c.
Unexpected interrupt
file:
line:0
Any on has some idea about it
Regards
Alain
Unexpected interrupt error
Started by ●January 8, 2004
Reply by ●January 8, 20042004-01-08
check the stack !!!
the little stack of Rabbit make difficult to work with UcosII ...
I useUcos at the beginnig but thecrash problem make me crazy
Now I use costate and I'm happy
the little stack of Rabbit make difficult to work with UcosII ...
I useUcos at the beginnig but thecrash problem make me crazy
Now I use costate and I'm happy
Reply by ●January 8, 20042004-01-08
check the stack !!!
but how?
I have alocated 512 to each task, and i think it is more than enough
Regards
Ahmed
but how?
I have alocated 512 to each task, and i think it is more than enough
Regards
Ahmed
Reply by ●January 8, 20042004-01-08
try 2048 or 4096 bytes for each task .
The heart of the problem is "how check the stack " I have no solution ... sorry
bye
The heart of the problem is "how check the stack " I have no solution ... sorry
bye
Reply by ●January 8, 20042004-01-08
In the old days of assembler and no power processor there was a simple method to
check the stack that is simple to use without an os or rtk but it is also
feasable.
Write a function that just after startup writes on ram just before the stack (every stack if you use an os). Suppose to have a 1kb stack, the function writes the 128 bytes before the stack (128 bytes may be changed it depends by your application) with a known pattern (may be 0, 1, 2, 3, 4 starting by the bottom to the top or 0x55 but the pattern have to be known) then examining the ram you may see if there was a stack problem or not. The problem is: when have I to examining the ram? Every time your program may use stack ram then, at every function call and every irq. This means that you have to write a little inline function or macro or asm subroutine that can check the buffer and is called inside every function to see if the stack is overwritten or not until now. Also you may just check for the address pointed by the stack pointer but remember that a function may corrupt the stack then at the end may reload correctly SP but it corrupted a ram area. In case of multitasking this piece of code may be task specific or have to know the ram location of the task stack. Obviously you have to provide a buffer before every stack. This type of test may found every type of stack overflow if you have ram and rom space to accomodate buffers and stack check function.
Write a function that just after startup writes on ram just before the stack (every stack if you use an os). Suppose to have a 1kb stack, the function writes the 128 bytes before the stack (128 bytes may be changed it depends by your application) with a known pattern (may be 0, 1, 2, 3, 4 starting by the bottom to the top or 0x55 but the pattern have to be known) then examining the ram you may see if there was a stack problem or not. The problem is: when have I to examining the ram? Every time your program may use stack ram then, at every function call and every irq. This means that you have to write a little inline function or macro or asm subroutine that can check the buffer and is called inside every function to see if the stack is overwritten or not until now. Also you may just check for the address pointed by the stack pointer but remember that a function may corrupt the stack then at the end may reload correctly SP but it corrupted a ram area. In case of multitasking this piece of code may be task specific or have to know the ram location of the task stack. Obviously you have to provide a buffer before every stack. This type of test may found every type of stack overflow if you have ram and rom space to accomodate buffers and stack check function.
Reply by ●January 8, 20042004-01-08
Tried an email as a potential answer but it seemed to go to the wrong
thread. uCOSII provides a function to retrieve the size of a tasks
stack (OSTaskStkChk). Check it out. You could either call it
periodically from each task or create a new task that checks all task
sizes.
I have developed 3 uCOSII projects and would like to share experiences
with others using the rabbit and uCOSII.
LK
thread. uCOSII provides a function to retrieve the size of a tasks
stack (OSTaskStkChk). Check it out. You could either call it
periodically from each task or create a new task that checks all task
sizes.
I have developed 3 uCOSII projects and would like to share experiences
with others using the rabbit and uCOSII.
LK
Reply by ●January 9, 20042004-01-09
Hello
First i would like to say thanks forallexperts who have commentedon "Unexpected interrupt"
There is something which i can't undertand about FS2 file system which is giveing me this problem i have found recently.
I am developping a project on RCM3100 core, i need FS2 file system
My multitasking system using ucos-ii works fine without any crash only when FS2_RAM_RESERVE =0
But if i use FS2_RAM_RESERVE any where from 1 to 50 (because i can use 200k for FS2 file system on SRAMas documents suggest) my program crashes with messages which are not always same
like unexpected interrupt file: line 0
orunexpected interrupt file: line 360
or Bad packet type 0ffffff98 subtype:020
Mayexperts tell me why i have this problem, please.
Regards
Alain
------
First i would like to say thanks forallexperts who have commentedon "Unexpected interrupt"
There is something which i can't undertand about FS2 file system which is giveing me this problem i have found recently.
I am developping a project on RCM3100 core, i need FS2 file system
My multitasking system using ucos-ii works fine without any crash only when FS2_RAM_RESERVE =0
But if i use FS2_RAM_RESERVE any where from 1 to 50 (because i can use 200k for FS2 file system on SRAMas documents suggest) my program crashes with messages which are not always same
like unexpected interrupt file: line 0
orunexpected interrupt file: line 360
or Bad packet type 0ffffff98 subtype:020
Mayexperts tell me why i have this problem, please.
Regards
Alain
------
Reply by ●January 9, 20042004-01-09
Sounds like you are getting low on xmem. I see the problem if the
TCP/IP stack runs out of xmem RAM, it will trash root RAM or the stack
and cause problems like this.
You might need to check xavail() after sock_init and sockets are
opened. I seem to remember that it still needed 4k or so free.
You can change the number of socket buffers and buffer sizes. I do an
xavail() before sock_init an then later when all socets are open. That
will let you know how much it needs.
TCP/IP stack runs out of xmem RAM, it will trash root RAM or the stack
and cause problems like this.
You might need to check xavail() after sock_init and sockets are
opened. I seem to remember that it still needed 4k or so free.
You can change the number of socket buffers and buffer sizes. I do an
xavail() before sock_init an then later when all socets are open. That
will let you know how much it needs.
