Debugging RTOS problems in embedded systems

Dear All,
Most of us involved with RTOS projects in embedded systems need to
encounter at one point or other problems pertaining to real time
situations:
1)DeadLocks
2)Racing conditions
3)Problems related to re-entrancy.
4)Problems related with priority setting

What are the general debugging techniques used to uncover problems
related to above mentioned?I have earlier worked with windriver
Tornado and Vxworks,and I got a tool called Windview which will show
graphicaly the status of tasks as well as some analysis on timing.One
can get an idea,if not exact,on what would have gone wrong in it.
But some of the OS are propreitory and further custom OS provided by
chip vendors(as is the case in my current product).These OS dont have
any tools like windview for debugging.I would like to know what can be
done to perform debugging?Clearly adding printf wont help in such
situations.

I would also like to learn building tools on my own to debug such
situations.

Can of you provide your suggestions or point me to a link ?

Looking farward for your replies and advanced thanks for the same,

Regards,
s.subbarayan

P.S:I have crossposted the same query in comp.realtime to attract more
inputs.

ssubbarayan wrote:
> 
... snip ...
> 
> P.S:I have crossposted the same query in comp.realtime to attract
> more inputs.

No you haven't.  You have multiposted, and failed to set
follow-ups, both of which are sins.

-- 
 <http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
 <http://www.securityfocus.com/columnists/423>
 <http://www.aaxnet.com/editor/edit043.html>
                        cbfalconer at maineline dot net


-- 
Posted via a free Usenet account from http://www.teranews.com

"ssubbarayan" <ssubba@gmail.com> wrote in message 
news:1183354917.089396.21010@o11g2000prd.googlegroups.com...
> Dear All,
> Most of us involved with RTOS projects in embedded systems need to
> encounter at one point or other problems pertaining to real time
> situations:
> 1)DeadLocks
> 2)Racing conditions
> 3)Problems related to re-entrancy.
> 4)Problems related with priority setting
>
> What are the general debugging techniques used to uncover problems
> related to above mentioned?I have earlier worked with windriver
> Tornado and Vxworks,and I got a tool called Windview which will show
> graphicaly the status of tasks as well as some analysis on timing.One
> can get an idea,if not exact,on what would have gone wrong in it.
> But some of the OS are propreitory and further custom OS provided by
> chip vendors(as is the case in my current product).These OS dont have
> any tools like windview for debugging.I would like to know what can be
> done to perform debugging?Clearly adding printf wont help in such
> situations.
>
> I would also like to learn building tools on my own to debug such
> situations.
>
> Can of you provide your suggestions or point me to a link ?
>
> Looking farward for your replies and advanced thanks for the same,
>
> Regards,
> s.subbarayan
>
> P.S:I have crossposted the same query in comp.realtime to attract more
> inputs.
>
As you have already noticed the answer is usually RTOS dependent.  Some RTOS 
have better tools available than others.
Micrium www.micrium.com has recently introduced a general purpose tool 
uC-Probe that may help.  It is supposed to be OS independent.  It is an 
application that communicates with your program and feeds data to a PC.  You 
run your elf file through their product and it learns about all the 
variables in your code.  You can then examine variables in real time.  It 
works directly through some jtag devices or can get the data through a small 
driver you add to your code.

Scott

On Jul 2, 1:41 am, ssubbarayan <ssu...@gmail.com> wrote:
> Dear All,
> Most of us involved with RTOS projects in embedded systems need to
> encounter at one point or other problems pertaining to real time
> situations:
> 1)DeadLocks
> 2)Racing conditions
> 3)Problems related to re-entrancy.
> 4)Problems related with priority setting
>
> What are the general debugging techniques used to uncover problems
> related to above mentioned?I have earlier worked with windriver
> Tornado and Vxworks,and I got a tool called Windview which will show
> graphicaly the status of tasks as well as some analysis on timing.One
> can get an idea,if not exact,on what would have gone wrong in it.
> But some of the OS are propreitory and further custom OS provided by
> chip vendors(as is the case in my current product).These OS dont have
> any tools like windview for debugging.I would like to know what can be
> done to perform debugging?Clearly adding printf wont help in such
> situations.
>
> I would also like to learn building tools on my own to debug such
> situations.
>
> Can of you provide your suggestions or point me to a link ?
>
> Looking farward for your replies and advanced thanks for the same,
>
> Regards,
> s.subbarayan
>
> P.S:I have crossposted the same query in comp.realtime to attract more
> inputs.

Allocate a huge block of RAM for a circular buffer.
At each critical section you suspect, or for each thread, write a
unique value to the next location in the memory block.
When you break on the error, inspect the block of RAM to see who did
or didn't do what it was supposed to.

On 2007-07-02, ssubbarayan <ssubba@gmail.com> wrote:
> Dear All,
> Most of us involved with RTOS projects in embedded systems need to
> encounter at one point or other problems pertaining to real time
> situations:
> 1)DeadLocks
> 2)Racing conditions
> 3)Problems related to re-entrancy.
> 4)Problems related with priority setting
>
> What are the general debugging techniques used to uncover
> problems related to above mentioned?

Look at the symptoms and the source code and think.

Seriously.

-- 
Grant Edwards                   grante             Yow! I'm in direct contact
                                  at               with many advanced fun
                               visi.com            CONCEPTS.

ssubbarayan wrote:

> Dear All,
> Most of us involved with RTOS projects in embedded systems need to
> encounter at one point or other problems pertaining to real time
> situations:
> 1)DeadLocks
> 2)Racing conditions
> 3)Problems related to re-entrancy.
> 4)Problems related with priority setting
> 
> What are the general debugging techniques used to uncover problems
> related to above mentioned?

There are the only two debugging tools for everything: the smart head 
and the assiduous ass. Nothing can help until you know what are you 
doing. And if you know how the stuff works, there should not be much of 
a need to debug it.


I have earlier worked with windriver
> Tornado and Vxworks,and I got a tool called Windview which will show
> graphicaly the status of tasks as well as some analysis on timing.

Those tools are no more then the glossy toys for the beginners. A debug 
printouts in the critical places and toggling LEDs is sufficient to 
verify the operation.


VLV

ssubbarayan wrote:

> Dear All,
> Most of us involved with RTOS projects in embedded systems need to
> encounter at one point or other problems pertaining to real time
> situations:
> 1)DeadLocks
> 2)Racing conditions
> 3)Problems related to re-entrancy.
> 4)Problems related with priority setting
> 

Amongst the many good texts on O/S design and theory,
I recommend LaBrosse's "uC/OS-II, The RealTime Kernel";
it includes example scenarios and debugging suggestions
in generalized form that pertain to your stated issues.

Regards,

Michael

In article <ZE8ii.9840$c06.2524@newssvr22.news.prodigy.net>, 
antispam_bogus@hotmail.com says...

> ssubbarayan wrote:
 
> I have earlier worked with windriver
> > Tornado and Vxworks,and I got a tool called Windview which will show
> > graphicaly the status of tasks as well as some analysis on timing.
> 
> Those tools are no more then the glossy toys for the beginners. A debug 
> printouts in the critical places and toggling LEDs is sufficient to 
> verify the operation.

Yes, and I can remove an appendix with a bread knife and a pair of 
pliers, but that doesn't make those the best tools for the job.

--Gene

Op Mon, 02 Jul 2007 07:41:57 +0200 schreef ssubbarayan <ssubba@gmail.com>:
> Most of us involved with RTOS projects in embedded systems need to
> encounter at one point or other problems pertaining to real time
> situations:
> 1)DeadLocks

No. Only possible in the classic and error-prone concept of 'shared  
resources'.

> 2)Racing conditions

No. Only possible in the classic and error-prone concept of 'non-exclusive  
ownership of data'.

> 3)Problems related to re-entrancy.

No. Only possible in the classic and error-prone concept of 'non-readonly  
data that belongs to all processes'.

> 4)Problems related with priority setting
Never heard of this.

> What are the general debugging techniques used to uncover problems
> related to above mentioned?

If you didn't find these problems earlier, then the problem lies in the  
design phase.





-- 
Gemaakt met Opera's revolutionaire e-mailprogramma:  
http://www.opera.com/mail/

Boudewijn Dijkstra wrote:

>> 4)Problems related with priority setting
> Never heard of this.
> 
Search "priority inversion". Most famously it almost took out
one of the Mars landers - even tho the problem had been known
for decades.