View Single Post
  #2   Spotlight this post!  
Unread 20-01-2009, 21:17
gvarndell's Avatar
gvarndell gvarndell is offline
Software Engineer
AKA: Addi's and Georgie's Dad
FRC #1629 (GaCo)
Team Role: Parent
 
Join Date: Jan 2009
Rookie Year: 2008
Location: Grantsville, Maryland
Posts: 350
gvarndell has a reputation beyond reputegvarndell has a reputation beyond reputegvarndell has a reputation beyond reputegvarndell has a reputation beyond reputegvarndell has a reputation beyond reputegvarndell has a reputation beyond reputegvarndell has a reputation beyond reputegvarndell has a reputation beyond reputegvarndell has a reputation beyond reputegvarndell has a reputation beyond reputegvarndell has a reputation beyond repute
Re: Periodic System Lockup

Quote:
Originally Posted by GabeRC1717 View Post
We are using the C/C++ development environment, this is the problem we have been having. At seemingly random intervals, but with increasing frequency, all of our tasks stop running, whatever motors they are controlling continue to move, and nothing happens for approximately one second. Our concern is that a higher priority task that is part of the system is taking over. One interesting thing that we noticed is that the data light on the camera turns solid while this is happening, we also get no console out or packets from the driver station. Has anyone else had a problem like this?
I'm going to suggest that you explore what Wind River's System Viewer can do to help you with this. Use Workbench help to read about it. It's not that hard to use, not nearly as hard as trying to guess what's going on, but it will take some reading.
In a nutshell, vxWorks has built-in event recording that can be enabled.
The event log is stored in RAM and fetched by the host computer -- either on demand or when the event log fills.
The event log is then graphically displayed -- it looks a little like a logic analyzer display. What you see on the display is task context switches and interrupts entries and exits.
In this case, you probably want to configure the log buffer as a circular buffer and size it such that it can store maybe 20 seconds of data before running over itself.
How big is that? Don't know, but there's plenty of RAM on the cRIO.
So you've read about System Viewer, you've configured it to log context switches, and you've empirically determined a log buffer size that equates to roughly 20 seconds of logging, now comes the hard part.
Wait for this anomaly to occur, wait for it to pass, and then quickly upload the viewer event log.
If you do all that, it should lead you right to the problem - -even if it's not your code.
Reply With Quote