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?
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.
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?
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.
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.
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:
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)?
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
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
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
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.
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.
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.
This:
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.
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.
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 arget\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
mppc C:\WindRiver\vxworks-6.3 arget\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
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.
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.