DSM2=SERIAL broken as at r1693

[GoogleCodeExporter]

Which board (stock / gruvin9x / sky9x) are you using?
gruvin9x

What is your open9x FW version?
trunk r1693

What is your open9x EEPROM version?
v212

What steps will reproduce the problem?
1. Compile with DSM2=SERIAL
2. Observe that DSM2 output on serial port is all messed up. It appears to be 
random pulses, spanning a total frame time of some 18+ms.

What is the expected output? What do you see instead?
Short bursts of 125,000 bps data, as before.

Original issue reported on code.google.com by gru...@gmail.com on 29 Nov 2012 at 10:58

[GoogleCodeExporter]

Would you check with the issue-164.patch that I attached on issue 164? Thanks!

Original comment by bson...@gmail.com on 5 Dec 2012 at 11:24

• Changed state: Started

[GoogleCodeExporter]

I cannot apply the r1712 patch, since r1712 doesn't even boot up.

The code is too complicated for me to read or understand to apply relevant 
parts manually to r1693. Sorry.

What does it do, anyway?

Original comment by gru...@gmail.com on 6 Dec 2012 at 6:18

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I found the problem and fixed it at r1722. HOWEVER, my simple fix might have 
broken something else. Seems OK to me, so far.

FRSKY and DSM2=SERIAL are not mutually exclusive. People can for example have 
exchangeable modules (DSM2 and FrSky) or in my case, an automatically switched 
TX Caddy board, to auto-select which transmitter module is to be used, 
according to what model (protocol) is loaded.

The if defines had recently been re-written as if these two options were 
exclusive. That is, only one system could be present or initialised at any one 
time. 

Since I have both FRSKY and DSM2=SERIAL enabled, it meant that NEITHER got 
initialised. Please see the r1722 diff: 
http://code.google.com/p/open9x/source/diff?spec=svn1722&r=1722&format=side&path
=/trunk/src/open9x.cpp.

This is only fixing main reset initialisation. So I'm not entirely sure what 
happens when protocols are selected from menus. It seems OK when I change to 
PPM and then back to DSM2, so far. But I am wondering if the Fr-Sky serial port 
is being re-configured correctly for non DSM2 mode models??? (9600 baud, RX and 
TX enabled.) This always used to be handled correctly. Hopefully, none of that 
code was actually changed???

Bryan.

Original comment by gru...@gmail.com on 10 Dec 2012 at 5:36

[GoogleCodeExporter]

I just tested DSM2=serial on stock the other day (where it wasn't supposed to 
be officially implemented. It's working fine, except for the one problem you 
mention, i.e. if you switch protocol from PPM to DSM the serial port starts 
putting out DSM but at the FrSky baudrate. 
So we just need to reconfigure the serial port correctly on PPM->DSM protocol 
change (DSM->PPM is OK).

Original comment by bernet.a...@gmail.com on 10 Dec 2012 at 6:49

[GoogleCodeExporter]

Then I suppose the call to DSM2_Init() was deleted at some point.

Again, this *was* all working perfectly, before. So this is all regression.
I'm not sure by whom. The fix I just committed seems to fix it for me, in
all cases I can think of testing. But I'm sure there should be a DSM2_Init
and/or a DSM2_Done() call somewhere in setupPulses()????

If whomever made the regression is reading, then perhaps they can fix it
quicker/better than I?

Bryan.

Original comment by gru...@gmail.com on 10 Dec 2012 at 7:52

[GoogleCodeExporter]

Probably the equivalent FrSky_Init in setupPulses, too ... if there is such
a thing.

Bryan.

Original comment by gru...@gmail.com on 10 Dec 2012 at 7:53

[GoogleCodeExporter]

r1712 introduces a regression, yes :) But now I see where I have to search, so 
it's good!

I will try to fix the 2 bugs described here today and will ask for some more 
testing, thanks!

DSM2_Init() should be called inside resetProto(). Wait ... I have to re-read 
that code. It's buggy, it should be called in pulses_avr through setupPulses.

Original comment by bson...@gmail.com on 10 Dec 2012 at 8:14

[GoogleCodeExporter]

Sounds like you are on the right track Bertrand. Thanks!

Bryan.

Original comment by gru...@gmail.com on 10 Dec 2012 at 8:20

[GoogleCodeExporter]

I still don't get it. When DSM2_SERIAL and FRSKY are enabled in the same time, 
the DSM2_INIT() should be called when the model is loaded (through resetProto())

Or perhaps you do the same test than Andre? (instead of loading a DSM2 model, 
he loads a PPM model and changes the protocol to DSM2, in this case, the init 
of DSM2 is not done, and that's the only bug I see now).

So my question is: if you load a DSM2 model, is the DSM2 initialization done 
properly?

Original comment by bson...@gmail.com on 10 Dec 2012 at 9:53

[GoogleCodeExporter]

@Andre: would you check on stock (both serial and PPM mode), the last issue 
should be solved!

Original comment by bson...@gmail.com on 10 Dec 2012 at 10:36

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I just updated to r1726 and ran the following tests ...

1. Configure a PPM model. Switch off. Switch back on. Check output. All OK.
2. Change model to DSM2 (serial) Check output. All OK.
3. Switch off. Switch back on. Test output. All OK.
4. Change model to PPM. Check output. All OK.
5. Switch off. Switch back on. Check output. All OK.

- - -

There is something different about my set-up that might explain test 
differences. Because I have the 9X plugged into the AVR ISP mkII programmer, 
that programmer always does a reset after it detects the 9X being powered up. 
(So I always see the "!" warning in top right corner.) That additional reset 
may sometimes mask things from me that others see, who don't have the reset 
taking place. *shrug*

Original comment by gru...@gmail.com on 10 Dec 2012 at 10:16

[GoogleCodeExporter]

Mmh, disconnect the programmer then?

r1726 is ok for this for me too, I just have one other problem, a "noise" in 
the speaker (AUDIO mod) when compiled with DSM2=SERIAL, and powering the radio 
up with a DSM model selected and an alarm happens Quite a lot of conditions 
indeed...

http://www.youtube.com/watch?v=JMqXqF_4Kfg

Original comment by bernet.a...@gmail.com on 10 Dec 2012 at 10:24

[GoogleCodeExporter]

DSM2_Init / FRSKY_Init are called within the interrupt, would it be a problem?

Original comment by bson...@gmail.com on 10 Dec 2012 at 10:36

[GoogleCodeExporter]

Original comment by bson...@gmail.com on 17 Jan 2013 at 11:06

• Changed state: Fixed