Help Requested - "Fatal Task-Level Kernel Exception"

[Travis Hoffman]

Keeping in mind I am not an experienced C++ programmer....

I have recently been having issues where, upon startup, when watching NetConsole, the robot will report the errors shown in the attached screenshot...the key statement seemingly is "fatal task-level kernel exception". Sounds pretty bad, no?

The Driver Station is communicating with the robot throughout...I can enable/disable...but there is no response from the pump, motors, etc.

When the robot does avoid reporting this error, the robot seems to perform just fine.

I would appreciate it if someone would help me figure out where the problem lies. If you request debug information or other specifics, you will likely have to provide instructions on how to get me to produce that info - I am not very familiar with the debugging environment of WindRiver (and yes, I've reviewed the FIRSTForge documents Brad Miller provided).

I will email code to anyone knowledgeable enough to review it and help me decipher and repair the root cause of this problem.

I am running the latest version of WPILib, v28 of the firmware, the v3.2 LabVIEW update, and the latest Driver Station.

Thanks in advance.

[byteit101]

You say labview 3.2, but the screenshot shows you are using C++, no need to update labview

anhow, the data access exception (which leads to the fatal error) is caused by a pointer error, which are nasty, often hard to find errors due to memory alotment. I try to avoid pointers where they are not needed, there are none in our 2011 code. Try replacing all the pointers with stack variables or references.
From

type *name = new type()
name->member

to

type name = type()
name.member

[Radical Pi]

Looking at the screenshot, it appears that you are referencing a NULL pointer somewhere within the constructor for your robot classes. If you're having trouble tracking it down, something I occasionally do is place printfs in key places in the code. If it appears on the screen at all, you can forget about the area above the printf. Make sure to comment them out later though.

[Travis Hoffman]

Thanks to both of you who've replied.

Originally Posted by byteit101

You say labview 3.2, but the screenshot shows you are using C++, no need to update labview

I update everything!

anhow, the data access exception (which leads to the fatal error) is caused by a pointer error, which are nasty, often hard to find errors due to memory alotment. I try to avoid pointers where they are not needed, there are none in our 2011 code. Try replacing all the pointers with stack variables or references.
From

type *name = new type()
name->member

to

type name = type()
name.member

I *might* have found the problem in my robot class constructor, per Radical Pi's suggestion. The code in question did use the "->" to call members of a custom PID class though.

I use one of the 2009 control system beta tester teams' code projects as the basis for my code. They use pointers all over the place, and I've not had any issue with the code in this manner until the other day.

I'll keep checking tomorrow to see if the problem returns.

[Travis Hoffman]

OK next fun issue for the practice robot. I believe the one stated earlier has been resolved.

This next one is very puzzling.

All my speed controllers and pneumatic devices work fine except one - the one (Victor) that controls the arm motor.

• Symptom - manually attempting to move the arm up with one of the gamepad joysticks causes the arm to jerk upward quickly.

• Symptom - manually attempting to move the arm down with the same joystick causes a rapid flashing of the yellow Victor LED, and the Victor makes a rapid clicking noise. If the pump happens to be running when this happens, the pump stutters in step with this flashing when this happens (sounds like some kind of short).

• Originally the controller was a black Jag. Now it's a Victor. Does the same thing.
• Found the arm Vic's PWM cable's male pins were coming loose from their housing. Changed the cable. Still does the same thing.
• Moved the Vic from PWM7 to PWM8, with corresponding code change. The problem moved with it.
• Loaded v27 of the firmware - same thing. Loaded v28 back in - same thing.
• Loaded a known good version of code from a few days back - same thing.
• Restarted Driver Station - same thing.
• Replugged control gamepad - same thing.
• Frame is isolated from ground.

This sounds like some kind of hardware issue, but I sure as heck am stumped. Any thoughts? All ideas appreciated.

I'm going to check the wiring from the Vic to the motor for some kind of short or anomaly....

[Mike Betts]

Travis,

Is the motor a 775?

Mike

[Travis Hoffman]

Originally Posted by Mike Betts

Travis,

Is the motor a 775?

Mike

RS-550, freshly installed.

This motor was tested fine, on robot, just prior to this anomaly and worked swimmingly. It still moves in the upward direction really fast whenever I move the stick anywhere north of neutral. The Vic seems to just output max voltage regardless of input. When I move the stick down, even though the variable in the code is changing per NetConsole, there is no movement out of the arm, but the Vic clicks real fast. If the pump is running, it stutters to the same beat as the clicking. Thing is, I can still drive while the clicking is going on - drive motors are not seemingly affected.

I can't see the digital sidecar being the issue - all other outputs and inputs are working fine, and the problem moved to PWM8 when I moved the cable and changed the code.

I will say that right before the problem occurred, I changed one constant in the code and redownloaded, then poof. I do not know if this is a coincidence or code-related. I won't rule out this problem being code related

Is it possible for the WPILib source code C++ stuff I can't change to be corrupted, while my custom code is still good?

Maybe I'll reinstall the latest WPILib update and do a clean recompile.

At this point, I'm completely stumped.

[Mike Betts]

Travis,

You might want to focus on the compressor. When it is intermittent, is the DSC LED for that relay channel steady or intermittent? If the former, then software is probably not at fault. If the latter, then the DSC is being commanded to intermittently run the compressor by the CRIO and software is highly suspected.

If the above indicates software is OK, you might want to temporarily disconnect the spike to the compressor. Does the 550 operate smoothly? If so, you may have a circular path somehow in your frame...

Good Luck,

Mike

[Matt Krass]

When you swapped out the Jaguar for the Victor, did you change the code? The Jaguar PWMs update faster and might be causing the Victor to trip over itself trying to keep up.

[Travis Hoffman]

Originally Posted by Matt Krass

When you swapped out the Jaguar for the Victor, did you change the code? The Jaguar PWMs update faster and might be causing the Victor to trip over itself trying to keep up.

Sorry I didn't respond sooner to you guys - I was very busy all day prepping for Pittsburgh.

Yes, I changed the code when I switched the controller. It turns out the problem was tracked to a bad 10 AWG zip cord power cable running to the controller.

I am not a fan of large-gauge zip cord (red/black wires joined together into a single cord). It is far too easy to tear the insulation during lead separation and expose the copper in those things. There was a small tear in both of them that was causing an intermittent short. I swapped out the cable to independent red and black wires, and the problem disappeared. I enjoyed hacking the zip cord into little pieces before disposing of it!

For smaller gauges like 18, zip cord is great - the two wires readily separate. For large gauges, I'm going with indivdual wires from now on.

Thanks to all who suggested ideas.