[Greg McKaskle]

The trace for auto, teleOp, and Disabled are reported as your code responds to the auto, teleOp, or disabled state of the control packet.

Apparently, as Thad was saying, that thread was no longer making that call. This could be because of logic, sleeps, infinite loops, etc.

In the philomath log, the CPU usage drops to background levels when this happens. Your disabled code CPU usage is 50%. Your auto was 67% then ~%51. TeleOp was 66%. Then it drops to 15% when the traces stop. About 10 seconds later, the driver station starts to request code restarts and finally a reboot. The roboRIO and user process come back up and go back to that state of low CPU usage. More code restart requests, and another roboRIO reboot request. When the code finally came back during disabled, the CPU usage looks like it matches the mode.

During TeleOp, my guess is that the code was crashing or locked waiting for a mutex that was never released.

The Portland logs show the same Disabled - 50%, Auto 61% and then 51%. But when teleOp starts, that doesn't change like the other log file. It appears that the code doesn't call the trace instrumented function, and remains in auto. The CPU stays at 51% until the code restart. This is quite different from he other log since it wasn't tracing, but seemed to still be running auto.

When the code comes back from the code restart request, the CPU usage is at 70%, but I don't see any indication that the mode function was called. The roroRIO was then rebooted, and when it comes back up the roboRIO is at 70% and the getMode is being called normally.

At this point, there are no messages in the logs that definitively log a crash of a C++ program or Java program. I hope we can improve that. Hopefully this additional info helps you identify anything that may be contributing to this.

Greg McKaskle