cRIO says: FRC_UserProgram failed to load.

Technical C/C++
1

We are unable to deploy our robot code to the cRIO. There are no errors from the Windriver IDE but there are VxWorks errors displayed on cRIO bootup console.
task 0xe744b8 (t1) deleted: errno=1835009 (0x1c0001) status=1 (0x1)
Relocation value does not fit in 24 bits.
Relocation value does not fit in 24 bits.
. (There are many, many of these)
.
Relocation value does not fit in 24 bits.
…FRC_UserProgram failed to load.

Googling this error gets many hits explaining that the code is addressed too far from the VxWorks kernel. The solution: use -mlongcall. In fact, a recent post, http://www.chiefdelphi.com/forums/showthread.php?t=91896 , recommends that as a solution to code not deploying. I followed their directions to implement -mlongcall:

“In Workbench IDE, right click on the project in project explorer on the left. Select “Properties”. In the project properties dialog, click build properties on the left and click the “Build Macros” tab on the right. Make sure your Active Build Spec is “PPC603gnu”. Select the “CC_ARCH_SPEC” name and click the Edit… button. If the “-mlongcall” option is not there, append it to the end. Save it and recompile.”

I followed this solution and it had no effect. Build and Deploy went normally with no errors. However, I have a robot “no code” condition plus the cRIO errors already described.

Current versions of Windriver and cRIO image:
C++ : 20110203rev2259
cRIO : FRC_2011_v27

When the updates and reimaging were completed a couple weeks ago, the sample code was built and deployed successfully. The robot was driveable. When we added the code for our arm, pneumatics, line sensors, etc, the code was no longer deployable and gives the errors described above.

We could really use some help on this problem. Bag and tag is Tue and we have a robot code only running in RAM using “Run Kernel Task”. The code tested very well as a Kernel Task and we can drive and operate our robot. But, we can’t compete without Deploying persistent code.

Thanks from Team 1258!

2

After creating a new Wind River project (Simple Robot Template) I see that mlongcall is already appended to the build parameters. If all else fails you could try creating a new Wind River project and just copy the cpp/h files from one directory into the newly created project in your workspace. Then right click, refresh in the project treeview in Wind River Workbench and all of the cpp files should build from then on. You will have to copy the code from the main robot class but at least you’ll have the latest project settings.

Also you should update to image 28…
http://www.usfirst.org/uploadedFiles/Robotics_Programs/FRC/Game_and_Season__Info/2011_Assets/Team_Updates/Team_Update_12.pdf

3

Thanks for the suggestion. Sadly that didnt’ work. Also, we had a crash (Error 60) when attempting to reimage the cRIO to v28. We did a reformat in Safe Mode then re-IP’d it then reimaged. The cRIO now boots up ok.

However, we still have the problem with deployed code:

“Relocation value does not fit in 24 bits.
…FRC_UserProgram failed to load…” error on the cRIO console output.

We are unable to deploy any code. We removed the cRIO before bagging in hopes that we can solve this problem.

The current plan is to set up the cRIO, router, a PD, digital sidecar and the Driver Station and try another laptop with Windriver on it. We can start with the default code and see if the problem remains. If no problems, we’ll add our code bit by bit to determine which line of code causes the problem.

Our code, by the way, works great as a kernel task so it drives, runs the pneumatics, follows the line, etc. It builds without errors. But when deployed, it won’t run.

Any help solving this would be greatly appreciated.

4

That looks like the missing mlongcall problem.

5

It WAS missing. But we added the -mlongcall flag using the instructions given in another post and still have the problem.

We did this…
“In Workbench IDE, right click on the project in project explorer on the left. Select “Properties”. In the project properties dialog, click build properties on the left and click the “Build Macros” tab on the right. Make sure your Active Build Spec is “PPC603gnu”. Select the “CC_ARCH_SPEC” name and click the Edit… button. If the “-mlongcall” option is not there, append it to the end. Save it and recompile.”

…then CTRL-B to build and then Deploy. Same result. “No Robot Code” on the Driver Station display and the same error on the cRIO. We also deleted the make file and did a build to create a new one thinking maybe the make file wasn’t updated. Still have the problem. When we go back to check the flags under CC_ARCH_SPEC, -mlongcall is there.

6

Doesnt Ctrl-B just recompile files that have had their source code changed since the last compile? You might have to force all your code to be recompiled in order for the new option to actually fix the problem the linker is encountering. I don’t know offhand what the “complete rebuild” is called.

7

Try clean build in the build option menu. Wind River does incremental build, so if nothing has changed, it may not do a full build. Also, check the console spew again to make sure you did not just hit a different issue.

8

The console spew is identical. However, sounds like a good plan to do a clean build. We are planning to do just that next week. Also we’re using a different laptop, freshly updated Windriver, and a new project.

I agree that CTRL-B might not look for changes like adding the -mlongcall flag to the build parameters. Starting clean holds lots of promise. We removed the cRIO and radio from the robot before the bag/tag. I’m setting up enough to do all the tests next Monday.

I will post our results next week.

Thank all of you for the great suggestions.

9

We, too had problems with deploying code to the robot. Our issues were twofold and, I believe, related to running Workbench on a 64-bit platform.

First, the code deployment problem. For us, with two different laptops (both 64-bit), the “Deploy” option would appear to work from the laptop’s perspective but would result in an incomplete copy. We would get all types of error messages about the CAN-based Jaguars failing to initialize. When we started looking into it, it seems as though the FTP mechanism in Workbench is FUBAR from a 64-bit platform. If I went to Filezilla and did the transfer to ni-rt/system/FRC_UserProgram.out by hand, then everything worked like a charm.

Next, when we switched from our test code to the real code, then we got the 24-bit relocation problem. Being a long-time VxWorks developer, I’m quite familiar with this particular issue on the PPC processor family. The code works if downloaded from workbench, but not if deployed. This stems from a “feature” of the PPC’s “bl” assembly instruction not being able to branch beyond 16 MBs. This is the default branch instruction for the PPC compilers and works well if your code gets loaded into the Wind Debug Pool region (which is what the 'Run Kernel Task" command does) but not if loaded at the top of memory (which is what the best-fit memory manager will do on initial boot up). Hence the need for the -mlongcall flag.

-mlongcall replaces the “bl” instruction with two separate instructions. One to load the 32-bit branch into a PPC special-purpose register followed by an indirect branch using the address in the just-loaded special-purpose register. This means that -mlongcall code should always be just a bit larger in size than the normal compile. This is an important visual cue that you’ve compiled it correctly.

So, where do you put -mlongcall? Right-click on the project and select “Properties”. Next select “Build Properties” -> “Build Macros” and edit the “CC_ARCH_SPEC” entry. Add -mlongcall to the end of the line, press return, and then click “Apply” followed by “OK”. Next, go back out to your project and right-click, “Build Options” -> “Clean Project”. Right-click again and select “Rebuild Project” and you should be good to deploy. You probably don’t have to do the “Clean Project” because the “Rebuild Project” should do the job. But, I’m superstitious :stuck_out_tongue: .

BTW, I tried adding -mlongcall to the “Tool Flags” entry of the “Build Tools” tab in the build properties. It took it, but apparently WRS doesn’t actually allow you to modify that field (they simply show you what you’ve selected from “Tool Flags” dialog). The visual check of the different size told us that the option wasn’t working. Moving it to the CC_ARCH_SPEC solved the problem.

Next, use Filezilla or some other FTP client and log into your cRIO with a user ID of “FRC” and password of “FRC”. CD to /ni-rt/system and copy your .out to FRC_UserProgram.out, exit the FTP client and reboot the cRIO. You should be good to go.

HTH,

Mike

10

Thank you Mike, for the great explanation on the reasons for that error. Tomorrow (Mon) I plan to assemble the cRIO and other components to get it running so I can try this. It may take a couple days to get it going but that’s the first thing I will try. I did add the -mlongcall flag as you indicated but I simply did a build which I can see now is insufficient.

On that last part that uses FTP: I have Filezilla and have been using it in my work. However I haven’t used it in place of Deploy. So when you say to copy the .out, do you mean the .out from Windriver and copy it to the cRIO with a change in file name (FRC_UserProgram.out)? Is that what FIRST --> Deploy does? If so, thats cool but I will have to navigate the the correct .out file in Windriver. It should be in a path with the Project name in it.

Thanks again!

11

Good luck with the cRIO build. Yes, that is exactly what the “Deploy” command in Workbench does. However, on 64-bit Wndows 7, it doesn’t appear to work quite correctly. Hence, my use of Filezilla and the name change. The path would be:

/ni-rt/system/FRC_UserProgram.out.

HTH,

Mike

12

Um, try compiling and deploying the examples, e.g. SimpleTemplate and see if it works. It it does, then you need to check your code.

Are you using a camera?

13

Yes, we are using a camera but we haven’t added the code for that. Our original code ran the robot very well as a kernel task.

We tried to compile and deploy SimpleTemplate, made sure -mlongcall was there but had a new error message: I/O Error popup even though in the left pane of Windriver says we can make a successful connection to the cRIO.

At first, I was connected via the router and got the error. Next, I used a crossover cable from the Windriver laptop directly to Port 1 on the cRIO and got the same I/O popup error when deploying.

I’ve never seen so many problems trying to deploy code on a robot!

I set up the cRIO, a PD, Digital Sidecar, D-Link and a couple spikes on a sheet of polycarb to make a sort of dev platform. This weekend we will try all this with a different laptop.

I have an additional question: If I want to use FTP instead of deploy what is the path of the compiled .out file and is it called simply .out? I’m asking this because I can FTP to and from the cRIO with no problem…thanks to Mike’s suggestions.

14

The path is /ni-rt/system/FRC_UserProgram.out.

HTH,

Mike

15

Can you post the output from the error messages?

16

Mike, I meant the path and likely file name of the .out on Windriver as a result of a build. That’s the file I will try to FTP (and rename) to the cRIO.

As mentioned, today the cRIO and related stuff will be in the hands of our programming mentor who will pick up where I left off yesterday.

If he gets the I/O error, I will post the actual error message.

I must say that even though I get the I/O error on deploy, I can successfully FTP files to and from the cRIO.

Thank all of you for the help with this problem!

-Larry

17

Oh, OK. That path would be something like:

c:\windriver\workspace\yourprojectname\PPC603gnu\yourprojectname\debug\yourprojectname.out

This name will change based on where you built your workspace. But, if you navigate into the workspace for the project, you should be able to find it under the PPC603gnu\ directory.

HTH,

Mike

18

If you can’t get the Windriver option of deploying your code to not work, then just use FileZilla and upload your .out file manually into the cRIO into the ni-rt/system folder.

That’s what I do…It’s gotten to be a habit.