Some protocols doesn't work in devo7e (modular build) about deviation HOT 20 CLOSED

@hexfet @goebish

from deviation.

See PR #487

from deviation.

@goebish did u verify wfly works in modular build?

from deviation.

I don't see why it wouldn't work in modular build only, it does nothing particular.

from deviation.

One guess is that wfly protocol did not pick the channels based on rssi. On my devo7e the tax power is only 10mw and my WiFi is much stronger. It cause receiver cannot gets the signal. Possible?

from deviation.

None of the protocols pick up the frequency based on RSSI (bind frequency is fixed anyway), I don't think that's the issue.
I don't have a WFLY receiver nor a 7e, just for testing, can you try to set MAX_WAIT_WRITE to 100 here ?
https://github.com/DeviationTX/deviation/blob/master/src/protocol/wfly_cyrf6936.c#L198

from deviation.

I tested to set it to 100. Doesn't work still. and I found more serious problem with WFLY (or something else).

Here repro steps:

1. flash zip package to devo7e.
2. configure the model1 to use WFLY as protocol.
3. run 'Bind' twice. (no receiver so it will never success). First bug: the wait time is so big. "Press ENT to stop 1492 seconds left".
4. Exit to main menu and select channel monitor. you will find only ch1 has the input when you move two sticks. I found it is caused model1.ini is somehow corrupted.

The model1.ini for your reference:
https://pastebin.com/raw/YFyjcjAz

from deviation.

More information from error.txt. Any idea?
[Soft fault]
devo7e-v5.0.0-ebc99d2
R0 = 40003800
R1 = 00000083
R2 = 000005dc
R3 = 00000002
R12 = 0000ffff
LR [R14] (subroutine call return address) = 200045fd
PC [R15] (program counter) = 0801bfdc
PSR = 61000000
BFAR = e000ed38
CFSR = 00000000
HFSR = 00000000
DFSR = 00000000
AFSR = 00000000
SCB_SHCSR = 00000000
Top of Stack:20004000
Stack Detect:20003f20
Backtrace:
20003f7c : 0800d8c7
20003f84 : 0800e2d5
20003f94 : 0800e36f
20003f98 : 0800e34d
20003fa4 : 0800929b
20003fbc : 08009375
20003fdc : 08009d93
20003fec : 08009e85
20003ffc : 0801c7ff
20003ffd : 080801c7
Done

uint16_t spi_xfer(uint32_t spi, uint16_t data)
{
spi_write(spi, data);

/* Wait for transfer finished. */

PC --> while (!(SPI_SR(spi) & SPI_SR_RXNE));

void CYRF_WriteRegister(u8 address, u8 data)
{
CS_LO();
LR --> PROTOSPI_xfer(0x80 | address);
PROTOSPI_xfer(data);
CS_HI();
}

from deviation.

I think I understand the problem, the protocol lacks CLOCK_StopTimer() at the beginning of the void initWFLY(u8 bind) function, can you try to add it and check if it works ?

from deviation.

or checkout this branch:
https://github.com/goebish/deviation/tree/protocol_wfly_fix

from deviation.

your fix fixes the issue that causing wdog timeout and reset.

the model corrupted issue looks like unrelated to wfly. I can repro with DSMX. let me look closely.

from deviation.

this sort of bug makes me thinking that we should abstract the state machine out of each protocol and handle the interaction with the hardware by the common shared code.

Let's say having a component called base_protocol. It includes the logic on Bind, AutoBind, hardware choose.

Each protocol need take care of how to initialize the hardware in the different mode (bind, tx, rx, etc), how to generate the package for different purposes, how to parse the telemetry packets.

as our protocol is largely inherit from Multi, loop @pascallanger if he has additional comments or suggestions.

from deviation.

I merged the fix for WFLY protocol.

from deviation.

@goebish I confirmed the regression is caused by my change on channel map. I am working on it now but still no clue. It looks like related the difference between new and old implementation on keeping sync between channel map and current protocol.

from deviation.

The bug does not exist in non modular build like F12e or emulator. I read the code couple of times, still no idea where is the issue. The code I changed is very similar for modular and non modular part, not sure what cases it...

from deviation.

In a modular build the linker is putting TAERG in the protocol RAM space for some protocols. It won't be initialized.

Strangely some protocols that don't use TAERG channel order are also in the list. Restoring the "static" qualifier to TAERG in protocol.c changes the build so that only the TAERG protocols are in this list.

It seems that line 35 in protocol/interface.h is causing allocation of TAERG in the modular build. Shouldn't both this line and line 34 be "extern"? But with that change the linking of the dsm protocol fails because TAERG is not defined. Not sure why because it looks like protocol.c is included in the link. Out of time to look now.

from objs/t8sg_v2_plus$ for a in *elf; do echo $a; readelf -s $a|grep TAERG; done

assan_nrf24l01.elf
   918: 2000475c     5 OBJECT  GLOBAL DEFAULT    2 TAERG
dsm2_cyrf6936.elf
   961: 20004fcd     5 OBJECT  GLOBAL DEFAULT    2 TAERG
esky150_nrf24l01.elf
   957: 200047b6     5 OBJECT  GLOBAL DEFAULT    2 TAERG
hm830_nrf24l01.elf
   935: 20004819     5 OBJECT  GLOBAL DEFAULT    2 TAERG
kn_nrf24l01.elf
   956: 20004964     5 OBJECT  GLOBAL DEFAULT    2 TAERG
ppmout.elf
   897: 200043dc     5 OBJECT  GLOBAL DEFAULT    2 TAERG
usbhid.elf
   924: 200045c9     5 OBJECT  GLOBAL DEFAULT    2 TAERG
wfly_cyrf6936.elf
   909: 20004840     5 OBJECT  GLOBAL DEFAULT    2 TAERG

Protocols with TAERG channel order

[src]$ grep -lr TAERG protocol/
protocol/dsm2_cyrf6936.c
protocol/esky150_nrf24l01.c
protocol/protocol.c
protocol/interface.h
protocol/kn_nrf24l01.c
protocol/hm830_nrf24l01.c
protocol/protocol.h

from deviation.

The assan and wfly protocols are not tight to any channels order so I'm surprised to see them in the list...

from deviation.

It is fine. here the channel mapping is the default channel order when user select the protocol. Maybe we can mark channel mapping as UNCHG (unchanged) for that protocols like SBUS and CSRF?

@pascallanger WFLY works but the range is smaller than original WFLY Tx. I believe we need do some additional work here. If you have some SPI dumps, maybe I can help. I have WFLY receiver and devo7e/f12e to test with.

from deviation.

Maybe we should implement fine frequency tuning for this protocol (can be controlled with registers 0x1b & 0x1c with the cyrf6936).
https://www.deviationtx.com/forum/protocol-development/7150-eachine-e012?start=40#63007
That would be the first time a cyrf6936 protocol requires it tho.

from deviation.

The serial protocols have been fixed in modular builds by #599.

from deviation.