Cannot get Code to Download to cRIO

[greekgod8591]

Hey,
We're currently trying to get our code to dl to the cRIO unsuccessfully.

Here's the situation:
Running WindRiver
Update 3 installed and cRIO flashed
Code completely compiled and not using std c lib

We turn on the control system, undeploy, reset, download, reset and it reads no code, yet in WindRiver it shows the file as downloading. What could be happening here?

[Windward]

We're getting the same error.
cRIO fully updated, as is driver station.
C++ code compiles, downloads.
Battery: No Code.
The funny thing is that when we download the cRIO Image in (reformat the cRIO using v11) and we reset it, the default code in the image works fine. Everything works as normal.
Any help would be great.

[greekgod8591]

Yes we are again same in the other issues you discussed.

Are all your IPs correct? Ours are correct and we can ping all of them. Let's brainstorm some possibly issues.
Could we be sending the wrong outfile? Are there any options other than the default out. Did you try doing a clean build of the project?

[csshakka]

Were experiencing same issue. Seems like no matter what we do, the drive station reads no code and only default will work. I can see the processes running on the crio so i know it is working, but cannot my code on.

When i get to robotics tomorrow, i was going to try making a new example project and just copying some simple code to work, using the default names to see if something went awry renaming files.

[Johno]

Check you downloader preferences under Window preferences to make sure that you are downloading the correct .out file.

Running the install program is not the only step required to flash the cRIO. We had a similar problem until we remembered to run the cRIO imaging tool to actually imprint the image. Instructions for this are in the 5 chapter Control System Manual.

[gm342]

342 is also having the same problem. Our problem started yesterday too. We are not getting any gcc error messages on our code. We can download the code to the cRIO with FIRST->Download but on reboot, the DS reads No code.

When we attempt to run last launched or debug last launched we get Symbol errors. The unresolved symbols have varied throughout the course of today. These include: Joystick::Joystick(int), Solenoid::Solenoid(int), Solenoid::Solenoid(int, int), DigitalInput::DigitalInput(int), Victor::Victor(int), Compressor::Compressor(int, int). As best I can tell, all of these are acceptable constructors from WPILib. And we are successfully linking this library in on the computer as we're not getting any output errors from gcc or the linker.

We have not changed any settings in Eclipse/Windriver. We are also running on the latest cRIO image (v11), FRC Update (3.0 and 3.0a tried), and DS (previous image and the new LCD custom text 2009-01-22c1).

No success yet to report on this problem. :ahh:

[marccenter]

Yeah,
Same problem for my code. I created two files from the two WPI library files Robotdrive (*.cpp and *.h). I appended every Robotdrive construct and member with RL to make a unique name. I added these two new files to a known good project and built (clean)with no errors. Next, undeploy, reset, download and No code error.

This is frustrating. After verifying that I can run the undeploy, reset, download sequence with simplerobot.out (provided with version 3.0) with my laptop, I switched to our new output file *.out and nothing (No code error).

At one point I introduced a simple typo error in the two new files and yep, the compiler found the typo.

Thoughts anyone on what to do next? Works with *.out from library but not with ever so slightly modified version of Wpilib files Robotdrive (*.cpp and *.h)?

[Sentient]

I don't know if this will help, but I made a quick video of how to download the code to your bot: http://www.youtube.com/watch?v=JfBfPC4VftM

[Kruuzr]

This problem often has NOTHING to do with the downloading process. One wierd aspect of VxWorks/PowerPC compiler-linker is that if you make a call to a function that does not exist, the compiler/linker will not give an error. What happens is that it fails to load the module (your code) which results in a No Code scenario. We've run into this a few times and had to waste a lot of time tracking down what function(s) were missing.

Good Luck

Steve C

[marccenter]

One weird aspect of VxWorks/PowerPC compiler-linker is that if you make a call to a function that does not exist, the compiler/linker will not give an error.

Wow! Seems like this shouldn't happen. Is there a software switch that needs to be enabled in order to turn on the error indicator in the default configuration version we have been given as examples?

[Kruuzr]

One weird aspect of VxWorks/PowerPC compiler-linker is that if you make a call to a function that does not exist, the compiler/linker will not give an error.

Wow! Seems like this shouldn't happen. Is there a software switch that needs to be enabled in order to turn on the error indicator in the default configuration version we have been given as examples?

I don't believe so. I actually ran into this at work (BAE Systems) and it was explained to me that it just expects the functions to be supplied in a different module. I guess that's the expected normal operation. It just makes life terribly difficult when you don't know what's missing. On the other hand, just knowing that can lead you to look in different directions than if you thought you weren't downloading correctly.

If you are using version control, try going back to an older version till you find one that works. Then track the changes. That's what we had to do.

Steve C

[gm342]

I still think that there is something more going on here. We troubleshooted this over the weekend quite a bit (still no full solution). We did try going through old code revisions and it did not solve the problem. We had cRIO symbol errors for all of the above mentioned symbols and then the list suddenly decreased to just the Solenoid constructors. After commenting out the solenoid constructor code, everything worked fine. Place the code back in and trouble. I checked Windriver and Eclipse settings files, and they too also were unchanged since the beginning of the season.

I am going to continue with trying to track this down.

[Sentient]

Did you try making a physical connection to the debug and reading the output in Hyperterminal? If you do have a run-time error, it will show up here.

[computerish]

EDIT: Everything was working fine and then suddenly we have the No Code error again. I don't understand it.

Check and double check your IP setting on your computer!

IP: 10.XX.XX.6
Subnet: 255.255.255.0

That solved it for us! Even if you "know" they are right, check it again.

[Analog]

This:

Did you try making a physical connection to the debug and reading the output in Hyperterminal? If you do have a run-time error, it will show up here.

[greekgod8591]

Hey guys,
I think we've made some progress. We have no gotten the code to download to the cRIO or at least we're under the impression that this is happening. Unfortunately we cannot get the code to execute/get anything useful to happen. Here's a list of what we did:
Problem 1: Stupidly connected the router to the internet
Solution: Disconnect from internet
Problem 2: Your IPs are not set correctly
Solution: In the control system documentation there is a nice little diagram with all the IPs. We just double checked everything and pinged to ensure they were there.
Problem 3: Project did not build correctly
Solution: Try going into WR and selecting Project->clean and rebuild everything
Problem 4: Incorrect download file
Solution: Window->Preferences and check team number and .out file
Problem 5: Do not have proper remote server set
Solution: Look in the FRC documentation, and reset your server settings, then try and connect to the robot.

So we did all of that and we now get the DS to show a voltage which I'm assuming means that we at least have the code file onto the cRIO. Unfortunately it doesn't do anything. We can also see it is there through looking at the remote server thing. We tried to run in debug mode and nothing happened, when we set debug points it throws crazy errors. We've basically hit a wall, we don't know what else to try.

[JamesBrown]

Try loading the code via FTP with a program like FileZilla. I had similar problems to your's and managed to resolve them this way.

As a note if you choose this solution then make sure you rename your .out file FRC_UserProgram.out . The loader changes the name itself prior to loading so if you load manually you will need to rename the file manually, you can change the name of the file created in the WindRiver build options if you don't want to rename it every time.

[gm342]

I connected to the cRIO with a Serial cable. Our error message is no more revealing than the Windriver Eclipse Run Last Debug except for one important bit:

task 0xc1fc38 (t1) deleted: errno=1835009 (0x1c0001) status=1 (0x1)
Warning: module 0xc9ed18 (FRC_UserProgram.out) holds reference to undefined symb
ol _ZN8SolenoidC1Eii.
Warning: module 0xc9ed18 (FRC_UserProgram.out) holds reference to undefined symb
ol _ZN8SolenoidC1Ei.
(unloading partially loaded module FRC_UserProgram.out)

I used the nmppc tool (located in C:\WindRiver\gnu\3.4.4-vxworks-6.3\x86-win32\bin) to list all of the symbols in C:\WindRiver\vxworks-6.3\target\lib\WPILib.a This lists all of the symbols in this library. Here's the interesting bit:

000003c0 T _ZN8SolenoidC1Ej
00000690 T _ZN8SolenoidC1Ejj

The symbol names don't line up (compare i and ii to j and jj). Anyone had a problem similar to this or guess what might have caused it? I would be interested to hear if other teams with symbol problems (no code error) are seeing similar output.

If it helps, run C:\WindRiver\gnu\3.4.4-vxworks-6.3\x86-win32\bin\nmppc C:\WindRiver\vxworks-6.3\target\lib\WPILib.a > outfile at a command prompt (I use Windows Power Shell)

and then you can open a file named "outfile" in any text editor to see the horrendously long list of nmppc output

[Aaron S]

I got this error the day after I updated the cRIO and fixed it by downloading the default code and then downloading our code (which I cleaned up a bit by going back through it and making sure I had fixed everything that looked like it could mess up). Whenever you get the "No Code" error after you have successfully downloaded your compiled .out file, it means that there is something wrong with your code. If there was no connectivity to the cRIO from the DS, "No Comm" would be displayed.

[gm342]

It's been several days and I have not seen any replies to this thread from other teams with the No Code error.

Did your error get fixed? Did you feel like it did it on its own or you changed something?

Are you still having problems, but it doesn't appear to be the same one as we're having?

Have you run the nmppc tool at all to compare output?

Thanks teams in replying. The reason why I am pushing this quite a bit is that this bug could track down to an issue inside of the Windriver gcc build, and this could save a lot of teams future heartache to work it now.

[Aaron S]

Again, it's more likely to be in your code if you successfully downloaded the .out file to the cRIO. Try making a new project based off the SimpleTemplate example and just adding your .cpp / .h files to it, then compiling. That's what I and my team did which seems to have worked.

[gm342]

Your fix may be a workaround to this larger problem. What may have happened is that by moving your files in the build order you changed the ordering in memory and gcc got a lucky fix and worked around it.

I have also done the new project, but in our case it hasn't resolved the problem.

I would say we should push for a md5/sha1 checksum on the cRIO for the uploaded file to compare it with the computer's file to verify the copy integrity. I will try this tonight and see where it goes. However, copying the file multiple times should have fixed any possible bit error. It would be inconsistent to get this same error after multiple uploads.

Thanks for the feedback.

[computerish]

We did an md5 sum. The files are the exact same for us.

We have solved this problem many times by reimaging the cRIO, but it always comes back. (And the fix is always different.)

[ExarKun666]

Okay our team just went through this problem and I personally went and debugged, undeployed, updated, ect... continuously.
We were successful in fixing this, while one team member was fixing the chain, I jokingly just said "For fun let's just check the wiring just in case." We found at least four loose wires, we tightened them all down, turned on the bot, downloaded and then it worked. I might mention we did the download tethered, but it works now wirelessly too. Hope this is some help. :D

[computerish]

We fixed our problem. Turns out that the function powf() that we were using to calculate the distance of the target is undefined, even though it is include in the Math.h file. pow() seems to work fine, though.

[gm342]

Here is some additional input that may help teams.

We had:

#define UINT32 unsigned int

in one of our files. This is actually slightly different than the type defined in WPILib (even though it eventually resolves into an unsigned int). The compiler/linker could successfully resolve that two-level symbol, but when placed on the cRIO, the variable types were slightly different and so the symbols did not match up.

This is not an obvious problem, with no obvious error message given. So other teams may have encountered this in some form also.

And Windriver/Eclipse guys reading this... why do you filter out -pedantic from the g++ Makefile settings in Eclipse IDE? It is very useful, and may have even caught this error.

Thanks to everyone for their help and input. Figuring out problems like this will be very useful for a lessons learned on the new cRIO controller.