Here's what we found Thursday night
(1) Same observation on powering up with reset depressed. Doesn't seem to make a difference.
(2) Tracing program flow with printf statements sprinkled throughout Process_Data_From_Master_uP(), we see that it always executes successfully the first time through.
(a) In the no-fault case, Process_Data_From_Master_uP() continues to get called like clock work
(b) In the CODE ERROR case, Process_Data_From_Master_uP() only gets called once. (or possibly it continues to get called but the printf's stop because of a serial port hangup)
(c) In the garbled rxdata case, the first packet comes in OK but from the second packet forward the OI mappings are corrupted. Data fields are always mis-aligned in the same fashion but it's not as simple as a byte shift.
I have incorporated a trap that detects five consecutive packets with 127 in the packet_num field and goes into an infinite loop if this occurs. This forces a code error if the rx packets are corrupted so we know to re-cycle the power. I plan to further refine the logic to only enable the trap during the first few cycles; once we get off to a good start we seem to run OK till the next power-up.
Does your RC ever come up OK with proper OI mappings?
Neil
Quote:
|
Originally Posted by drinkdhmo
We have explored the problem a little more fully today and have found a few more details:
Powering up the robot with the reset button depressed, then releasing it, still results in a code fault.
The processor results in a code fault only when the controller has been off for more than 5 seconds after running for more than a few minutes. We did some extensive testing and timing and a power cycle (with the breaker, not the reset button). When the processor has not been on as long, more time powered down is required to reproduce the code fault. We could not reproduce the code fault at all by holding down the reset button for an extended period of time (about a minute).
Along with joystick 1's y-axis being mapped to p1_x, we have also noticed that joystick 3's x-axis is being mapped to p1_y. We have not yet explored all of the oi input mappings, but we will post it when we do.
We also found that when we powered up the rc without a radio modem or tether connected, the program does not fault. When we reconnect the radio modem the program will fault again, but only after the processor has been powered down for a varrying period of time.
Whether the code faults on startup or not, the OI input mappings are still messed up.
This is all we have found so far. I will continue our exploration of the problem tomorrow and post anything new.
|