The 8.2 (or 8.3) Battery Voltage Bug

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

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

[Eldarion]

Originally Posted by kaszeta

I'm wondering if there is some sort of memory stomping happening, because I've also seen some random bits flicking on the OI status leds (the pwm and relay leds; we had disabled the default routine LED feedback on these to make a little bar graph showing how good the camera lock was, but after we pulled the camera I pulled the code for this as well, and we still would see random bits flicker in there).

I had the intermittent data "glitches" with the LEDs as well; the cure was to save sections .tmpdata and MATH_DATA as well as the default PROD in the interrupt handler #pragma. For example:

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

Also, this may be a stupid question, but is everyone here using the latest version of the IFI loader? The previous version had a problem writing to FLASH bank 1, which might explain why it works just fine as long as it can fit in the 2005 controller.

EDIT: What version of the compiler is everyone using?

[Kevin Watson]

Originally Posted by Eldarion

...What version of the compiler is everyone using?

You beat me to this question. I'm using 2.44 (version can be found in readme.c18) and have seen *none* of the problems teams are seeing. All of the code on my website has been compiled with the 2.44 version. Has anyone had a problem with the pre-compiled code in my .zip files?

-Kevin

[kaszeta]

Originally Posted by Kevin Watson

You beat me to this question. I'm using 2.44 (version can be found in readme.c18) and have seen *none* of the problems teams are seeing. All of the code on my website has been compiled with the 2.44 version. Has anyone had a problem with the pre-compiled code in my .zip files?

Yes. I can regenerate the 8.2V problem with the gyro.hex file from a freshly-downloaded frc_gyro.zip from http://www.kevin.org/frc/, although it doesn't do it every time I upload it.

So far, the IFI folks think that ADC_Int_Handler() is too long, but I'm not sure I agree (since I'm not seeing the RLOD, and it works flawlessly on my 2004 RC).

Oh, and to answer your question, I'm using mcc18 v2.40. (Is an update available to us?)

[Sachiel7]

Yes, we are using v 2.40 as well, this is the version that was supplied in the kit. Did we miss an update? I don't recall seeing anything come across the board...
Perhaps that is the root of our issues,
From the IFI Website:

NOTE: To Compile 2004, 2005 or 2006 code, use MPLAB ver 7.20 and C18 Compiler ver 2.40 (newer versions can not be used)

Kevin...you didnt give us base code compiled with 2.44 did you...?
Even if so, we do appreciate all the hard work you do to provide us with the code each year, so Thank You!

[Kevin Watson]

Originally Posted by Sachiel7

To Compile 2004, 2005 or 2006 code, use MPLAB ver 7.20 and C18 Compiler ver 2.40 (newer versions can not be used)

They're referring to version 3.0 of the compiler, which cannot be used for a few different reasons.

Originally Posted by Sachiel7

Kevin...you didnt give us base code compiled with 2.44 did you...?

Yep, I certainly did. It's not a problem.

Originally Posted by Sachiel7

Even if so, we do appreciate all the hard work you do to provide us with the code each year, so Thank You!

As long as you learn something from reading/using the code, it's my pleasure.

-Kevin

[devicenull]

I'm using 2.40 and I haven't seen any of the problems stated here.. The real test will come on Thursday, when I see if any of these problems have appeared since we put it in the box...

I'm going to check tonight to see if we have a spare 2005/2004 RC that we can bring, but as of the current FIRST rules, they are not allowed. Maybe someone should go post on the Q&A forums, explaining the situation.. maybe we could get the 2005 RC cleared to use until this problem is resolved (It DOES work with the field control system, we were using it at the scrimmage with no problems) It wouldn't even be a tight fit for me.. 55% usage on the 2005 controller


Someone with access to a 2006 RC: Disable compiler optimizations... Project->Build Options->Project->MPLAB C18->Optimization (Dropdown), Disable.

If that fixes it, then its a compiler bug (But it can be worked around!)

I can tell you right now I've had all the optimizations enabled since the second week of build, and haven't seen this problem.

[kaszeta]

Originally Posted by devicenull

I'm using 2.40 and I haven't seen any of the problems stated here..

And neither did we, with almost 100 hours of autonomous mode testing in our clubhouse. At BAE we were batting 50%.

I'm going to check tonight to see if we have a spare 2005/2004 RC that we can bring, but as of the current FIRST rules, they are not allowed.

Under the circumstances, you can probably get a ruling on the field. They originally gave us trouble last year about subbing a 2004 RC for our 2005 when we broke a terminal off of it, and they eventually calmed down.