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.

[Mike Bortfeldt]

Kyveck,

As you probably know, when an interrupt occurs, the processor pauses execution wherever it happens to be in the normal loop code and begins executing the interrupt code. In the case of the low priority interrupts, this is done by the InterruptHandlerLow routine. By default, the compiler saves the values most of the basic registers on the stack at the beginning of the interrupt and then restores these registers back to their original value at the end of the interrupt. This allows the processor to continue executing your normal loop code as if the interrupt never occurred (other than a time delay). However, there are several registers and data memory sections that are typically used by the normal loop code that are not saved. The most common register is the 16 bit PROD register. This register stores the result of 8 bit multiplies, 16 bit return values from functions and a host of other things. Normally, any code you will write in the ISR (interrupt service routine) will probably utilize the PROD register. This is why in the #pragma statement above the InterruptHandlerLow routine has the part about "save=PROD". This tells the compiler to save the value of the PROD register when beginning the interrupt, and restore it when exiting. There are also two data memory sections that are frequently used by the compiler. The first one is the ".tmpdata" section. This is a block of data memory (in the access data area) that is used by the compiler as a temporary data storage area. The compiler typically stores intermediary values from calculations in this area when a more complex statement is encountered in code. This area is used (and reused) all throughout your code. If the compiler has a value stored in this temporary data section and an interrupt occurs, this area can become corrupted if the interrupt code shares a common temporary data location. The result of this can sometimes be seen in code not seeming to execute correctly, odd jerkiness of your bot, or a host of other things and can appear to be quite random. The second data section is the "MATH_DATA". All the more complex integer math routines (other than addition/subtraction) and all floating point math use this section when passing arguments and returning values and as temporary storage during processing of the calculation. If your ISR uses any multiplies, divides, or floating point values, you will probably be utilizing the "MATH_DATA" section. Like the ".tmpdata" section, if your ISR uses the "MATH_DATA" section when your normal code is in the middle of a calculation, your ISR could corrupt the values needed by the normal loop code. Like the "save=PROD" above, adding the 'section(".tmpdata"), section("MATH_DATA")' to the #pragma line instructs the compiler to restore these memory locations to their original value at the end of the interrupt.
The downside to saving these additional data sections is that it increases the time the processor needs to spend handling EVERY interrupt. The ".tmpdata" section size is dependant on your code, but the default 2006 code has a 12 byte area (this information can be found in the .map file) that requires about 76 instruction cycles to save and another 76 to restore. This adds about 15 microseconds to every interrupt call. The "MATH_DATA" section has a size of 20 bytes and will add a total of about 25 more microseconds. Normal context saving and execution of the interrupt is probably in the neighborhood of 4-5 microseconds, so each interrupt could delay your normal code processing by 45 microseconds before you even execute a single instruction of your actual interrupt code.
This is why you'll generally hear people say that you should only do what is absolutely necessary within an interrupt. If you can code your interrupts such that they don't require the ".tmpdata" and "MATH_DATA" sections and take very little time themselves, you can save a significant amount of processor time and be able to handle a much higher rate of interrupts, leave more time for your normal program loop and reduce the chance that you might miss an interrupt altogether (a floating point calculation within an interrupt is a very bad idea). To give you an example, this year, we are using interrupts to handle 3 encoders (max 3200 interrupts / second each), a 250 microsecond timer as a clock (4000 interrupts/sec), AI port scanner, TTL & Program port serial driver (maybe 1000 interrupts / sec total between the them) without any problems. However, they are all coded such that they only require us to save the PROD register. This took a while as it required us to examine the assembly code listing file and recode until we were able to get the functionality we needed without the compiler using any of the ".tmpdata" section variables. One thing you can easily do if you use a "if - else if" type statement in the InterruptHandlerLow routine, is to place the higher rate interrupts early in the if statement. This will allow the processor to find the "correct" interrupt faster reducing the overall time spent processing interrupts.
Without actually seeing your code, I can't tell if you need to save the "MATH_DATA" and ".tmpdata" sections, so to be on the safe side, I recommended saving both of them. This is the quick way to test to see if the interrupts were causing your problem without actually changing any of your code.

Sorry for the long post, but I hope it's useful.

Mike

[Greg Ross]

Thanks for the explanation, Mike. I've long wondered (about the save=PROD,section(.tmpdata), etc.), but I was never motivated to dig to find the explanation.

[Eldarion]

Once again, thanks for the explanation!

Our 'bot was experiencing random glitches, where it would go bezerk for one program loop every once in a while. In desparation, I copied Kevin Watson's pragma directive in and it fixed the problem. Now I know why it worked!