The 8.2 (or 8.3) Battery Voltage Bug

[Eldarion]

Originally Posted by kaszeta

Anyone yet found a highly reliable way to duplicate this? (very frustrating, since it was showing the error reliably in the pit)

Try uploading Kevin's frc_gyro.hex as many times as necessary to cause the error. (See previous post; I have also confirmed that this causes a similar "bug" on the 2004 RC)

Was the robot tethered when you had the bug, or was it on the field with the radio?

[kaszeta]

Originally Posted by Eldarion

Try uploading Kevin's frc_gyro.hex as many times as necessary to cause the error. (See previous post; I have also confirmed that this causes a similar "bug" on the 2004 RC)

I tried it a bunch of times last night without triggering it,

However, (1) I only tried it with the tether (the radio modem pair I scrounged up at the clubhouse appears not to be working), and (2) I don't have a backup battery handy, but I did vary the voltage on the backup battery lugs by (a) hooking a +5V signal from the pwm outputs to it, (b) hooking up a 1.5v battery, and (c) hooking up a 9V charger to the pins

I'll try it again today with an actual battery and see if massive repeated uploads of frc_gryo.hex do it.

Was the robot tethered when you had the bug, or was it on the field with the radio?

Both, and oddly, I saw the error about half of the time.

[EricS-Team180]

Originally Posted by Mike Bortfeldt

.....from page 2.....
...As you move the joystick 4 wheel, the OI battery voltage changes. The p3_wheel is mapped to the backup battery voltage (as shown from the data in the dashboard). the p1_x axis now maps to the joystick #3 switches. ...

Correction - Rather than the p3_wheel & p4_wheel, it is actually the p3_aux and p4_aux.

This doesn't directly relate to these microprocessors, but...
This reminds me of something I once encountered with PowerPC's, running VxWorks OS.
It had to do with how you saved the data registers when a function was
interrupted by a function with higher priority.
You could request that the interrupted functions's registers be saved as an "integer save" or a "floating point save". If you used an "integer save" and you had any floating point registers that you were using, your saved data was
corrupted.......a very low level and weird bug.

So...
How are the registers saved on the User proc when it is interrupted by the master proc for data i/o? A pointer hack, overflow or corrupted save could certainly be changing the apparent mapping of the i/o data. And, it could be reproducible on any of the pic FRC's (I believe ElDarion reproduced the problem on a 2k4)

...just my 2cents

[ericand]

Originally Posted by Kevin Watson

Can those folks who are having problems please try building your code with the attached 18f8722beta.lkr link script and testing your code. If you still have problems, then try the attached 18f8722_2.44.lkr script and test again. Please report back here with the outcome.

-Kevin

Our problems seem to be helped by changing the linker script. The symptoms
indicate that txdata and/or rxdata are being corrupted. In our robot,
the .map file indicates that txdata is at 0xf00 (gpr15 right above the stack).

Normally I would suspect a stack overflow into the txdata, but the PIC
addressing modes can't allow the stack to escape its bank.

On the theory that there is something strange about the memory in gpr15,
we changed our linker script to disallow data in gpr15. This seemed to fix
things, but we were out of time so we don't have enough testing to be 100%
sure. My fear is that we have just changed the symptom, but not eliminated
the problem.

[Mark McLeod]

If gpr15 is suspect (or really 14) we can nail a diagnostic data array into that space and test periodically to see if an overwrite of that bank occurs. I was thinking of using databanks before and after to isolate our user code from "outside" corruption.

[ericand]

Check out IFI web site for an update. They are saying
to use the linker change (protect gpr15) and the new
libraries that resolve the interrupt issue.

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

[Kevin Watson]

Originally Posted by ericand

Check out IFI web site for an update. They are saying
to use the linker change (protect gpr15) and the new
libraries that resolve the interrupt issue.

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

Please let IFI or myself know if this does not fix the problem.

-Kevin

[Rickertsen2]

I'm not sure i correctly understand this issue. Is it a problem with the 18f8722? Why does not using the gpr15 area fix this?

[ericand]

What we are hearing from IFI is that the problem is at least partly associated with
the oscillator that controls timing in IFI controller. It seems that it can drift, and that
the drift is related to temperature.

The data that is getting corrupted is the inter-processor communication data which tends to be stored in gpr15.

I too am curious about why moving those data structures (by protecting gpr15) seems
to solve the problem and not just move it somewhere else. It may have something to
do with the fact that gpr15 is located adjacent to the locations the registers are memory mapped to.

I'm hoping that we will have more clues about what works and what doesnt over the course of the next few regionals, but I feel sorry for teams that are affected by this
problem. Our robot was impacted by this in about 1/3 of our matches in Portland.

[eugenebrooks]

Different data segments might have slightly different address/data
timing margins and moving the data to a different segment could be
resolving the timing issue if that is what it is. Lets hope that the
patch resolves the problem. We were also at Portland and got hit
quite severely by this bug on Thursday afternoon. After trying a
loaner RC and seeing the same problem we gutted all of our feedback
code to obtain a robot that ran reliably. This severely impacted our
performance by taking all of our cameral directed shooting off line
and forced us to resort to a defensive strategy. If the linker patch
works around the problem we will have a very different robot.

Given the temperature sensitivity perhaps I should bring one of my
leg warmers to strap to the robot controller...

Eugene

Originally Posted by ericand

What we are hearing from IFI is that the problem is at least partly associated with
the oscillator that controls timing in IFI controller. It seems that it can drift, and that
the drift is related to temperature.

The data that is getting corrupted is the inter-processor communication data which tends to be stored in gpr15.

I too am curious about why moving those data structures (by protecting gpr15) seems
to solve the problem and not just move it somewhere else. It may have something to
do with the fact that gpr15 is located adjacent to the locations the registers are memory mapped to.

I'm hoping that we will have more clues about what works and what doesnt over the course of the next few regionals, but I feel sorry for teams that are affected by this
problem. Our robot was impacted by this in about 1/3 of our matches in Portland.

[Eldarion]

Originally Posted by ericand

What we are hearing from IFI is that the problem is at least partly associated with
the oscillator that controls timing in IFI controller. It seems that it can drift, and that
the drift is related to temperature.

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!

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

[Rickertsen2]

Originally Posted by Eldarion

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!

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

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.

[Gdeaver]

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.

[rangersteve]

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.

[kaszeta]

Originally Posted by Rickertsen2

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.

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