Debugging C++ code in Windriver

[mfalk]

We've been having sporadic issues with all sorts of random issues from CAN programming to holonomic drive modes and everything in between. For our programmers, the only way that we've been able to test anything has been to build, deploy, fiddle with the robot, change the code, build again, deploy again, etc.

How exactly can we go about testing this while viewing console output and detailed errors?

Our current crisis is that when we deploy code from Windriver the DS still reads "No Code". I've made sure that all of the IP settings are correct. I can ping the crio, I can ftp into the crio, but I have no idea what I'm looking for. Being able to see more detailed errors than "no code" might help us figure this out.

Thanks in advance for any assistance.

[Alan Anderson]

You have two options for viewing console output. Either connect a terminal to the cRIO's serial port, or use NetConsole. Those should work whether you're running interactively or deploying code persistently.

[masoug]

Did you reimage the cRIO with the new image and new version of WPILib?

Chances are, the errors are from undefined symbols.

[mfalk]

@Alan:
We'd probably be better off using Netconsole since we're using a serial-to-CAN configuration. Is there any thread or tutorial explaining how to use Netconsole that you know of?

@masoug:
The crio is at version .28 and I think that we're up-to-date on WPIlib but I'll check. What do you mean by "Undefined symbols"?

[masoug]

Originally Posted by mfalk

@masoug:
The crio is at version .28 and I think that we're up-to-date on WPIlib but I'll check. What do you mean by "Undefined symbols"?

I get these errors referring the the WPILib symbols when the WPILib.a library is the wrong version with the cRIO. I am not too sure about the whole linking process, but my hypothesis is that the FRC_UserProgram.out links with other libraries upon runtime, and when the symbols don't match, the library fails to load.

I may be wrong though...

[Alan Anderson]

Originally Posted by mfalk

Is there any thread or tutorial explaining how to use Netconsole that you know of?

Try the WPI FAQ entry on NetConsole.

[Dave Scheck]

Originally Posted by mfalk

Our current crisis is that when we deploy code from Windriver the DS still reads "No Code". I've made sure that all of the IP settings are correct. I can ping the crio, I can ftp into the crio, but I have no idea what I'm looking for. Being able to see more detailed errors than "no code" might help us figure this out.

I'm assuming that by "Deploy Code" you're referring to going to the FIRST menu and using the deploy option. If that's the case, you need to power cycle the robot for it to take effect. The deployed executable is only ever started on the initial boot.

This is obviously a pain when doing tweak debugging. Rather than use that method, you should try running your program out of memory rather than flash. Check out page 12 of this document. While it shows how to set up the debugger, the same setup will allow you to run out of memory without actually attaching the debugger. This will save you a ton of time. Once set up, this is done by clicking the green Run arrow on the tool bar (might have to use the little submenu on the button to select the right deployment type)

When you want to use this option, be sure to do a FIRST->Undeploy and reset the robot so that there isn't anything running .

A couple of warnings
1. Make sure that you correctly delete any memory that you create in the appropriate destructors. If you don't, you will leak when you re-run your code and will eventually run out of memory if the leak is bad enough.
2. Be sure to deploy with FIRST->Deploy when you're done debugging. If you don't, the robot will have no code on it when you power cycle it. Running the code out of memory means that it isn't persistent across a reset.
3. Be very careful if you're using a debugger and breakpoints. If you pause your program, your speed controllers might be latched with the last value they received. This will cause a runaway robot which is bad (even worse if it's on an arm or something that could destroy itself).

Good luck

[Dave Scheck]

To answer the second part of your question about the console. In the left sidebar you should see the tree that shows what's running on your target (see page 7 of the document I referenced above). I'm writing this from memory so the exact menus might be slightly different. Right click on the entry for VxWorks... go to Target Tools -> Target Console. Any printf that you put in your code (don't forget to #include <stdio.h>) will show up in this console. This is extremely useful in debugging.

If you lose connection with your robot, you will need to reopen this console.