View Single Post
  #41   Spotlight this post!  
Unread 06-03-2006, 12:46
yoyodyne yoyodyne is offline
Registered User
AKA: Greg Smith
FRC #0116 (Epsilon Delta)
Team Role: Engineer
 
Join Date: Jan 2006
Rookie Year: 2004
Location: Reston, VA
Posts: 61
yoyodyne is a splendid one to beholdyoyodyne is a splendid one to beholdyoyodyne is a splendid one to beholdyoyodyne is a splendid one to beholdyoyodyne is a splendid one to beholdyoyodyne is a splendid one to beholdyoyodyne is a splendid one to behold
Re: The 8.2 (or 8.3) Battery Voltage Bug

Quote:
Originally Posted by Sachiel7
We were using a struct too, in our auto routines....
Has everyone here with this problem used a struct? It'd be funny if it was something as simple as that, but just checking...
We had this problem crop up at the VCU regional on Friday and it almost cost us a number of matches. Each time, we reverted to some version of old code and at one point made just a few mods to the default code just to get operator control of the drive motors and the herder.

Our code:

Uses a lot of structures with mixed char, int, and long types.

Uses Kevin Watson's serial port code.

Uses Timer 4 interrupt for a 5ms real time clock

Uses Kevin Watson's ADC with 5 analog channels each with a 200Hz rate for a 1KHz timer 2 interrupt

Points to structures and calls routines through pointers

Uses two additional shaft encoder interrupts

Assembles a lot of instrumentation data and sends that to the OI user variables, LED variables, and unused PWM outputs for data logging

Process_data_from_local_IO always runs at least every 10ms - we set a flag if two or more 5ms timer ticks have occured so I don't think this is an excessive loading issue. A printf with multiple arguments will cause this dely, however.

When we removed support for the shaft encoders and yanked out all the code that was not absolutely necessary toward the end of the qualification rounds on Sat the problem went away but it is clear to me that it will come back. Code that was "bad" causing the 8.2 volt problem on Friday night worked first thing Sat morning! (Power was removed for an extended period, however the backup battery was connected overnight) Tried to re-load the same code and it started failing again.

My instincts and experience with these problems is leading me to take a good look at the map file to see if there is something fishy going on with data section allocation. The problem is is that I don't have a "known good" hex/map file to use as a reference. We had no problems until Friday and I was wondering if it was the new IFI libraries but I can see from this thread that the problem can occur with the old libraries.

I posted more details to IFI - waiting for a reply.

If all else fails, I am inclined to trim the code to fit in the 2005 controller - not sure if it is legal to use it yet?

Greg