OpenTX 2.0.10 and 2.0.11 with more than eight channels active

[andrewfernie]

I updated to 2.0.10 and ran into trouble controlling more than eight channels.
Configuration is Taranis with an X8R. There is a SBUS to CPPM adapter to my APM (channels 1-8) and a SBUS to PWM adapter to control my camera gimbal (channels 9-12). I use only the internal RF module, set for D16, and with channels 1-16 selected.

With 2.0.8 it worked fine. With 2.0.10 sometimes I had control of the gimbal, sometimes the APM, most of the time nothing, and never both. Disconnected the SBUS to PWM adapter and no improvement - APM sees nothing. Set the channel count to 1-8 and it was fine. Increased the channel count and lost control of the APM. Checked at the output of the SBUS to CPPM adapter and the pulses looked like the failsafe values. The green light on the RX is always on steady.

Went back to 2.0.8 and everything worked fine. Went back to 2.0.10 and same problems as above. Went back to 2.0.8 and all good.

2.0.11 came out today and it behaves the same way. Switching back to 2.0.8 gets all channels working.

[bsongis]

I suspect the compiler again, I didn't change this code, while we changed the compiler between 2.0.8 and 2.0.10

May I ask you your email, I will send you a 2.0.10 compiled with the previous compiler so that you will double check

[driver33]

I have faced this same last week when start to use sbus and more than 8 channels on my own compiled FW. Only 8 channels work, highest possible , for example 9-16 or 5-12, depends on the settings. I took clean official Fw 2.0.8, installed and got 16 channels working perfecty. Just for test i compiled vanilla 2.0.8 from source and problem come back. So definitly its some strange problem with my compiller which i was unable to locate.

[bsongis]

Yes I reproduce here with my compiler. I am downgrading my computer to check the issue is fixed. If yes I will downgrade the compilation server as well. This is the 2nd bug which comes with arm-gcc 4.8 :(

[bsongis]

Confirmed, no problem with gcc 4.7.4

[andrewfernie]

Thank you Bertrand. It is andrewjfernie@gmail.com

Andrew

On Sep 11, 2014, at 2:40 AM, Bertrand Songis notifications@github.com wrote:

I suspect the compiler again, I didn't change this code, while we changed the compiler between 2.0.8 and 2.0.10

May I ask you your email, I will send you a 2.0.10 compiled with the previous compiler so that you will double check

—
Reply to this email directly or view it on GitHub.

[bsongis]

Meanwhile I tested it myself and horror I had the same result. I switched the server back to the 4.7.4 compiler instead of 4.8, all previous bins are removed, so if you download again your firmware from Companion, it should be ok. Would you confirm? I will release a 2.0.12 to make sure everybody is up to date

[andrewfernie]

Tried a download of the new 2.0.11 and everything works fine. Thank you for the fast response!

[markab]

So is there is fix for this or just downgrade?

[andrewfernie]

No downgrade. It works fine now with the current release.

[projectkk2glider]

Yes I reproduce here with my compiler. I am downgrading my computer to check the issue is fixed. If yes I will downgrade the compilation server as well. This is the 2nd bug which comes with arm-gcc 4.8 :(

@bsongis do you have any idea what is causing this problems with newer gcc? Might this problems be just a symptom of a well hidden bug in opentx code? I find it hard to believe that a tool-chain has a bug that is causing this issues.

Do you think that a disassembly of opentx code (especially the interrupts part) made by different tool-chains would give us some clues?

[bsongis]

@projectkk2glider
You are right, that's why I didn't write it was a gcc bug, but a bug which comes with gcc 4.8 :)
And yes I do agree, we should check the ASM code, it will be really easy with the 9XR-PRO sound bug which is in a very very short interrupt (OPT=1 makes it work on 4.8), but I had too much work with the issues raised on 2.0.10 and 2.0.11 so I decided just to go back to the 4.7.4
I think now that I won't change the compiler again like we did, without enough tests, I was too much confident! I will install the 4.8 version of the compiler in another place on the compilation server so that we will be able to use both in parallel.

[davxlw]

Hi,
One person at the FrSky forum had the same problem:
http://www.frsky-rc.com/BBS/viewtopic.php?f=4&t=5725&sid=2d7c2995b65f7de5b60c50c7b46cc4ed

I wonder if the opentx-x9dp-v2.0.9 firmware haven't been compiled with the 4.8 version and so could cause trouble for new Taranis plus users ?

[kilrah]

No, from what he says he simply tried to bind his receiver in the wrong mode (D8).
Likely rebound correctly after flashing, and wrongly deducted it came from the firmware.

[davxlw]

But he talks about D16 for the Taranis and binding his X8R in mode 3 and mode 5, which are D16 modes...
The "only higher 8 channels working" is exactly what is described here.

[kilrah]

Ah yes, confused 1 and 5.

Anyway the compiler was only changed after 2.0.9, FrSky know about the issue, and nobody else including us during our own testing has reported the problem with the stock 2.0.9 firmware... so IMO it's user error somewhere.

[davxlw]

Ok, I just wanted to let you know 😉