The 8.2 (or 8.3) Battery Voltage Bug

[Kevin Watson]

Originally Posted by kaszeta

As for 18f8722_2.44.lkr, if you try to use it as provided, you get a "Error - section '_entry_scn' type is non-overlay and absolute but occurs in more than one input file" from the linker, which requires that you comment out the first "FILE" line in the .lkr script. After that, IFI Loader won't upload it, giving an "invalid address : 0x20 (Correct Range: 0x800-0x7fff)" error.

Okay, I see the problem with the file. If you can, try the 18f8722beta.lkr script.

-Kevin

[Rickertsen2]

Well programmers, there is upshot to this. For once there is a programming problem that might not be our fault!

What leads people to think that this is a problem with the linker script? It seems to me like there is a good chance this could be a master proc problem.

Its interesting to note that 8.2/8.3 volts is very near 127 when you convert it using that little forumula. Is it possible that the RC and OI are somehow loosing synchronization and reading the wrong parts of the packets? Maybie some structure or array is being manipulated incorrectly?

Make sure you are using the newest version of IFI loader. I had some bizarre similar problems from using an old version. I have also had weird errors from USB->serial converters. Rule these things out first.

[kaszeta]

Originally Posted by Rickertsen2

Make sure you are using the newest version of IFI loader. I had some bizarre similar problems from using an old version. I have also had weird errors from USB->serial converters. Rule these things out first.

I haven't been able to recreate the problem using the older IFI loader (but all the code I've used so far, even when I was still using trig functions, still fit in bank 0).

And our laptop is still old enough to have a serial port...

But yes, both of these are worth ruling out.

[kaszeta]

Originally Posted by Kevin Watson

Okay, I see the problem with the file. If you can, try the 18f8722beta.lkr script.

Script seems to work fine (produces hex files that seem to work), but since I currently haven't been able to duplicate the bug then I can't tell if it cures it.

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

[eugenebrooks]

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

We can't check for the bug with the beta loader on our robot controller
as our robot is in the crate heading from Portland to SanJose.
I did try building the hex file with the beta <linker> script, however, and
note that there is a large number of differences in the hex file, relative
to the one generated prior to copying the beta <linker> into place.
If IFI fixed a bug in the linker script with their change, our code was
stepping on this bug in lots of places.

We will learn the score, for sure, during the practice day at the
SanJose regional...

Eugene

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