The 8.2 (or 8.3) Battery Voltage Bug

[Bharat Nain]

I have a 2004 upgraded to a 2006 RC sitting at my house. I will try to get a battery and try to reproduce the results. Since we were also having similar problems through the day, I would be glad to test out anything suspectible. Please get in contact with me if you think you have a possible solution to this problem or a way to get there. I never spent time at NJ trying to correct the bug. I just replaced the battery. Thanks
-Bharat

[Eldarion]

Originally Posted by Bharat Nain

I have a 2004 upgraded to a 2006 RC sitting at my house. I will try to get a battery and try to reproduce the results. Since we were also having similar problems through the day, I would be glad to test out anything suspectible. Please get in contact with me if you think you have a possible solution to this problem or a way to get there. I never spent time at NJ trying to correct the bug. I just replaced the battery. Thanks
-Bharat

Try downgrading your controller to the v11 master code. I'm wondering if something got messed up in the v12 master code.

[Eldarion]

OK, I might have figured this out:
Has anyone noticed if the red "Code Error" LED on the OI is steadily on during the 8.3-volt bug?
I was doing some experimenting with the 2005 RC upgraded to v12 of the master firmware. Taking the advice of another person in this thread, I tried downloading frc_gyro.hex to the controller, at which point I was greeted with the 8.3V display and a solid red Code Error light. The interesting thing about this was that the Program State LED on the RC was steadily orange and the RC was ready to accept programming?

On power off / power on, the RC errored with a BLROD. I tried recompiling frc_gyro for the 18F8520, and it worked fine.

My thought is that maybe the 8.3V display is one manifestation of the sequence that is supposed to trigger a BLROD, halt the user processor, and kill all the PWMs, and it is simply displaying the 8.3V without doing the rest? I am guessing that user program data corruption (similar to what would happen trying to run an 8722 file on an 8520 chip) is fooling the master processor into this "half-disabled" mode.

Unfortuately, without a 2006 controller at my diposal, this is all speculation.
I just found it interesting that it is possible to trigger the same 8.3V bug on the 2004 / 2005 RC as well.

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

[kaszeta]

Originally Posted by Eldarion

OK, I might have figured this out:
Has anyone noticed if the red "Code Error" LED on the OI is steadily on during the 8.3-volt bug?

For us, the Code Error light WAS NOT on. The Radio light showed an error, and the Team LEDs quit blinking, but the Code Error light was the first thing we and Corey from IFI (who did a good job peering at dead bots on the field trying to debug them) checked.

I was doing some experimenting with the 2005 RC upgraded to v12 of the master firmware. Taking the advice of another person in this thread, I tried downloading frc_gyro.hex to the controller, at which point I was greeted with the 8.3V display and a solid red Code Error light. The interesting thing about this was that the Program State LED on the RC was steadily orange and the RC was ready to accept programming?

Odd. I haven't been able to replicate this on a 2005 RC, but I'll try upgrading to v12 firmware.

My thought is that maybe the 8.3V display is one manifestation of the sequence that is supposed to trigger a BLROD, halt the user processor, and kill all the PWMs, and it is simply displaying the 8.3V without doing the rest?

I'll note that you can see the 8.3V problem with code that otherwise appears to work correctly.

When I last talked with IFI, their guy was fairly convinced it was something in the ADC interrupt handler (which has a lot of code for an interrupt handler)

[Kevin Watson]

Originally Posted by kaszeta

When I last talked with IFI, their guy was fairly convinced it was something in the ADC interrupt handler (which has a lot of code for an interrupt handler)

Um, I'll eat the cardboard box that housed the last dozen Krispy Kremes that Dave Lavery polished-off if this is found to be true .

-Kevin

[Mark McLeod]

It happens to us without the ADC code.

[dlavery]

Originally Posted by Kevin Watson

Um, I'll eat the cardboard box that housed the last dozen Krispy Kremes that Dave Lavery polished-off if this is found to be true .

-Kevin

Kevin -
Just as a precaution, I really hope you are hungry. We experienced the "8.2V problem" over the weekend at the VCU regional. Ricky Torrance from IFI was there, and we reviewed the problem with him. We were not able to confirm it in the time we had to work the problem, but issues with overwhelming the interrupt handler was one of the two plausible explanations we were able to identify (the other was a memory overrun situation into a specific unprotected memory space that affected the ADC lines).

At the time, we only had that one known case of the problem to give to IFI as an example, which limited the options for investigation of the problem. As of this afternoon, IFI is aware that the problem may be larger, and is looking in to it. We have pointed them to this thread for more information.

-dave

[Gdeaver]

Question. Are all of the teams that are having problems using the most recent IFI loader? Wasn't the latest loader upgrade to allow full use of the new pic's increased memory? Could this be something in common with teams having problems. Wouldn't a fully charged back up battery show between 8.2 to 8.4 volts? When the error occurs what happens if the back up battery is unplugged? How does IFI manage the change from the 12 volt bat to the back up? Could a drop out from those shooters starting up hang the processor?

[Kevin Watson]

Originally Posted by dlavery

Kevin -
Just as a precaution, I really hope you are hungry. We experienced the "8.2V problem" over the weekend at the VCU regional. Ricky Torrance from IFI was there, and we reviewed the problem with him. We were not able to confirm it in the time we had to work the problem, but issues with overwhelming the interrupt handler was one of the two plausible explanations we were able to identify (the other was a memory overrun situation into a specific unprotected memory space that affected the ADC lines).

At the time, we only had that one known case of the problem to give to IFI as an example, which limited the options for investigation of the problem. As of this afternoon, IFI is aware that the problem may be larger, and is looking in to it. We have pointed them to this thread for more information.

-dave

Dave,

Well, I'm pretty confident it has nothing to do with my code for several reasons. The first, and most important, is that Mark has duplicated the problem using IFI's own default code.

-Kevin

[dlavery]

Originally Posted by Kevin Watson

Dave,

Well, I'm pretty confident it has nothing to do with my code for several reasons. The first, and most important, is that Mark has duplicated the problem using IFI's own default code.

-Kevin

I would not be surprised if that turns out to be the case. If so, then I will gladly eat a dozen Krispy Kreme donuts (notice I didn't say anything about the box...). Either way, I understand that both Mark and Tony Norman will be at the Arizona regional with us this weekend. If the problem is not solved by then, we can hold them down and sit on their heads until they fix it...

-dave

[ericand]

When we have seen this problem it has been immediately after a power up,
and is not cleared by using the reset button, but can be cleared by powering down and bringing it up again.

What is different between the data segment initialization when the reset button is pushed and the initialiazation when the system is powered up?

It almost looks like the code in _do_cinit is not setting the initialized memory
up correctly sometimes.

[kaszeta]

Originally Posted by Kevin Watson

Dave,

Well, I'm pretty confident it has nothing to do with my code for several reasons. The first, and most important, is that Mark has duplicated the problem using IFI's own default code.

As have I, and demoed it to Corey at BAE, hence my skepticism that the interrupt handler is the problem. My money is on something being wrong in the master CPU, since bad user code shouldn't be able to cause some of the problems I've seen.

[chris31]

Originally Posted by Kevin Watson

Um, I'll eat the cardboard box that housed the last dozen Krispy Kremes that Dave Lavery polished-off if this is found to be true .

-Kevin

We are not even useing the adc code and we get the problem. So lucky for you it looks like you wount have to eat a cardboard box.

[MikeDubreuil]

Can someone who has experienced the problem and have the hardware upgrade to the latest 2.44 version of the C18 compiler. Compile some user code and with the newly compiled code try to replicate the problem. I find it highly suspicious that Kevin Watson does the amount of development he does on the IFI boards and he hasn't experienced the problem.