The 8.2 (or 8.3) Battery Voltage Bug

[Keith Watson]

Originally Posted by eugenebrooks

...Either the compiler is not correctly initializing the static variables that are not explicitly initialized, or the memory movement that might be caused by the variable landing in a different segment, the one with explicit inits, caused a memory stomping problem to go away.

The compiler creates a section of code in the binary where all of the static initializers are called. I have always assumed any sort of processor reset would call this block of code before calling main().

Originally Posted by gobeavs

That bug hit us once and disabled us for a round at PNW, but we have found a way to avoid it. When we turn our robot on at the beginning of the round we have someone at the OI looking at the battery voltage to give us a thumbs up or down depending on whether it is showing ~12 or 8.2. If we get 8.2 we just power cycle (not just reset, because that screws up the camera). It saved us at least once later on.

We encountered behavior where the symptom is that the static initializers are not being called by a reset under certain conditions. See the recent thread Camera does not search in autonomous mode after reset for a full description of those conditions.

[Mike Bortfeldt]

I've been able to successfully cause the 8.2 battery voltage bug to occur on demand by sequentially downloading 2 different versions of code (both based off the default code). I haven't narrowed down the exact cause, but I will see what I can find out tonight and call IFI tomorrow. With a way to reproduce the problem, they will hopefully be able to come up with a fix or workaround.

Mike

[Ryan Meador]

I have some information that may be relevant. There is a problem with the silicon in the PIC chip that involves the interrupts not properly restoring register values upon return. I'm not sure if this could cause the problems you're all reporting, but the possibility exists - it may be this problem that the new libraries are supposed to fix.

You can read about this and other errors in the silicon of this line of chips here: http://ww1.microchip.com/downloads/e...doc/80221b.pdf

[kaszeta]

Originally Posted by Ryan Meador

I have some information that may be relevant. There is a problem with the silicon in the PIC chip that involves the interrupts not properly restoring register values upon return. I'm not sure if this could cause the problems you're all reporting, but the possibility exists - it may be this problem that the new libraries are supposed to fix.

At least with Team 95's code (which does use an interrupt handler, but just for the Timer2 and ADC), the new libraries don't fix this problem.

[chris31]

The new libraries didnt fix are problem. And the only interupts used are with Kevin's code.

[steven114]

We had this problem too - our workaround was to stop using structures. It seemed that even having a simple struct of a few integers would cause rampant corruption and crashing. I'd suggest that as something to try if you're at your wit's end...

[kaszeta]

Originally Posted by chris31

The new libraries didnt fix are problem. And the only interupts used are with Kevin's code.

I just talked with IFI (and was talking to the same IFI rep that was at BAE), and they are looking at the issue and are going to call me back.

[Kevin Watson]

Originally Posted by chris31

The new libraries didnt fix are problem. And the only interupts used are with Kevin's code.

Just FYI, IFI uses the high-priority interrupt for SPI communications between the master and slave processors. You just can't get away from those pesky interrupts <grin>.

-Kevin

[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...

[eugenebrooks]

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 were using a struct as well, but I believe that the IFI code
also uses structs. Remember that in an earlier post in this thread
the problem has been demonstrated to occur with the default code.

The problem comes and goes with small changes to your code, so
things like "getting away from structs" might make the problem go,
but it will come back later. Unless there is a decisive cure, the only
way out is the 2005 controller and a squeeze to fit if your code has
gotten too big...

Eugene

[yoyodyne]

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

[kaszeta]

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...

No structs here (well, it should've used them, but our team's students are just learning about those things).

[kaszeta]

Originally Posted by eugenebrooks

We were using a struct as well, but I believe that the IFI code
also uses structs.

Indeed, take a look at ifi-aliases.h and the pic18 header files and you'll see that most everything you use for variables provided by IFI is a struct.

[kaszeta]

Originally Posted by yoyodyne

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

Our original code was very complex, but by competition we had narrowed it down to code that

• Uses Kevin's gyro code (which includes his serial code and adc code)
• Uses Timer2 and the ADC interrupt
• Uses two analog channels (the gyro and a selector switch for autonomous strategy)
• No shaft encoders, weird pointers, or anything like that.

(although I like the idea of using a timer to make sure that you aren't bogging down on the loop execution)

[yoyodyne]

Originally Posted by Keith Watson

The compiler creates a section of code in the binary where all of the static initializers are called. I have always assumed any sort of processor reset would call this block of code before calling main().

We encountered behavior where the symptom is that the static initializers are not being called by a reset under certain conditions. See the recent thread Camera does not search in autonomous mode after reset for a full description of those conditions.

We don't initialize any variables in the code, but instead in each file have an explicit initialize routine such as void InitializeRealTimeClock(void) that performs the initialization. If you write code this way, you don't have to worry about what the loader will or will not do to initialize bss and data. We put all the init calls that were used for autonomous just above the inner loop as well just so we could toggle the competition port pin to test the autonomous routine over and over without hitting reset. - Didn't help with the "8.2" problem though.