View Single Post
  #9   Spotlight this post!  
Unread 02-25-2011, 09:53 AM
taichichuan's Avatar
taichichuan taichichuan is offline
Software Mentor
AKA: Mike Anderson
FRC #0116 (Epsilon Delta)
Team Role: Mentor
 
Join Date: Feb 2010
Rookie Year: 2010
Location: Herndon, VA
Posts: 328
taichichuan has much to be proud oftaichichuan has much to be proud oftaichichuan has much to be proud oftaichichuan has much to be proud oftaichichuan has much to be proud oftaichichuan has much to be proud oftaichichuan has much to be proud oftaichichuan has much to be proud oftaichichuan has much to be proud oftaichichuan has much to be proud of
Send a message via AIM to taichichuan
Re: cRIO says: FRC_UserProgram failed to load.

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 .

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
Reply With Quote