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
Quote:
|
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.
|