cRIO Application Loader Issue

[7-11number1]

Hello from 1711 Traverse City!

We have much (I joke) of our code written to do this, that, and the other and have tripped on what looks like a memory related issue. Having Hyperterm connected to our serial console, we witness vxWorks booting just fine, starts to load our deployed FRC_UserProgram then fails with an Application Loader exception, data access error of course. We know that the data access error is a protected mode trap on illegal memory access. The situation is that our code has not been executed yet. This seems to be connected with static memory heap utilization. We can solve it by reducing the number of variables declared on the heap (actually just by removing one class variable does the trick) and we boot fine. Adding a different class variable (such as changing Joystick rightStick(2); to Sensor turret(4);) causes the problem to re-occur. Anyone else witnessed this behavior? I am looking for WindRiver Linker options or any config settings that my be able to expand my static heap (sounds personal?). Since this is memory address space not stack, I do not think this is stack related (but all ideas welcome). I wish the nastiness of this one on nobody!

Oh by the way, reverting to a simpler program works just fine and we are still at update #2 RIO v7 (we'll change that this afternoon).

Cheers! Tony.

[Jared Russell]

If you are declaring your members using:

Joystick rightStick(2);

instead of:

Joystick *rightStick = new Joystick(2);

then you are declaring on the stack, NOT the heap. You have a limited stack size for your program (I'm not sure if you can increase it or not - anyone?). Try using heap variables instead and see if the problem goes away if this is how your code works (which it looks like from the snippets you posted).

[7-11number1]

Abwehr,

Thanks for the response, in this case we are declaring in the heap and did use the dereference as a tester but made no difference. I know that the code is not executing at all as this is the loader throwing the exception, not the application based on the exception report. When I get to the lab in a few hours, I'll post the exception text. Our code model is as follows:

/* declare global vars */
etc...
Joystick *joy2=new Joystick(2);
-or-
Joystick joy2(2);


(FUNCPTR) taskOperations(params) {
// do task operations
}

MyTask::MyTask() : Task("1711_TASK", (FUNCPTR)taskOperations) {}

I think some of the variables in the global space are candidates for the local task scope, but I fear there is a problem coming to light here that may bite us in due time again.

Cheers, Tony.

[7-11number1]

Problem solved and was a code architecture issue. We were instantiating the Joystick class outside of our class model. This caused early allocation, prior to the driver station object being initialized and *bang* all fell down. Keeping our pointer in the heap but instantiating in our task initializer class conformed to start up sequencing and all works without issue.

Thanks for your help!

Tony,
1711 Raptors