Cannot Deploy - "No Robot Code"

[silutang]

So we were having problems deploying code to a 4-slot cRIO.

We could run/debug code fine, but after every reset/power cycle we would have “No Robot Code” in the Driver Station because it was only run in temporary memory. And that’s fine; that’s expected behavior. The problem was after we try to deploy code inside WindRiver, reset the robot, Driver Station would still say “No Robot Code.” (Note we could successfully run AND deploy code (the same code) on an 8-slot cRIO.)

After reading many threads on CD, it seemed many other teams had the same problem. As suggested by these threads, we tried to FTP into the cRIO, manually move the .out file into ftp://10.te.am.2/ni-rt/system, and rename the file FRC_UserProgram.out. The DS still found No Robot Code on the 4-slot cRIO. The DS *did *find robot code on the 8-slot cRIO. We tried this several times. Results subsisted.

Then we reimaged both cRIOs with v52. After repeating the FTPing FRC_UserProgram.out procedure several times, the 8-slot cRIO was successful. The 4-slot was not.

Then we were out of ideas. So we tried to deploy a SimpleTemplate sample program from WindRiver. This time, the program successfully deployed onto the 4-slot cRIO. After rebooting, DS found robot code.
We found little reason for our actual C++ code to be causing the problem. So we suspected that something in the Build Properties of the WindRiver project was causing the problem. (Our original robot project was created from scratch, not from an existing sample project.)

We copied and pasted all of our .h and .ccp files from the original robot project into SimpleTemplate. The SimpleTemplate project was successfully deployed. So at this point we were almost certain it was something in the project properties that was causing the problem.

So we digged harder on CD. Indeed one poster mentioned appending “-mlongcall” after the “$(CC_ARCH_SPEC)”. This is inside Project Properties -> Build Properties -> Tools -> Tool Flags.

After doing this to the original robot project, it was still unable to be properly deployed to the 4-slot cRIO. The SimpleTemplate project could deploy, repeatably.

So we are out of ideas. Has anybody else had similar problems before? Help please?
Thank you!

[bvisness]

What kind of errors are you getting on your NetConsole? It sounds like the file must be there, but it for some reason doesn’t load correctly. I’m confident that the cRIO would at least try to load the FRC_UserProgram.out file.

[silutang]

The NetConsole read “Relocation value does not fit in 24 bits.”

[bvisness]

Google tells me that you should definitely make sure your build settings are correct, and -mlongcall seems to be a common solution to this problem.

We have no problems compiling and deploying to a 4-slot cRIO. I’ve attached screenshots of our build properties - hopefully you can find what’s different and make it work.

(In the last screenshot, the full text after CC_ARCH_SPEC is “-mcpu=603 -mstrict-align -mno-implicit-fp -mlongcall”)

[taichichuan]

Yes, you’ll need to add the -mlong_call build option. There’s a weirdness in the PPC architecture relating to the branch local (bl) instruction that dates back to the early 1990s. The bl instruction only supports jumps of 24-bits or less. The -mlong_call option uses address redirection through a 32-bit register to get beyond the 24-bit relocation issues.

The really weird thing is that the code would work if run as a kernel thread from the IDE, but not work if the code were deployed. That has to do with the way WRS loads code in the two different modes. In the deployed mode, the code is loaded down low and can be more than 24-bits (16MB) from the kernel which is loaded in high memory. Since the 4-slot cRio has more memory than the 8-slot, the kernel is further away from where the code is loaded when deployed and that increases the likelihood of the 24-bit relocation error.

HTH,

Mike