Problems with Deploying code

[dratewka2]

hello, Im running using Windriver but i cant seem to get the robot code to stay on the cRIO after rebooting. The code seems to stay on the RAM and after reboot the RAM is flushed making it so we have to reload every time.
After Building,Debugging,Running and then deploying it still does not manage to perminatly load.

yes i have used the First > Deploy function many times.

Help if possible. I am missing something simple, but im not sure what it is exactly.

[mikets]

You need to connect to the debug console either by COM port or using the netconsole so that you can see the messages from the cRIO. It will tell you why the code doesn't deploy. But in our case for last year, our code was loaded too far away from the WPI library so it need to use longcall in order to resolve the links. To fix it, you need to add "-mlongcall" to your linker option. 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.

[jwakeman]

It sounds like it might not be the mlongcall issue...it sounded to me like their application was running ok but was removed from the cRIO each time it rebooted. Maybe one of those little white switches on the cRIO is in the wrong position?

[dratewka2]

I went looking for the attached -mlongcall, and it was there, so it couldnt be the problem. Anyways ill keep trooping looking for another answer.

soo frustrating, even the getting started with c++ pdf couldnt help me when uploading code perminatly. I followed it to percision and still nothing...

[dratewka2]

all of the dip switches on the cRIO are set to off, should they all be positioned like that?

[mikets]

If it is not the mlongcall issue, you really need to hook up the debug console. It will at least tell you what failed.

[Alan Anderson]

Originally Posted by dratewka2

all of the dip switches on the cRIO are set to on(True), should they all be positioned like that?

No. They should all be OFF. I suspect they already are, because you wouldn't be able to do anything with the IP RESET switch ON.

You can turn the CONSOLE OUT switch ON if you want to monitor the VXworks console on the DB9 serial connector. The USER switch can be whatever you want it to be. The NO APP switch won't make any difference if you aren't using LabVIEW.

[dratewka2]

oops, i meant off sorry all the dip switches are set to off but still nothing.

[Trump]

Have you tried reimaging the CRIO. If you're using CAN try formatting it without any of the Can Drivers, and then go back in and put the CAN drivers on without reformatting. Also use netConsole to check that you aren't getting any run-time errors.