PDA

View Full Version : Periodic System Lockup


GabeRC1717
01-20-2009, 07:50 PM
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?

gvarndell
01-20-2009, 08:17 PM
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.

GabeRC1717
01-20-2009, 10:25 PM
We looked into doing that but what we saw was the it was only available when debugging a custom kernel image. Is there any way to do it with our project and the WPI provided image?

gvarndell
01-21-2009, 05:31 AM
We looked into doing that but what we saw was the it was only available when debugging a custom kernel image. Is there any way to do it with our project and the WPI provided image?

I almost never have a cRIO to work with.
I had one for a day last week and verified that System viewer worked.
Not sure how you came to the conclusion that you couldn't use it with the provided kernel image, but you can.
It's a great tool, use it.