Re: The 8.2 (or 8.3) Battery Voltage Bug
 

So they are using an RC oscillator on the processor? That would be odd.
If it's a crystal oscillator, there's no way that should be happening whatsoever! :confused:

On a side note, there are over 100 posts in this thread! :yikes:
This must be a big problem! :D

Re: The 8.2 (or 8.3) Battery Voltage Bug
 

The 04 RC uses a crystal. I have not taken apart a new RC. If they use an RC oscillator it is indeed a BIG problem.

Re: The 8.2 (or 8.3) Battery Voltage Bug
 

Crystal are subject to temperatures so are voltage regulators. If I remember correctly don't both processors share a common clock? Maybe this worked for the old proc but not the new one this year. Also the pic does have a watchdog capability. Maybe this needs to be implemented.

Re: The 8.2 (or 8.3) Battery Voltage Bug
 

WOW. We had this same problem. We got it fixed at the competition after we lost 2 matches. I am not a programmer so i dont know what the problem was but it supposedly came out in an update. I will try to get one of our programmers to tell me what or where. It is a simple update that took them about 5 minutes. I wish i had more details. It is a very fixable problem. It shifts the inputs by one or something. I am really surprised nobody has posted a fix here yet.

Re: The 8.2 (or 8.3) Battery Voltage Bug
 

The '05 uses a crystal, and I'm sure the '06 does too. Crystals still have temperature issues, they just aren't as bad.

Re: The 8.2 (or 8.3) Battery Voltage Bug
 

Please post what you know, but i doubt the fix is as simple as you seem to think it is.

On a side note i just found out are RC is back from competition so hopefully i can test the tempurature stuff more.

EDIT: WOW, 105 posts in this thread.

Re: The 8.2 (or 8.3) Battery Voltage Bug
 

NOWHERE NEAR as bad.

Re: The 8.2 (or 8.3) Battery Voltage Bug
 

Come'On guys, the someone used RC for "Robot Controller"
in posts above and then someone distorted it to "RC" circuit for
timing. Lets get back on topic...

Its not the Crystal... It is likely the R and the C in the CMOS
wiring...

Re: The 8.2 (or 8.3) Battery Voltage Bug
 

If you had the 8.2[3] battery voltage problem, and you applied the
high priority interrupt patch, and the linker patch, and it fixed the problem,
WE REALLY WANT TO KNOW!

Eugene

Re: The 8.2 (or 8.3) Battery Voltage Bug
 

We've never had this problem.. I patched the linker script Thursday, when I found out there was a patch. I don't know if it fixed problems that would have occured, or if we never would have had them.

I can't see any reason why you shouldn't use both patches.. What more can you do? Patch both and hope for the best.

Re: The 8.2 (or 8.3) Battery Voltage Bug
 

I am positive that we had the 8.3 Volt battery problem. I dont know what was fixed but I do know that it was fixed by a moderate programmer in 5 minutes. I also know it had something to do with switching ports and making our robot shiver but not work. The person who fixed it(Brandon Heller, Tim Emerson also knows about it) is a regular to this site and i am very surprised he hasnt read this thread. I dont know where he got the fix or anything, I heard something about a team update and a new version of something. I wish I could be of more help. I will try to get a hold of somebody who knows what they are talking about.

Re: The 8.2 (or 8.3) Battery Voltage Bug
 

Ok all, just back from GLR. I was in terror of the 8.2V bug thursday night and saw the patch in here. I was going to rebuild and dump code to make sure we wouldn't get hit, but figured the odds were low that it'd happen in the first match, and we had a lot of robot work to do. So, of course, I see the dreaded 8.2V on the OI when we're out on the field. Tried to cycle the power, but the match was starting, so that sucked. Rebuilt the code and dumped it, and didn't have the problem for the rest of the regional.

However, this is such an intermittent problem, that I'd sort of like to have a statistically significant sample of people this has worked for.

Re: The 8.2 (or 8.3) Battery Voltage Bug
 

I talke dto one of our programmers at school today and I sent an email to a mentor, so one of them should be on here soon.

Re: The 8.2 (or 8.3) Battery Voltage Bug
 

IFI has posted the patch already.. It's on their web site. You don't have to know any programming to do it..

Re: The 8.2 (or 8.3) Battery Voltage Bug
 

Re: The 8.2 (or 8.3) Battery Voltage Bug
 

I am curious about this subject. We had some troubles in AZ, seemed like our bot was glitching. Very sporadic, we were never able to trace it.
What were the symptoms of this voltage bug?

Thanks in advance

Re: The 8.2 (or 8.3) Battery Voltage Bug
 

Typical symptoms are your robot just plain not working. It tends to hit as soon as you power the bot on and won't ever rectify itself once it happens. Atleast until you completely power the bot down. When it happened to our bot, we just ran back and forth and the joysticks wouldn't do anything.

Re: The 8.2 (or 8.3) Battery Voltage Bug
 

On our controller the problem never occurred on startup although most of the others I've personally seen occurred immediately at startup.

It hit us after the robot had been on awhile. The symptoms will differ with your individual control setup. In one instance ours suddenly began attempting to rapid fire our poof balls all on it's own. The more common case was the gunner would suddenly find himself controlling the left drive train, or when idling the robot suddenly began driving away slowly. You will see mechanisms moving without orders and controls that won't control.

No recurrence for us in competition with the IFI library update and blocking out bank 15. But the controller doesn't run very long in matches.

I did see the problem in a couple of other robots at competition, but they didn't have the newest patches in.

Re: The 8.2 (or 8.3) Battery Voltage Bug
 

We patched our code with the interrupt related patch, and the linker script patch, and although we did not see 8.2 displayed on the controller for the battery voltage our code refused to load and run on the 2006 controller. Retrofitted to the 2005 controller our custom code loaded and ran without any problems.

Depending on your use of interrupts and timers, you may, or may not see problems continue after patching your libraries and linker script. Several teams at the San Jose regional remained dis-functional after patching.

The only sure cure seems to be a 2005 controller upgraded to V12 master code. The upgrade is required and checked by the technical inspectors. If you are having problems with the 2006 controller, I would like to suggest that you use a fix-it window to retrofit your custom code to the 2005 controller, squeezing it to fit if required, so that it is ready to go if you need it. Don't forget to have a copy of the V12 master code to load into your controller.

Have fun, and don't forget that it all about fun and nothing else...

Eugene

Re: The 8.2 (or 8.3) Battery Voltage Bug
 

Nope.. The 2006 RC is required this year.

Post on QA about it too: http://forums.usfirst.org/showthread.php?t=788

Re: The 8.2 (or 8.3) Battery Voltage Bug
 

Yeah, we got bit by the 'bug' in like our 4th seeding match today at Chesapeake. Bot started going crazy all over the field, running into the walls and such. Took it back to the pits, all the controls were messed up, then mentor walks over to the controls, hits the select button on the OI, and says, "Well you only have 8.2 volts here." Ahh!!! Problem solved. Got the update on flash drive from IFI guy, our programmer had it fixed in 5 minutes.

Everything else went well and we are now 5 and 1- the match we lost was when our bot was possessed!

Make sure to get the update!

Good luck to all,
-Chris

Re: The 8.2 (or 8.3) Battery Voltage Bug
 

I am happy to report that so far (8 matches today) Team 116 has not had problems at the Peachtree regional. We are using the same library update as we were at VCU and in addition using the new linker command file with gpr15 PROTECTED. I still don't understand how user processor memory issues would impact the master processor to OI comms. We have not implemented the large code switches mostly because we don't want to slow the code down.

Greg

Re: The 8.2 (or 8.3) Battery Voltage Bug
 

This killed one of our alliance partners in the elimination rounds and almost killed another.

Re: The 8.2 (or 8.3) Battery Voltage Bug
 

More importantly, did the suggested linker and library changes help, or were they already using them?

At this point, posts saying "yes it happened to me (or someone we know)" are not worth much without knowing if they have tried the fix or not.

If anyone is experiencing a problem (and they are using the fix) please let IFI know, and let the Chief Delphi community know ASAP!

Right now, all indications that I have seen are that the linker script and the library replacements fix the two hardware problems in the robot controller. If anyone has reason to doubt that the problems are fixed, or if anyone has experienced any other controller hardware problems, please report the details here.

Thanks!

Re: The 8.2 (or 8.3) Battery Voltage Bug
 

Well, with the revised linker script, Team 95's robot functioned perfectly at Palmetto. Competition is a lot more entertaining when your bot actually does something (we got second place with Teams 16 and 1676).

Deepfelt thanks to everyone here and at IFI for their help in finding this problem and turning our season around.

Re: The 8.2 (or 8.3) Battery Voltage Bug
 

I concur, it was very nice seeing our robot run in Las Vegas and being confident that any strange behavior was due to things within our control, and not hardware failure in the RC.

Re: The 8.2 (or 8.3) Battery Voltage Bug
 

Does anyone know if the hardware problem that caused this has been fixed in the 2007 controler, or do we still need the linker script change that eliminates the upper section of memory?

Re: The 8.2 (or 8.3) Battery Voltage Bug
 

No, it hasn't. This years controller uses the same revision of the 18F8722 as last year.

-Kevin

Re: The 8.2 (or 8.3) Battery Voltage Bug
 

My understanding was that the problem was drift in the oscilator that coordinated the communication between the master and user processors.

Re: The 8.2 (or 8.3) Battery Voltage Bug
 

Come to think of it, I was discussing this year's controller with IFI staff and this was mentioned, but I don't recall if they made changes to address this bug. The other 18F8722 related bugs are still there though. You might give 'em a call to find out.

-Kevin

Re: The 8.2 (or 8.3) Battery Voltage Bug
 

Yeah, I will dl and patch just to be sure. Oh, the ref thought we were having the 8.2 volt bug, but it turned out to be the circuit breaker tripping :) Is there any plans to fix this bug permanently? Did Microsoft have something to do with the controller---this seems like their handy-work ;)

Re: The 8.2 (or 8.3) Battery Voltage Bug
 

I saw this bug tonight on last year's controller. I am not using any fixes yet, because I didn't think that this was such a huge issue.

Mine went into autonomous mode. All by itself. Even though the competition jumper was connected and set to disable. This is a *serious safety issue*. More than one light was amber on the RC; I think it was the bottom two. I can't remember for sure because I saw it, went "what the..?" and hit reset a few times. For about 2 minutes the controller was strange, not obeying joystick commands, shifting (or trying to, there was no air in the pneumatics), and running auton intermittently (YEA! Another intermittent error!:) ). I re-programmed the controller more than once, with slightly different codes (I added a printf to see if it really was auton running; I couldn't believe it).

I will try the linker script. I already had new libraries compiled in, so those aren't the cure. I hate that I have to use a "beta-ish" fix, but if that's all there is, that's what I'll use. This is the first time in the whole year and a half we've had that controller that I've seen that error. May it never come back!

Hopefully IFI gets it straightened out quick!

JBot

Re: The 8.2 (or 8.3) Battery Voltage Bug
 

I saw the 8.3 Battery Voltage Bug last night with the following setup:

2004 controller upgraded with the 8722 processor (the upgrade was done last year).
Beta 14 master firmware.
2005 radios.
2007 OI
the current linker script and frc_library.lib from the 2007 default code (which I verified were the same as the updated ones from last year)


I originally saw the problem about a week ago. After investigating, I realized we were not using the new frc_library.lib. After putting that in, the problem went away until last night, when we saw the problem 3 or 4 times.

Re: The 8.2 (or 8.3) Battery Voltage Bug
 

We've seen the 8.3/8.2 Battery Voltage Bug yesterday and today with the following setup:

2007 controller
Beta 14 master firmware.
2007 radios.
2007 OI

We have the PROTECTED memory section defined in the linker command file.
We have the latest FRC 8722 Library file

Has any other teams seen the 8.2v bug resurface? Any ideas?

Thanks!
-Terry

Re: The 8.2 (or 8.3) Battery Voltage Bug
 

It hurt first week regional team last year. Hopefully, if it is occurring again we can figure it out fast. Especially since we ship our RC tomorrow.

Re: The 8.2 (or 8.3) Battery Voltage Bug
 

We've had it on our brain for the entire build season. Adding protected to the problematic memory section and replacing the library files fixes the whole problem.

Re: The 8.2 (or 8.3) Battery Voltage Bug
 

Are you using any interrupts?
If so, what interrupts are you using and for what purposes.

<<< Let me be a little more transparent. All of the teams that I talked to last
year who were seeing this problem, after applying all the patches, were using
timer 3. I am interested in knowing if you are using timer 3. The patches
move things around in memory, and any movement of variables in memory
affected this problem, without really fixing it. We never saw the problem when
we backed away from interrupt use, although our interrupt based code was well
wrung out on prior year's controllers and never showed a problem. Knowing that
the chip was the same, and that the patches did not fix it for us last year, we
avoided any additional interrupt use in our code this year. One workaround worth
trying if you are not using the Kevin's camera code is to use his lastest code
that changes how the high number pwms are being handled. >>>

Eugene

Re: The 8.2 (or 8.3) Battery Voltage Bug
 

Joe and Terry,

If you have not done so already, please get this info to IFI as soon as possible.

Regards,

Mike

Re: The 8.2 (or 8.3) Battery Voltage Bug
 

I read through the errata on the 8722 last year, and again recently, and couldn't see how the changes to the linker's ability to use a region of memory related to any of the published errata.

Did I miss something?

Re: The 8.2 (or 8.3) Battery Voltage Bug
 

Seeing that we got killed by this bug at BAE last year, it's on our pre-match checklist to verify the battery voltage on the OI when the bot is placed.

That said, we haven't seen this one this year in practice yet, or at the scrimmage. But there's a lot of code out there that doesn't have the linker fix in it, so I'd expect a certain amount of repeat of this problem.

Re: The 8.2 (or 8.3) Battery Voltage Bug
 

Furthermore it seems like there's a lot of code with the linker fix that's still being affected. I'm starting to think we need a processor rollback, with maybe memory extensions (I'm not sure if the PIC supports external Flash/SRAM latches though) to compensate.

Re: The 8.2 (or 8.3) Battery Voltage Bug
 

I did speak with Tom Watson yesterday. He said I was the first to report it since the new linker script and library files were released. Hopefully Terry has talked to them by now as well.

I did more testing today. I was able to reproduce it with all 2007 components.

We're using a modified version of Kevin's ADC code at 3200hz. We're using his camera code, but without a camera physically installed. The problem will occur consistently if we're using printf to print 20 or so characters per slow loop. I didn't see it when we were not outputting any data.

Last week, I verified that that we could output 40 characters without causing us to slow down the slow loop. However, something may have changed since then, so I need to reverify this.

I suspect that something in our modified ADC code is stomping on something it shouldn't, and that it isn't a widespread issue.

I do have a test setup that I can reproduce the issue on, so I will continue trying to isolate the problem, and hopefully it is just our code.

I still wonder in the back of my mind whether protecting gpr15 doesn't fix the root cause, but only the most common symptom.

Re: The 8.2 (or 8.3) Battery Voltage Bug
 

Obviously, we can't test with 2007 components. I've been concerned with this, so I've been testing, both with my 2006 RC and this years 2007 RC before we shipped.

Our code has 8 ADC channels running Kevin's ADC code at 800 Hz and 16 samples per update (so that we could get 12 bit precision although in testing I think we can work just fine with the default 200 Hz and 4 samples per update), as well as three shaft encoders all running at up to around 1000-2000 pulses/sec. We also generate a *lot* of debug printfs, but the student programmers will probably comment out most of those in the pits. We've got Kevin's serial drivers in there as well, but no camera. I haven't been able to duplicate anything yet with either controller using the fixed library and linker scripts. The 2007 rc has the beta update for the master controller code, but the 2006 rc is un-updated.

I'll try to recreate your setup and torture-test my 2006 RC if I have a chance.

Why that fast, if you don't mind my asking? And what did you modify?

I'm pretty sure this just cures one symptom.

Re: The 8.2 (or 8.3) Battery Voltage Bug
 

For what it is worth, when we had this problem last year we were using a timer to time the rotational interval of the ball shooting wheel. Our code to do this was very compact and carefully combed over for potential race conditions. Small changes to printf statements, or adding static sentinel variables to the code, could cause the 8.2 volt bug to come and go, and in particular, memory movement caused by the sentinel variables could cause hard code errors. The code ran without a hitch on the prior years RC.

Given all this trouble, we did not use any custom interrupt/timer coding this year. Stepping outside of what is commonly used by all the teams seems to get you into serious trouble with the new PIC chip. In my humble opinion FIRST should allow an older controller to resolve the 8.2 bug when it occurs. It just isn't right to lead students through a sophisticated control system development only to have the 8.2 bug take you out at the competition. We are supposed to be inspring the students, not depressing them.

Eugene

Re: The 8.2 (or 8.3) Battery Voltage Bug
 

Terry, when I talked to Tom Watson at IFI this morning, he again said that I was the only person to report the problem this year. Can you please call IFI so that they are more aware of the problem.

That's exactly the type of behavior we are seeing. I disabled all printfs and it ran overnight without a code error

I would support allowing the older controllers, however that wouldn't help us without a major code redesign, because we're already over both the code and RAM limit for the older processor.



We wanted to run the gyro at 1600 hz and 32 samples per update (we've gotten very good results with that in the past). Last year, that was the only sensor we used, so Kevin's ADC code was fine. However, this year, we're using 5 other analog sensors, so it wasn't practical to use his code with a sample rate of 1600*6. Our modifications use the same basic framework, but allow different channels to use different sample rates and samples per update values. It takes longer to execute the interrupt routine, and uses more stack space, but I've proven that the problem isn't throughput or stack space.

Re: The 8.2 (or 8.3) Battery Voltage Bug
 

I'm surprised that you need both that update rate and precision, that's all.

But I feel your pain, last year we used Kevin's ADC code for a gyro and a single pot (and the pot wasn't used after autonomous). This year we've got the gyro, IRs, and a pot.

I'm interested in your "different channels at different update rates", since we tried the same thing (we really don't need our IR sensors updating as fast as the gyros), and it was indeed very difficult to get it to not RLOD. Difficult enough that we decided it wasn't worth the risk.

Re: The 8.2 (or 8.3) Battery Voltage Bug
 

I just dropped Kevin's original code back in, and still had the problem. That makes me feel better that it isn't our new ADC code, but leaves me stumped.

Re: The 8.2 (or 8.3) Battery Voltage Bug
 

When we were debugging this problem last year, we found that it was heat related. The problem would show up more frequently when the system was cold and less when it was warm.

See: http://www.chiefdelphi.com/forums/sh...992#post466992

Re: The 8.2 (or 8.3) Battery Voltage Bug
 

We (Team #1825, JCH Robotics) have had this same problem, and let me tell you it absolutely killed our robot. Our design probably wasn't as strong as it could have been, but it was solid--however, starting Thursday and increasing in intensity through Saturday, we kept running into the following errors:

Our two interrupt-driven optical shaft encoders failed to update, causing our encoder-based arm and wrist positioning system to drive to its extremes without ever updating the value from the encoder. Thank goodness we had limit switches that were hardcoded to stop all motor operation, or even the foam-core fiberglass/resin compound that composed our arm would have failed.

Incremented variables designed to serve as timing loops failed, making our autonomous mode a signal failure, since our "release ringer" code was never triggered. Without this error, our autonomous mode would have been one of the most successful at the arena--the robot placed ringers perfectly in position several times (until our camera failed Saturday) but the variable that triggered the arm to release was overridden and never reached the expected value.

The camera, when we fired the robot up on Saturday, locked up entirely, despite the fact that it worked fine Friday and no changes had been made since.

Our OI displayed 8.3 volts consistently.

An "Unknown User Violation" displayed on the dashboard occasionally instead of the voltage readings, with no apparent relation to anything done in the code. All attempts to solve or debug this failed. PLEASE, would it be possible to get more detailed error messages than "You have an error!"?

On tether, the robot would work just fine--though other symptoms such as the 8.3 volt output on the OI were still present--however, when hooked up to the competition interface at the arena, the robot failed miserably, as apparently several variables were overwritten, causing the robot to act as if buttons had been pressed when they weren't.



In testing at home, the robot had appeared to work perfectly in testing, responding excellently to everything we did and placing several ringers even in autonomous. Based on this, we hadn't tried any fixes or patches--why fix what isn't broken? However, when we got to the arena, we started noticing these strange errors. We attempted to fix them, came here looking for help, found several bits of advice, and followed them all, but to no avail--the robot's performance only degraded as time went on.

Fortunately our drive train was still operational, and even though it only had 2 small CIM motors excelled at defensive maneuvers thanks to its traction and center of gravity. This allowed us to get into 8th in the seeding rounds--but by the time the finals matches rolled around, the robot was in such a state that it could barely drive, and its arm was entirely useless.

Fixes we tried:

Updating library files (no success; we were using the latest release)
Updating linker files (made the robot worse if anything; certainly no improvement noted)
Rebuilding the code from scratch (a real pain, and a last-ditch effort to make SOMETHING on the robot work, but we might as well have saved ourselves the effort)
Involving the IFI staff at the location (they were extremely helpful, but nothing they suggested made a difference--which puzzled even them)
Asking other teams for help (the Bomb Squad mentor/programmer and a few others graciously suggested a few fixes, but they were as ineffective as the other methods tried)
...
Attempting to punch the robot (hey, it works on my PC! Unfortunately, the RC was set back in the robot far enough that I couldn't reach it from where I was sitting...)

Even though we're now out for the season, I still want to get this robot working for demonstration purposes. What else can I try?

Re: The 8.2 (or 8.3) Battery Voltage Bug
 

Call up IFI and tell them your problem. They might offer to look at your code and maybe even your processor. Maybe something else is also wrong with the processor you are using.

Re: The 8.2 (or 8.3) Battery Voltage Bug
 

We were able to work around it by not using printf or Kevin's serial code. We successfully used IFI's blocking serial libraries without triggering the bug. I do not beleive that Kevin's serial code is the entire problem, as we tried reproducing the problem with just his code several times. Rather, we've decided that it is some wierd interaction between his code and our code.


We replaced all our printfs with DEBUG statements like Kevin's camera code so we could easily disable all printfs before doing anything important.

Re: The 8.2 (or 8.3) Battery Voltage Bug
 

I find it scary that the linker is allocating variables such that problems that bad are appearing, and you're using code that could do that.

All variables are statically allocated.

Pointers and arrays are used only a few times in the code.

Issues that bad would suggest that something is very, very wrong at a fundamental level. Try it on another RC.

Re: The 8.2 (or 8.3) Battery Voltage Bug
 

We are having the same problem that you guys speak of in this thread, and we can't understand from this thread what the exactly is the solution...
Can anyone please clarify to us what exactly we shoud do?
We are using Kevin's most updated code...

Re: The 8.2 (or 8.3) Battery Voltage Bug
 

Whoa, really? Can you zip up your entire build directory and e-mail it to me?

-Kevin

Re: The 8.2 (or 8.3) Battery Voltage Bug
 

I'm sorry for the confusion, everything is ok now.
Thanks a lot though =]

Re: The 8.2 (or 8.3) Battery Voltage Bug
 

What do you mean everything is okay now? Given the pain the 8.2 bug caused teams in the past, you need to let me know if you actually had this problem, so that I can try to understand it and hopefully provide a fix.

-Kevin

Re: The 8.2 (or 8.3) Battery Voltage Bug
 

We experienced this bug earlier this year. We changed the size of our autonomous code and it went away.

Re: The 8.2 (or 8.3) Battery Voltage Bug
 

Is this with my code? If you happen to have an archive copy of the malfunctioning code, can you e-mail it to me? Has anyone else seen the 8.2 bug this year (yes, that includes you, over there in the corner)? If you have, please post here.

-Kevin

Re: The 8.2 (or 8.3) Battery Voltage Bug
 

We are using your gyro + encoder code integrated into last years ifi default code.

We didn't remove any functional code when we did our clean up - we deleted some old procedures that we were not even calling. We were not close to the memory limits. That's the best information i can give you as we only keep the last 4 days of code - the rest gets deleted.

We're using MPLAB 7.20.

Re: The 8.2 (or 8.3) Battery Voltage Bug
 

We experienced this bug, I think, twice for the first time tonight. We'll be driving the robot around normally and, without warning and for no obvious reason, it will stop in place and cease responding to all inputs. The OI shows 8.3V and the Code Error light illuminates.

Since I'm not a programmer, I can't say too much about how we have things set up. We're coding manually within EasyC and using two Chicklets for control, if that makes any difference.

I've pointed our programming mentor to this thread, as well as to the document provided by IFI about changing the information in the linker file. I'll update this with more information from him as I come across it.

Re: The 8.2 (or 8.3) Battery Voltage Bug
 

We have gotten the 8.2 bug on multiple occasions. Sometimes we'll turn on the robot and it'll go freaking crazy (right track at full speed and drive the arm all the way up, fortunately it seems to obey the limit switch and not overdrive it). We'll hit the disable switch and read the OI, lo' and behold it reads 8.2.
After a complete power cycle (kill main breaker and hit the reset button to power off the RC), sometimes we have to do it twice, it'll work just fine.

I believe this code is the 2007 default plus all of the changes we've made. We did not get this bug in any previous years and we don't know what made this happen this year.

Re: The 8.2 (or 8.3) Battery Voltage Bug
 

Before this happened had you completed all the steps mentioned in this document?

-Kevin

Re: The 8.2 (or 8.3) Battery Voltage Bug
 

Help!

We now figured out why the 8.2V bug went away last time - it's because we stopped using our practice bot + controller and switched to our new one.

Today we went back to the practice bot, loaded the code that works perfectly well on our competition bot, and it immediately went into the 8.2V bug.

I've deleted and commented out huge chunks of code in an attempt to change the compiled memory footprint however it does not seem to make a difference. Nothing we do with this code seems to correct the problem.

The issue immediately goes away upon loading the IFI default code. Can someone take a look at this and see if there's anything that jumps out at you as to the cause of the issue? Thank you!

We updated the master code to check if that fixed the issue and it did not.

Re: The 8.2 (or 8.3) Battery Voltage Bug
 

Just for fun, we got our 2006 board out and used that - no 8.2 error. So we get 8.2 on the 2007 board, but not the '08 or the '06.

That makes me lean toward a silicon issue.

Kevin, if you would like our code, I can email it to you.

Re: The 8.2 (or 8.3) Battery Voltage Bug
 

Yes, please.

-Kevin

Re: The 8.2 (or 8.3) Battery Voltage Bug
 

Got your code and it looks like you didn't make the changes to the linker script discussed here:

http://www.ifirobotics.com/docs/memory_problem_8722.pdf

Also make sure you're using these libraries:

http://www.ifirobotics.com/docs/lega...es_2-24-06.zip

Let me know if you're still having a problem after you make these changes.

-Kevin

Re: The 8.2 (or 8.3) Battery Voltage Bug
 

Thanks for the help, we fixed the two errors in the code and now it works fine.

Many Thanks From Team 1718
The Fighting Pi

Re: The 8.2 (or 8.3) Battery Voltage Bug
 

Thank you Kevin. I'm a bit embarassed :o . I was told these were done... Mr. Z and myself are going to have some words when I get back...:mad: