Developing a universal module

@M you're everywhere, shouldn't you be working like a slave ?

I just got back from vacations and I already miss the "far niente", good times go away to fast

I have very similar issues as phantom8 with the MultiModule on my Devo 8S, using the very same modules (and even when disabling CC2500) using Deviation built from recent source (3b623a8d08f5).
The MultiModule is detected, but any RF module besides A7105 is not, pressing OK will let transmitter go stuck - powering off takes some seconds then.
Even when using my 'old' module which has PA-less A7105 and nRF the CYRF is no longer detected when using my custom build. This module was working before (using custom build from around one month ago), besides some issues with V2x2 protocol.

Note that I have double-checked all connections on MultiModule to be fine.

I tried some variations on hardware.ini, but even when disabling all modules (and not enabling MultiModule) it complains about missing MultiModule and missing CYRF (having MultiModule disconnected). Did I miss a change with hardware.ini or default behavior ?
Reprogramming AVR via Devo works, as such the SPI must be working somehow, even that it looks at first glance that MISO is somehow misbehaving (A7105 uses MOSI pin for in and out)

I have local changes, but they should not affect module detection at all (New protocols / options added for testing).
Sadly I'm _very_ low on time right now, but I'll test with older revisions tomorrow (In case my family gives me some spare time )

btoschi wrote: Sadly I'm _very_ low on time right now, but I'll test with older revisions tomorrow (In case my family gives me some spare time )

And you have to work on some protocols too : UDI, MJX

SeByDocKy wrote: And you have to work on some protocols too : UDI, MJX

True.
Luckily the Jiayuan "Guard of Space" Quadcopter I got very cheap is a simple V202 rebrand, as such no new protocol added to my list, same with NincoAir Quadrone (V222 rebrand with huge canopy). *phew*

Update on Deviation issue:

I downgraded deviation source to changeset from Apr 17 usingI have no longer problems with CYRF not being detected and all modules but the CC2500 are detected properly (which is the same status as I had before with this module, the other one has no CC2500 on it).
Having CC2500 enabled lets TX reboot immediately after pressing "OK" Button.
Disabling CC2500 will lead to TX complaining about missing CYRF and missing NRF, and reboot after pressing "OK" Button.

Someone able to give me a "crash-course" on how deviation boots up / debugging this issue can go on (That's my usual job, when I'm not writing new Bugs. err. Software ) ?

btoschi wrote: Update on Deviation issue:

I downgraded deviation source to changeset from Apr 17 using

hg checkout 2311:c76900a50e89

I have no longer problems with CYRF not being detected and all modules but the CC2500 are detected properly (which is the same status as I had before with this module, the other one has no CC2500 on it).
Having CC2500 enabled lets TX reboot immediately after pressing "OK" Button.
Disabling CC2500 will lead to TX complaining about missing CYRF and missing NRF, and reboot after pressing "OK" Button.

Someone able to give me a "crash-course" on how deviation boots up / debugging this issue can go on (That's my usual job, when I'm not writing new Bugs. err. Software ) ?

I think, in my first attempt to build the MM, I had such behaviour. Everything was ok until I installed the CC2500. In this case, the TX was rebooting like you after pressing OK. You should check your CC2500 connextion. Do you try the MM with closed devo ? coz I found that the cover was pressing on the MM especially on the CC2500 ....

btoschi wrote:

SeByDocKy wrote: And you have to work on some protocols too : UDI, MJX

True.
Luckily the Jiayuan "Guard of Space" Quadcopter I got very cheap is a simple V202 rebrand, as such no new protocol added to my list, same with NincoAir Quadrone (V222 rebrand with huge canopy). *phew*

Good to know. I will add them in the Supported model list

S-2 model

www.toy63.com/cp/html/?5586.html

SeByDocKy wrote: You should check your CC2500 connextion. Do you try the MM with closed devo ? coz I found that the cover was pressing on the MM especially on the CC2500 ....

I've triple checked all MM connections with my multimeter, all is looking okay to me.

The Multimodule is outside of my devo (case still openede, of course), since I have soldered ribbon cable with motherboard connector into my devo so I can switch MultiModules easily.
On first attempt I only had non-PA RF modules laying around, so I though about an easy way to switch the Multi Module later.

Interestingly when I disable all modules besides the MultiModule, I can use CYRF protocols once (possibly after unplugging batteries / waiting a while) (see below) - even w/o having MM connected, but when I power cycle the TX, I get a complaint about missing CYRF and MM plus reboot again.
I have even replaced batteries (eneloop, at > 5.1V).

Edit:
Found the "solution":
Having throttle not fully pulled down, the safe value warning screen appears (seems to hinder the other to show up ???)

Edit2:
Found the solution to the "missing CYRF" issue: My USB connection (!)
When having original Walkera USB cable plugged into my PC front panel, I'm getting missing CYRF, simply unplug the cable and all is fine.
MM with RF modules is detected properly (CC2500 still not found).

The TX does reboot when selecting any NRF-based protocol (even when MM is not attached). FlySky is partially working (can toggle lights on my V959), but throttle has no effect at all.

My old MM is sometimes not detected on startup - but A7105 (FlySky/V959) and nRF (V272) are working as expected.

This reduces my issues to my second multi module and the CC2500 plus NRF combination.

Edit3:
Testing with recent version from PB's repository (changeset: 2332:3b623a8d08f5) shows no real difference, besides the reboot when using nRF is no longer there (endless loop waiting for Packet ACK refactored into simple check in callback - great !).
V2x2 bind stays at "0" forever and does not work - nRF seems to be not reacting at all.

I'll attach my LA then ...

Modules are no longer detected when having Logic Analyzer attached.
Ground / USB issue again, I guess.

I can see the nRF Module is sent SPI commands E1, E2, FF, 07 FF, 20 08 (which look fine to me) and always returns 20 as status via MISO.

btoschi wrote: Edit3:
Testing with recent version from PB's repository (changeset: 2332:3b623a8d08f5) shows no real difference, besides the reboot when using nRF is no longer there (endless loop waiting for Packet ACK refactored into simple check in callback - great !).
V2x2 bind stays at "0" forever and does not work - nRF seems to be not reacting at all.

I'll attach my LA then ...

Your V2x2 binding problem is the same as mine. This is because the CE pin of the NRF chip has been mistakenly set to active low when you pressed the bind button. Refer to my previous post for details.

phantom8 wrote: Your V2x2 binding problem is the same as mine. This is because the CE pin of the NRF chip has been mistakenly set to active low when you pressed the bind button. Refer to my previous post for details.

True.
This issue looks like a regression from change 2231 which introduced reset of modules on initialization.
v202 code never calls NRF24L01_SetTxRxMode(TX_EN), but NRF_Reset() calls NRF24L01_SetTxRxMode(TXRX_OFF), thus radio stays disabled.
Disabling CE_lo() will keep radio "alive" and the config register is written by protocol initialization code, thus all is fine.

Proper fix is to call NRF24L01_SetTxRxMode(TX_EN) in v202_init() v202_init2(), the same applies for every other NRF protocol, besides NE260.

btoschi wrote:

phantom8 wrote: Your V2x2 binding problem is the same as mine. This is because the CE pin of the NRF chip has been mistakenly set to active low when you pressed the bind button. Refer to my previous post for details.

True.
This issue looks like a regression from change 2231 which introduced reset of modules on initialization.
v202 code never calls NRF24L01_SetTxRxMode(TX_EN), but NRF_Reset() calls NRF24L01_SetTxRxMode(TXRX_OFF), thus radio stays disabled.
Disabling CE_lo() will keep radio "alive" and the config register is written by protocol initialization code, thus all is fine.

Proper fix is to call NRF24L01_SetTxRxMode(TX_EN) in v202_init() v202_init2(), the same applies for every other NRF protocol, besides NE260.

Good find

Now on the UDI !!!! protocol

btoschi wrote: True.
This issue looks like a regression from change 2231 which introduced reset of modules on initialization.
v202 code never calls NRF24L01_SetTxRxMode(TX_EN), but NRF_Reset() calls NRF24L01_SetTxRxMode(TXRX_OFF), thus radio stays disabled.
Disabling CE_lo() will keep radio "alive" and the config register is written by protocol initialization code, thus all is fine.

Proper fix is to call NRF24L01_SetTxRxMode(TX_EN) in v202_init() v202_init2(), the same applies for every other NRF protocol, besides NE260.

Well done! Just tested your fix and it's working well. Thanks for the proper fix.

btoschi wrote:

phantom8 wrote: Your V2x2 binding problem is the same as mine. This is because the CE pin of the NRF chip has been mistakenly set to active low when you pressed the bind button. Refer to my previous post for details.

True.
This issue looks like a regression from change 2231 which introduced reset of modules on initialization.
v202 code never calls NRF24L01_SetTxRxMode(TX_EN), but NRF_Reset() calls NRF24L01_SetTxRxMode(TXRX_OFF), thus radio stays disabled.
Disabling CE_lo() will keep radio "alive" and the config register is written by protocol initialization code, thus all is fine.

Proper fix is to call NRF24L01_SetTxRxMode(TX_EN) in v202_init() v202_init2(), the same applies for every other NRF protocol, besides NE260.

Do you have a patch I can take a look at?

Here's a patch which enables Radio for all NRF protocols which did not call enable before (diff against current revision from PB's repository).
I tested V2x2 protocol with my V272, which works fine, and YD717 with my SH6044 (which binds, but control is not accurate due to protocol differences I'll need to figure out) but the general strategy was simple: Place the enable right before PWR_UP bit gets set, so it should do the expected thing.

Note that some registers are written multiple times now (many init2() methods flushes pipes, which NRF24L01_SetTxRxMode(TX_EN) does, too, same with PWR_UP / CRC setup).
But I found that when removing the second write to the config register for V2x2 (after calling TX_EN) the fix no longer works. Maybe a timing issue. But before checking this and cleaning up code, we need ppl to test the other protocols, I'd say.

It's possible to have the devo 7E and 10 build including this patch ? coz I guess PB is extremely busy last days (or in vaccations

I've tested the YD717 (with yd717) and Hisky (v922) protocols on a Devo 10 with the patch applied to the latest PB repo. I don't have the multi-module installed yet. Worked well. Good find.

Builds attached for 7e and 10.

Since my MM with CC2500 is still not working properly, I've added some more debugging printout and found out that one issue which causes a module to not being properly detected is that SPI_ConfigSwitch() fails before (byte1 is not a5).
It seems like in that case we're not talking with MM, but someone/thing else ...
But that is not the only issue here.
Here is a sample printout (Since I've prefixed my output by method name it should be easy to follow even w/o exact source modification) where most MM communication seems to be working, but still chips won't "talk back" properly.
This is my second MM with CC2500, NRF24L01 and A7501 (latter one w/o problems) and Devo8S displays Missing Modules: CYRF6936 CC2500 NRF24l01, pressing "ok" button runs into hard fault as I've selected a model which uses one of them (no matter if CYRF or NRF, it reboots and then runs into very same problem again).

I wonder why the MM gets programmed for the CYRF (I use the buildin module, but 0e means make PORTA0 on MM low = active, which is CYRF_CSN). May that be the cause for CYRF not being properly detected ?

Edit:
Looking again at the output, the last line looks scary:means that all CSN lines of (hypothetic) CYRF, NRF and CC2500 are set to low (=active) - thus any SPI activity will send out data to all three modules at once (!)

Edit2:
Comparing output when turning TX off and on multiple times, one can see that the "readout" of the modules in the reset method reproduces a part of a sequence, which is shifted around:were output above wasOnce can see that with other output, too, but since I added readout of PARTNUM and VERSION, we have three values for CC2500 printed out here. I beg I can add a for-loop reading any register (even random) to read the very same sequence, starting 'somewhere'.
(it looks like we're getting the very same sequence starting at some point regardless of what command we send - indicating we're not talking with the RF chip at all)

Edit3:
These are all sequences I was able to find:Where second is same as first one, but misses one byte, and third one is starting one bit later, thus values are mostly half of values in first sequence. Next two are constant values, but trying around (~20 times) I never saw another sequence.
Anyone has an idea which chip in Devo8S could always respond with(ignoring MOSI command and returning > 256 values which end up with constant '20') ???

For reference my hardware.ini (commented lines removed) isand works fine with my first MM (no CC2500).

Digging deeper into the code ...

Hello, I'm new to Walkera/deviation and tx modding.
I'm surprised by the quality of the info/work on this forum, hats off to the developers!
Planning to buy a devo 10 for my helis, I like this multimodule.
What I don't like are the multiple antennas... I would need 3 modules so 4 external antennas seems a bit messy
I heard that those modules shouldn't powered without antenna/resistor wired in.

- Is there a dirty way (without programming) to only use one antenna for all the modules wired to the MM? (so just 2 total antennas, one for mm modules and one stock devo)

I mean using some kind of rotary multi pole/ways switch to manually commute them between dummy resistor or antenna?

Or wiring antenna signals through a small not shielded rotary switch is a bad idea? (for signal/interferences)

asking because electronics is not my field

is single-antenna on MM dev plans, like a new rev of board, or should I wait the ultimate single board module in the other topic?

Roberto