Code malfunction after robot reset?

[jgannon]

I have found myself in a most perplexing programming situation, and I'm hoping someone can help me figure it out in time to actually get this robot programmed before shipping. We have been using Kevin Watson's encoder code as a basis for our own code. The only modification I've made to it so far is to add our own joystick mixing function to user_routines.c, and call it in Process_Data_from_Master_uP(). This function does not do anything with the encoders. I downloaded the fresh code from Kevin's website, put his patched header file in the right place, pasted in the mixing function, compiled it, and downloaded it to the robot. I tested the joysticks, and it worked exactly as expected. I turned off the robot, and came back to it later to find that the code was flipping out. The motors spin at random without touching the joysticks, and if I look in Dashboard, I can see that several of the PWM outputs (including ones my code doesn't touch) are forever incrementing and overflowing, hence the motor craziness. When I switch the robot into autonomous mode, it keeps doing the same thing, despite me having no code in the autonomous function (aside from the IFI default to set all of the PWMs to 127, which is apparently not happening). I have sent the same HEX file to the robot again, and it continues to be crazy. When I put the IFI default code with our mixing function onto the robot, everything behaves again. I replace it with the encoder code, and it flips out.

Basically, my question is, how can the same code work and then suddenly not work? Does the encoder code leave some sort of persistent change even after reset? The fact that this problem persists into autonomous mode indicates to me that this problem extends beyond a simple coding error. Thank you in advance.

EDIT: One other important tidbit. I'm not using PWM 13-16, so I don't think it's a problem with the encoders causing the "special" PWMs to wig out.

[Kevin Watson]

Originally Posted by jgannon

I have found myself in a most perplexing programming situation, and I'm hoping someone can help me figure it out in time to actually get this robot programmed before shipping. We have been using Kevin Watson's encoder code as a basis for our own code. The only modification I've made to it so far is to add our own joystick mixing function to user_routines.c, and call it in Process_Data_from_Master_uP(). This function does not do anything with the encoders. I downloaded the fresh code from Kevin's website, put his patched header file in the right place, pasted in the mixing function, compiled it, and downloaded it to the robot. I tested the joysticks, and it worked exactly as expected. I turned off the robot, and came back to it later to find that the code was flipping out. The motors spin at random without touching the joysticks, and if I look in Dashboard, I can see that several of the PWM outputs (including ones my code doesn't touch) are forever incrementing and overflowing, hence the motor craziness. When I switch the robot into autonomous mode, it keeps doing the same thing, despite me having no code in the autonomous function (aside from the IFI default to set all of the PWMs to 127, which is apparently not happening). I have sent the same HEX file to the robot again, and it continues to be crazy. When I put the IFI default code with our mixing function onto the robot, everything behaves again. I replace it with the encoder code, and it flips out.

Basically, my question is, how can the same code work and then suddenly not work? Does the encoder code leave some sort of persistent change even after reset? The fact that this problem persists into autonomous mode indicates to me that this problem extends beyond a simple coding error. Thank you in advance.

EDIT: One other important tidbit. I'm not using PWM 13-16, so I don't think it's a problem with the encoders causing the "special" PWMs to wig out.

Post your user_routines_fast.c file.

-Kevin

[jgannon]

Originally Posted by Kevin Watson

Post your user_routines_fast.c file.

Will do tomorrow. I'm 99% sure that it's unchanged from the way it was in frc_encoder.zip. Thanks.

[KenWittlief]

Couple things that will make any bot wack out (may or maynot be related to your problem)

1. battery is low. Sometimes we forget this.

2. someone else is testing last years robot, and they have it on the same team number and radio channel. If something weird is going on always check your bot on the tether cable. There could also be someone else transmitting on the same frequency with some other type of radio equipment.

3. you are not downloading the file you think you are. Its easy to get the MPLAB SW setup so that it automatically pulls the download file from one directory all the time. You can be working in a different directory and it happly keeps downloading code that you have not touched.

4. some piece of code is sending 255 to a pwm port. It doesnt have to be one of the ports you are using. The way the PWM output works a 255 will reset the PWM output address in the middle of the output stream, so the values end up at random PWM ports. This will definately make your bot totally wack out.

[jgannon]

I sent my code off to Kevin Watson, and this is what he told me:

Originally Posted by Kevin Watson

Uncomment this line: #pragma interruptlow InterruptHandlerLow save=PROD,section(".tmpdata")
Remove or comment out this line:#pragma interruptlow InterruptHandlerLow save=PROD

Everything seems to be working fine now, so that's the secret for anyone else who runs into this problem. Thank you, Kevin!

[Rickertsen2]

What does that do?

[Joe Ross]

Originally Posted by Rickertsen2

What does that do?

It's been explained a few different places, but the best explanation is probably by Mike Bortfeldt here: http://www.chiefdelphi.com/forums/sh...ad.php?t=44046