[ericand]

We have been running tests on a controller that has shown the 8.2V issue
and which has been getting intermittent code errors to try to determine if
or how our code is going wrong.

What we determined after much experimentation is that there is some sort
of hardware issue with the controller. We observed:

The code ran better when the controller was warm. We noticed that
code errors seemed to decrease when the controller had been
continuously operating for a period of time. We tested this by
cooling the controller and noticing that the incidence of code errors
went up. The cold controller would error immediately. The warm
one would error intermittently.

Older code which we thought didn't have problems was actually
seeing corruption in the data being sent to/from the OI. We noticed
this by seeing a correlation between joystick movement and feedback
LEDs that is not programmed into our code. With this in mind, we
looked at the feedback response with the code that has been
getting the code error and noticed that feedback LEDs that should be
lit continuously were blinking off intermittently.

Our theory is that the data segment that contains the txdata, rxdata, and the
status flag is somehow getting corrupted. Our map file shows this data is
located in gpr15 (above the stack? near the register access??).

We ran an experiment and changed the linker script by eliminating gpr15
(I commented it out, I'm not sure if that is the best solution). We then ran
the code on a cold processor and did not see any strange behavior. LEDs
that were supposed to be lit were lit and stayed lit. There were no strange
relationships between controls and LEDs. txdata etc are now located in gpr2
at 0x200 instead of gpr15 at 0xf00. I think I need to run more tests, but I
find these results interesting.

I now see that there are new linker scripts from Kevin and one of them marks
gpr15 as protected. Is there something known or suspected about data
integrity in gpr15? I don't have the controller here, but a quick recompile and
look at the map indicates that 18f8722beta.lkr moves the txdata into gpr2 like
the change I had made.

We need to run more tests, but I would really like to hear any comments on
our analysis.

B.T.W - we did run timing checks on our main loops including the process
data from master up() and we determined that our maximum loop time was
11ms with an average loop time less than 5ms so we are sure that we were
not getting the code errors from running too long.


Thanks for your help.

Eric Anderson - 1425 Wilsonville Robotics