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.