Problem adding CC2500 to multimodule

I'm running the latest nightlies, and have been using the A7105 & NRF24L01 modules while waiting on the CC2500 and parts. Now that I have them all, it doesn't seem to want to work.

Install it, plug the electronics back in, and I get a "Missing Module: CYRF6936" and the Tx locks up (the nightlies don't seem to deal with missing modules very well). Unplug the CC2500, and things work again.

Behaves this way whether or not the CC2500 is enabled, except that the "Missing Module: CC2500" dialog locks up the Tx.

I did a visual inspection of the soldering on them CC2500 (to add pins) and the multimodule (to add headers) and didn't see any problems. Used a meter to verify that there were no shorts between adjacent pins on either. I didn't check all pins against all other pins because I'm not sure what might be connected on the board/module.

Any other suggestions as to what I might be doing wrong?

I remember having trouble with one of my multimodules. I did the not-so-smart thing and changed two things at once. I replaced the pigtail connector I was using between my TX and the multimod, and I also switched to running a build of hexfet's repo, because it includes some NRF24L01 fixes that hadn't been pulled in to the PBs repo. Between the two of them, my init problems went away.

Well, hexfet's version solved the module init problems, at least partly. It now inits if I turn on the CC2500 in hardware.ini. But if I plug in the CC2500, it still says it can't find the CYRF6936. Everything works fine if I unplug the CC2500.

Any clues as to what to check for other than shorts on the CC2500? Could it just be a dead CC2500 interfering with the CYRF module?

mwm wrote: Well, hexfet's version solved the module init problems, at least partly. It now inits if I turn on the CC2500 in hardware.ini. But if I plug in the CC2500, it still says it can't find the CYRF6936. Everything works fine if I unplug the CC2500.

Any clues as to what to check for other than shorts on the CC2500? Could it just be a dead CC2500 interfering with the CYRF module?

Do you use some female connector to unplug RFchips ?

As suggested by your video tutorial, sorta. I put in sockets for the CC2500 and NRF24L01, but decided to solder in the A7105 since that fit better under the NRF24L01.

BTW, thanks for the video tutorial on that. I'm not really a fan of video documentation, but that helped a lot.

mwm wrote: As suggested by your video tutorial, sorta. I put in sockets for the CC2500 and NRF24L01, but decided to solder in the A7105 since that fit better under the NRF24L01.

BTW, thanks for the video tutorial on that. I'm not really a fan of video documentation, but that helped a lot.

Check again your soldering job for the male connector attached to the CC2500 itself. I had to triple check this point before it's started to work. But, it's true main problem come from when we add this one. And the CC2500 standalone, did you tried ? or just with the C2500+the A7105 ?

Well, my soldering job there was the first thing I suspected and checked. But I checked it again: visual inspection with a jeweler's loupe, which showed no obvious (to me, anyway) problems. I also checked each adjacent pair of pins for shorts, and again didn't find any. Can you recommend any other checks? Maybe posting a picture of the male header on the CC2500 so more experienced eyes can check it?

No, I haven't tried the CC2500 by itself. I've been adding the modules as they arrived from the other side of the pacific. I can remove the A7105 easily enough, but that may have to wait until Sunday or Monday.

Thanks.

mwm wrote: Well, my soldering job there was the first thing I suspected and checked. But I checked it again: visual inspection with a jeweler's loupe, which showed no obvious (to me, anyway) problems. I also checked each adjacent pair of pins for shorts, and again didn't find any. Can you recommend any other checks? Maybe posting a picture of the male header on the CC2500 so more experienced eyes can check it?

No, I haven't tried the CC2500 by itself. I've been adding the modules as they arrived from the other side of the pacific. I can remove the A7105 easily enough, but that may have to wait until Sunday or Monday.

Thanks.

Can you check electricity continuity with a DMM between CC2500 pads and the male pins ?. Can you plug the CC2500 directly in the Devo ? in a "non-multimodule" way ? Maybe of you are using Dupont wires too, like in my video, so it's easy to plug directly and check the CC2500

Did you use a connector for the Multi-Module itself and/or is the cable to multi-module relatively long (so you can have the MM outside of Devo housing while being connected) ?

I am plagued by a very similar issue which I was able to _proove_ to be being caused by entire SPI traffic getting trashed. The code in SPI_ConfigSwitch() usually reads '0xa5 0x03' (version 3 AVR code) - but I've added a printout of these values (and enabled debug printout via tty by using 'dev' Makefile option) and can see that ANY SPI traffic read back (e.g. when modules perform reset code and check module presence by comparision against expected values) look like nonsense - though its structured and somehow (bitwise shifted) reproducable. This makes the module detection code fail and thus all configures modules are listed as not found.
The 'no modules found issue' almost never happens when using a MM w/o CC2500 - though when it happens, unplugging the MM and plugging in again usually solves the issue. The MM with the CC2500 never really started to work for me, until I've disabled it - which does not work out of the box with the present code base.

Every not configured CS line will be held in SELECTED state (thus enabling SPI with this module) with current code, which is exactly what you do NOT want to have here.
I have changed code of PROTOCOL_SetSwitch() (protocol/protocol.c) towhich really disables all but the configured modules (all lines high by default).
NRF code for CE_lo() and CE_hi() (protocol/spi/nrf24l01.c) should be changed to:The original code does use hardcoded values, not the ones from your config, which could lead to unwanted issues again.
With these changes you should be able to physically DISABLE the CC2500 on your MM via config and use the other chips without issues.

When I recall it right, the lockup issue is actually caused by the default protocol which tries to talk SPI with CYRF but does not get things right, thus hitting watchdog. Could be SPI double-talking. Deviation has ALWAYS an active loaded protocol, even after startup. When I recall it right the lockup/restart issue does not happen for me when selecting an A7105 based protocol with my working MM and then switch to the other MM.

I'm pretty sure the actual issue has something to do with wire length, bad logic levels, missing decoupling capacitors and/or possibly timing issues which lead to AVR on multi module, chips on multi module and ARM in Devo getting into different states leading to SPI crosstalk. The bad thing is that attaching a logic analyzer does not solve the actual issue where the captured traffic looks fine to me.

Please tell us if my workaround for disabling modules via configuration does work for you and makes the multi module usable again. Even that this does not solve the original issue, it limits the root of cause to interaction with CC2500 module not working properly with multi module.
I think we should double-check the actual pinout of the CC2500 (one more time, again, ... )

Well, I made btoschi's recommended changes, but to the hexfet sources. The only real change in behavior I noticed was that it nows complained about the multi-module being missing rather than the CYRF module.

Then, while looking into SebyDocky's suggestions, I found the problem. The CC2500 was the last module I added, and I just removed the comment markers for the CC2500 entries without editing them. This meant that the CC2500 enable pin was still set to A13, not S3 as it should be for the multi-module. Oops.

Fixing that fixed the problem. It now finds the module, and I've successfully bound it to a FrySky D4R-II Rx.

Thank you all for the help. That got me looking in the right place, at least.

Great to hear that you have solved your issue.

That's strange that it complains about missing MM, which Devo do you have, this code was tested (only) on Devo 8S until now - and it worked fine for me

I'm using a Devo 10

If you're not using code from the hexfet repository, that might be why things are weird. It also has solutions for the module detection issue in it.

btoschi wrote the code you're referring to

I just applied the patch.

hexfet wrote: btoschi wrote the code you're referring to

I just applied the patch.[/quote

Should be nice to be officially included ... but it's a while I didn't see PB around ...