Presence of function causes auton to fail???

[Kyveck]

I apologize if this will be a little long, but I will try to present our problem clearly and concisely. As of Saturday morning, we had our autonomous mode working beautifully, albeit without any gyro code. In our spare time, we decided to go ahead and patch in some code one of our first year programmers wrote to allow us to use a Flightstick joystick that has some very odd calibration parameters. We began by placing the standard function Limit_mix() that our programmer had decided to use in its proper place in User_Routines.c, and its prototype in User_Routines.h. We had previously deleted it, but we are sure that the new copy of the function is identical to the default from IFI.
With the function and prototype in, and not called from anywhere, the robot only pulses its wheels for about half a second, instead of performing the scripted path that we had set for it. We have checked, and are extremely confident that the function is not called anywhere, and that none of the names in the function occur anywhere else in our code. We modified the code to read:

unsigned char Limit_Mix (int intermediate_value)
{
  /*
  static int limited_value;
  
  if (intermediate_value < 2000)
  {
    limited_value = 2000;
  }
  else if (intermediate_value > 2254)
  {
    limited_value = 2254;
  }
  else
  {
    limited_value = intermediate_value;
  }
  return (unsigned char) (limited_value - 2000);  */
  return 2;
}

Then it worked again. When we uncommented the first if(), it ceased to function properly in autonomous. We then commented the whole function, and created our own for test purposes. When we only made it increment a variable, autonomous worked, but if we gave it an if or while statement, it would cease functioning again. Our controls mentor is now reading up on our code, but hasn't found a problem yet. The only explanation my controls team can think of is that we might be out of program space or memory. Our mentor remains dubious of that, as we haven't gotten any errors from the loader.
Once again, the robot still seems to function properly in everything but autonomous, though we haven't had time to exhaustively test that. I can post more details if anyone needs to know more to guess what is going on. We high school students are afraid that something is probably seriously wrong if the presence of a function is enough to cause a whole module of code to malfunction, especially if the function is never called and is removed far removed from the autonomous module.
Chances are that we are just missing something obvious, but I have had a number of very astute programmers scratching their heads over this in the last few days. If anyone has some insight, or any idea what is going on, we would greatly appreciate any ideas. We are basing our code somewhat on Kevin Watson's scripting code from last year, though it has all been heavily modified to suit our needs. We have quite a lot of code, which lends some plausibility to the idea of us being out code space, and there are a decent number of interrupts in the background, if that affects anything. Thanks for reading this,
Kyle W
Lead Programmer, 1014 Controls Team
(Dublin Robotics)

[X-Istence]

unsigned char Limit_Mix (int intermediate_value)
{
  static int limited_value;
  
  if (intermediate_value < 2000)
  {
    limited_value = 2000;
  }
  else if (intermediate_value > 2254)
  {
    limited_value = 2254;
  }
  else
  {
    limited_value = intermediate_value;
  }
  return (unsigned char) (limited_value - 2000);
}

Is the default I found in my files.

I might be kinda blind (I wear glasses), but I am unable to see anything changed in those two functions, except you commented an entire block out.

[Alan Anderson]

Check your printf statements for missing, extra, or inconsistent variables.

Your description sounds like something that happened to us a couple of years ago. Things were failing to work properly in places that made absolutely no sense. But after we took out all our printfs in desperation, things worked fine. In retrospect, I suspect we had some int vs char mismatches, or something, that ended up clobbering unrelated variables.

[Keith Watson]

Those kinds of problems are frustrating to find.

Depending on how you were commenting/uncommenting I wonder if there might have been unterminated multiline comments before that function? But syntax highlighting in the editor would normally find that.

It would also help if you would post your non-working code instead of the working version. And in this case include both this function and the previous function including any comment lines between the functions.

[gnirts]

The only explanation my controls team can think of is that we might be out of program space or memory. Our mentor remains dubious of that, as we haven't gotten any errors from the loader.

The way I tell how much memory I am using is to open up MPLAB with your code's workspace, then go to View->Memory Usage Gauge, or type [Alt], then 'V', then '6'.

Its good to do a recompile before this.

Good luck,
Robinson

[Kyveck]

I might be kinda blind (I wear glasses), but I am unable to see anything changed in those two functions, except you commented an entire block out.

Exactly. We don't care so much about the Limit_mix() function, in particular, as that we can't seem to add any new function. (Once again, we haven't tested that exhaustively). We find it very wierd that commenting out that block and adding a default return value would have the effect of making our autonomous mode cease to run.

The way I tell how much memory I am using is to open up MPLAB with your code's workspace, then go to View->Memory Usage Gauge, or type [Alt], then 'V', then '6'.

I will try this tonight, when I get the robot to work with. Does anyone know off the top of their heads how much code space we get?

Check your printf statements for missing, extra, or inconsistent variables.

We do have a number of prinf statements in our code, and have had a lot of trouble in casting between ints and longs. Our AP Computer Science teacher suspects that there is a compiler bug relating to that.

I will try cutting printfs and looking up code size tonight. Thanks,
Kyle W
1014 Controls

[Bharat Nain]

Originally Posted by Kyveck

Does anyone know off the top of their heads how much code space we get?

128K

[Kyveck]

We're not sure exactly what happened, but a combination of optimizing extraneous code and reducing interrupts seemed to fix our problem. I we remove all printf statements, the autonomous won't work, but if we leave three, ("cmd velocity", "cmd null", and "cmd drive") it works well. We have no clue what is really going on on a low level that causes this problem, but for now we don't have any problems. We seem to be comfortably within program size. Does anyone now what is actually going on?
Kyle W
1014 Controls

[Mike Bortfeldt]

Kyveck,

From your last comment, it sounds like your interrupt code may be overwriting some common variables. Make sure you have this line in your User_Routines_Fast.c file just above the InterruptHandlerLow function (with both the .tmpdata and MATH_DATA sections).

#pragma interruptlow InterruptHandlerLow save=PROD,section(".tmpdata"),section("MATH_DATA")

Mike

[Kyveck]

I added the MATH_DATA section, and I already had tmpdata. I won't have the robot for a little bit to test, but could you explain what that line does? I generally prefer to use code that I understand. It has something to do with storing registers during the interrupt handler, I assume. Thanks,
Kyle W

[X-Istence]

Originally Posted by Kyveck

I added the MATH_DATA section, and I already had tmpdata. I won't have the robot for a little bit to test, but could you explain what that line does? I generally prefer to use code that I understand. It has something to do with storing registers during the interrupt handler, I assume. Thanks,
Kyle W

Yup, stores any data before it enters the interrupt, and then restores it after coming back out.