No Robot Code error

[CFrank13]

For the upcoming fall classic FRC competition, our team did our first power-up check today. The test ran smoothly and everything worked fine. After turning off the robot and then turning it back on, without re-downloading code or changing anything on the robot, the driver station displayed "No Robot Code" and would not run. This program is the exact code that we used last FRC season, and was confirmed to be operational. Because it worked today and then suddenly stopped working without any apparent cause, this is a list of troubleshooting solutions we have tried so far:

Software Tests:
-Run full program (which was just working a moment ago)
-Run program with complex/potentially breakable functions commented out
-Run empty workspace (hello world)
-Run code from previous years (2012, 2013)
-Check Driver Station Launch Viewer
-Re-Install latest FRC WindRiver C++ update
-Re-Install latest WPILib update
-Re-Install latest National Instruments update

Firmware Tests:
-Run code on new cRIO
-Re-image cRIO with latest image (2014)

Hardware Tests:
-Unplug/replug ethernet cable
-Use new ethernet cable
-Run code using wireless connection
-Turn robot off then on
-Ensure battery is fully charged
-Check wiring system for breakages/disconnections
-Redo wiring system (just to be sure)

...

Any suggestions on what else we can try or what the problem may be?

[BleakRNS]

-Run code from previous years (2012, 2013)
-Run program with complex/potentially breakable functions commented out

Did these work? If the first one did and the second one didn't, have you tried copying the code to a new file and deploying that?

Hardware Tests:
-Unplug/replug ethernet cable
-Use new ethernet cable
-Run code using wireless connection
-Turn robot off then on
-Ensure battery is fully charged
-Check wiring system for breakages/disconnections
-Redo wiring system (just to be sure)

I'm not seeing "use a different computer to deploy" here. It's not a likely solution, but weirder things have happened.

[FrankJ]

It is probably something silly. These things usually are.
On the DS setup tab do you have the right language selected? (not sure if this really matters) On the DS diagnostic tab, Do you have robot coms? Does it have the Crio version? right side of page. If it has these things then your com path to the crio is probably good. I would start looking for odd settings in your compiler tool chain.

[CFrank13]

Originally Posted by BleakRNS

Did these work? If the first one did and the second one didn't, have you tried copying the code to a new file and deploying that?



I'm not seeing "use a different computer to deploy" here. It's not a likely solution, but weirder things have happened.

Unfortunately neither of those worked when we tried them. We just tried deploying from an older computer (we just got new ones) and it yielded the same result. We also tried deploying the code from WindRiver as well as from FileZilla. Nothing has worked so far. Thank you for the advice.

[BleakRNS]

Originally Posted by CFrank13

Unfortunately neither of those worked when we tried them. We just tried deploying from an older computer (we just got new ones) and it yielded the same result. We also tried deploying the code from WindRiver as well as from FileZilla. Nothing has worked so far. Thank you for the advice.

Check the placement of the modules on the cRIO and re-re-check that all wires going into and coming out of it are totally secured. Check the lights, too. Also, if you have another, try deploying it onto a different cRIO because at this point it seems like it's a robot-side problem.

[Joe Ross]

What does netconsole report, both in the working cases and the failed cases?

[CFrank13]

Originally Posted by Joe Ross

What does netconsole report, both in the working cases and the failed cases?

I am not entirely sure what the netconsole is. Are you referring to the driver station? If that is the case, then this is Warning it is reporting:

Warning <Code> 44002 occurred at Ping Results: link-bad, DS radio(.4)-bad, robot radio(.1)-GOOD, cRIO(.2)-GOOD, FMS-bad
Driver Station
<time>9/20/2014 1:07:03 PM<unique#>9

[Joe Ross]

Netconsole: http://wpilib.screenstepslive.com/s/3120/m/8851

[CFrank13]

Originally Posted by Joe Ross

Netconsole: http://wpilib.screenstepslive.com/s/3120/m/8851

Oh, thank you for clarifying. I enabled the net console, and here is the report on startup (For some reason I am unable to simply copy and paste the report, so I just took a screenshot)

http://imgur.com/DN9sAGG

UPDATE-1: We discovered that WPILib was the problem, and that it was not installed correctly. On a different laptop that WPILib was not installed on yet we correctly installed it. Now the NetConsole is giving us the same errors plus more. From the look of it, it is possible that we are either including our WPILib incorrectly in code or that we are defining our variables wrong. Here is the NetConsole report:

http://imgur.com/CcOtNfl

UPDATE-2: We fixed the "Relocation does not fit in 24-bit" problem through a different thread by adding in -mlongcall into our build options. Now the only remaining issue is the WPILib. Here is the new NetConsole report:

http://imgur.com/w1gRPUs

[CFrank13]

Here is a link to our code in case there is something we are doing anything incorrectly:

GitHub Main Page

Issue on Github

[Joe Ross]

Does it work if you create a brand new project and don't add any extra code?

Commit 08a2bdb seems to have messed with a lot of project settings (along with lots of other things).

[CFrank13]

Originally Posted by Joe Ross

Does it work if you create a brand new project and don't add any extra code?

Commit 08a2bdb seems to have messed with a lot of project settings (along with lots of other things).

As it stands now, the cRIO is able to load any program that does not use WPILib in code. Empty workspaces are fine. However, we are still unable to figure out why objects made from the WPILib (i.e. Talon) are registered as "undefined symbols" in the net console. The code compiles/builds without any errors, it is the cRIO that will not load the FRC_UserProgram.out file if it include WPILib.

[AustinSchuh]

Originally Posted by CFrank13

As it stands now, the cRIO is able to load any program that does not use WPILib in code. Empty workspaces are fine. However, we are still unable to figure out why objects made from the WPILib (i.e. Talon) are registered as "undefined symbols" in the net console. The code compiles/builds without any errors, it is the cRIO that will not load the FRC_UserProgram.out file if it include WPILib.

https://github.com/Robodox-599/2014_...03gnu/Makefile

Reading the autogenerated Makefile, it looks like WPILib isn't being linked in. WPILib is a static library.

[CFrank13]

Originally Posted by AustinSchuh

https://github.com/Robodox-599/2014_...03gnu/Makefile

Reading the autogenerated Makefile, it looks like WPILib isn't being linked in. WPILib is a static library.

Oh. That is fantastic, we have been trying to decipher this issue for days! Could you please explain how to fix this issue?

[AustinSchuh]

Originally Posted by CFrank13

Oh. That is fantastic, we have been trying to decipher this issue for days! Could you please explain how to fix this issue?

Unfortunately, I can't... I have been using custom linux based build environments and unsupported GCC cross compilers that I built myself for years. Hopefully someone else will be able to take my diagnostic and help you figure out what to do with it with WindRiver...

Conceptually, you want to add WPILib.a to the link command. Not sure the magic key strokes to do that.

My guess is that the following diff to your .wrproject did it.

-            <listAttribute key="BLD::Info|Libs|PPC32diab">
-                <stringAttribute value="$(WIND_BASE)/target/lib/WPILib.a"/>
-            </listAttribute>
-            <listAttribute key="BLD::Info|Libs|PPC603gnu">
-                <stringAttribute value="$(WIND_BASE)/target/lib/WPILib.a"/>
-            </listAttribute>