Alieron Trim moves without input from user

[GoogleCodeExporter]

*SVN:Trunk-r478
VERS:V1.2-gruvin
BLD:285
DATE:14.01.2011
TIME:09:09:19

What steps will reproduce the problem?
1.If i copy a model without the fault and rename the model and sooner or later 
the alieron trim will start moving in flight.  
2. Only one model is affected
3. The issue was noted by Erazz 
http://www.rcgroups.com/forums/showpost.php?p=16679620&postcount=3215
http://www.rcgroups.com/forums/showthread.php?t=1266162&page=218

What is the expected output? What do you see instead?
For the Alieron not to move without input

What version of the product are you using? On what operating system?
Turnigy 9X (version 2 firmware) obviously the firmware is gone. TX is about 6 
months old and this issue only occoured after flashing.

Please provide any additional information below.

Original issue reported on code.google.com by flame_ha...@yahoo.com.au on 28 Jun 2011 at 2:45

[GoogleCodeExporter]

I've asked the submitter if he can provide before and after EERROM dump files 
in hopes of being able to replicate this bug.

I've also asked him check if there's any sign of possible "off screen writing" 
happening on the LCD as the sticks are moved, using the model set-up that 
relates to the fault. (That will require checking all related screens of 
course.)

I'm also aware that a screen-overwrite bug fix has recently been contributed by 
bsongis, but that's no in the trunk version yet. Could be the same bug?

Thanks for the help. :D

Original comment by gru...@gmail.com on 28 Jun 2011 at 5:53

[GoogleCodeExporter]

I dug out the definite off-screen rending bug fix that bsongis made in 
branches/frsky r559 and have now ported that to the trunk code. This is FAR 
more likely to be the cause of the trims moving on their own fault than my 
previous fix from er9x issue 180. HEX ''binaries'' updated to the build 
revision.

New trunk/*.hex files uploaded for this version as at r591.

I'm much more confident this fix will actually do the job. Please let us know.

Original comment by gru...@gmail.com on 28 Jun 2011 at 9:32

• Changed state: Started

[GoogleCodeExporter]

I should note that this last change may not fix this specific issue. There 
might be yet another bug to find. But here's hoping.

Also, note that this issue, assuming it is caused by off-screen writing (very 
likely), should only occur on one specific display screen -- and most likely on 
one of the more graphical stick position pages, at that. The one with 
horizontal bars showing channel output is probably the most likely culprit, 
since it has graphics closer to the screen edges.

Original comment by gru...@gmail.com on 28 Jun 2011 at 9:40

[GoogleCodeExporter]

Was due to the lcd_vline function which wrote over the display memory limit 
when called with h=57 and l=7 (which is called 4 times - the 2 horizontal trims)
Bertrand.

Original comment by bson...@gmail.com on 1 Jul 2011 at 9:06

• Changed state: Fixed

[GoogleCodeExporter]

Original comment by gru...@gmail.com on 23 Sep 2011 at 1:52

• Changed state: Verified