Help needed with CC8520 board

Hi Kobus,

I can not see anything direcly wrong with you schematic. Are you using the preload demo example in the configurator? Try  to use the DSP as the audio device as I have described in this post:

http://e2e.ti.com/support/low_power_rf/f/155/p/62657/225024.aspx

Let me know if  they connect together?

-P

Thanks for the quick reply.

Sorry, my previous report was incorrect, our LED doesn't come past ALONE pattern, we havent been able to reach standby at all.

regarding the post you mentioned , yes I have read it before, and it gave soe interesting insight into the 'network id' problem.

But again, I dont see how the DSP mode is going to help us before the chips get past ALONE, as this only really seems to test the I2C funcionallity, and we cant even pair.  

Hi Kobus,

Have you got it to work?

-P

No. we're going to have a professional board made and hopefully that works.

I can at least say that we were able to get the device to enter pairing mode, as it seems there was just a disconnect between the pairing button and the device :)

but still no pairing. We've ordered some samples of the c2590 instead of the cc2591 to make sure this is not the problem, and ahve made the board compatible with both.

It should also be mentioned that we still havent received our 2.4GHz antennas, we were only using makeshift coax antennas, and i think this should have some impact, although we should have got something with the old ones.. we'll see... 

Sounds good Kobus!

Let me know if it works or not! If not, we will try to help :-)

-Pelle

I have verified you answer, but as yet I have not tested this. It does seem to be the problem though, Thanks!

Hopefully we can halt the production of my pcb's until we can verify  whats going on....

Thanks again. 

I felt I should mention that we have still not fixed the problem. We have swapped the pins on the first demo board and nothing worked, but thought this may be because we could have harmed one of the components and as such proceeded to produce the professional PCB's, but they too are not functional. Initially we could see them with the cc debugger, but they kept saying 'failed to erase flash' when we tried to program them.

Then we undid the only change made to the board; we swapped out the new crystals for the old oscillators and they succeeded in programming, but they still can't pair.... the interval simply goes past without either connecting. 

Kobus,

I am sorry that you are having difficulties with your design, but as I am still in the very early planning stages of my design, I don't have much advice to offer with this chip.  I generally follow these troubleshooting steps, in the following order, when a new board I have designed and built doesn't work right away.

Closely look at every pin on every chip and ensure that every pin has a gold solder joint to the board - using a magnifying glass helps.  If it is not a smooth, shiny transition from pad to pin, then the pin is probably not soldered to the pad.  This is almost always where my mistakes are, especially when the design has a few QFN packages.

Check continuity between each and every pin belonging to each and every net.  Without pushing down too hard, try to put the probe lightly on the pin itself and not the PCB land pad.  This will help you find pins with poor solder joints.

Check for shorts between pins which are adjacent to each other, between every pin to ground or Vdd, and between ground and Vdd.

Power on the board, and check that all of the power, ground, and control pins have the expected voltage level applied to them.

If available, do a pin for pin comparison of your design against a reference design if available (checking pin numbers and not pin names).  For this step, don't get in a hurry and try to go fast.  You have already spent several days on a problem, so take the time and spend a couple hours making two separate lists, one of your design, and then one of the reference design.  Compare the two lists together, and look for anything that isn't the same.

Finally, if the board has passed all of these tests, and you are sure that the schematic design you are working with is correct, start swapping out chips from the board.

I hope this helps.

ITS FINALLY WORKING!!!!!

probem solved. sparkchase was half correct, the issue was with the PAEN and LNAEN lines, but not like you think.

After hours of debugging and trying to fix at least another three issues we saw with the design, we decided to cut the EN tracks and swap them back to their original orientation, when in a brief lapse of sanity decided to test them with only the Master's pins swapped and the Slave left as is. This fixed the problem??!!

This is also partly due to my partner noting that the EN signals appeared to be the wrong way arround on the scope; ie they switched contrary to what we thought they should for the TX board. So now we have one board with the pins swapped and the other without and they work!

This realy doesnt make any sense to me though, could this be a firmware issue? that the software running on the CC8520 has enumerated the pins incorrectly or something...  Thats one of the big issues i have with this system: the purepath configurator does make life easier for us, but the moment something is wrong, its like a big screen blocking you from whats really going on in the chip; I would very much like to have some code to look at and preferably be able to step through/debug.

As a side note, can I just ask someone with a CC8520 evaluation kit to try pair the 2 cc8520 + cc2590 boards. From my theory they should only be able to connect if the master is one of the boards without a CC2590.  

Just for the benefit of the forum, the other issues with our circuit are;

1. apparently they say XANTIN and XANTIP should be puled high if not used.

2. we tied DCPL to 3v3 which should have been brought out to a cap. (Im supprised this didnt blow up the digital part of the chip! We actually fixed this by tying the pin to the 1.8V rail for the codec, but found the chip actually functions more reliably with it tied to 3V3... at 1.8V the oscillator is jumpy and usually you have to press reset after power up before it will start...)

3. our 48MHz crystals turned out to be third harmonic crystals! We got them to function at 48MHz with a LC filter, but found them to be iffy at best. We are now using the 48Mhz oscillators. -- 48Mhz crystals seem to be notoriously hard to come by, i dont know why, especially considering all the USB devices that use them, but there you have it. has anyone got the CC8520 to work with another value crystal? I see on some of the schematics they show a list of possible values, including 16Mhz, which i know to be more popular.    

Kobus,

I am glad you got yours up and working.  I agree with you that I think it this a firmware issue.  These chips and software are still very new, and judging by these types of simple mistakes, I think these chips might have been rolled out as full production ready a little prematurely.  I was just looking at the user's guide, and Table 3 shows that pin 36, XPAEN, has the peripheral function of Range Extender LNA control, and pin 38, XLNAEN, is the PA enable pin.  Thanks for the heads up that the timing of the LNAEN and PAEN pins do not take into account if the device is acting as a master or a slave.  Just in case a later revision of the firmware corrects this, I am going to use a switch to route the LNAEN and PAEN signals instead of hard wiring them.

Sparkchaser

Kobus sparkchaser,

To clarify a bit here… the error here is in the documentation; in the datasheet figure 1, pin-out table and the description of xLNAEN(should be pin 38) and xPAEN(should be pin 36) in table 3 in the user guide. Thus, pin 38 controls the LNA of the CC2590 and pin 36 controls the PA. This will be updated very soon in the documentation. The correct way to connect the CC8520 and the CC2590 on both the master and the slave is (as we have it on the CC8xx-CC2590EM):

CC85xx.38(xLNAEN) connected to CC2590.6 (EN)

CC85xx.36(xPAEN) connected to CC2590.5(PAEN)

To comment some more on your 3 points:

1.       xANTN and xANTP (pin1 and pin 2 of the CC8520) should not have a pull-up.

2.       The DCPL pin(pin39) should only be connected to a 1 uF capacitor(as in the ref design). Not to 3.3V or 1.8V or anything else except the capacitor.

3.       The CC8520 only works with a 48MHz crystal (no other frequency). The spec of the crystal can be found in the datasheet.

Finally, the HW of the CC8520 is very well tested and we are testing the FW extensively before any release.

Again, thanks for noting this and helping us getting better!

Cheers,

Pelle :-)

"This is also partly due to my partner noting that the EN signals appeared to be the wrong way arround on the scope; ie they switched contrary to what we thought they should for the TX board. So now we have one board with the pins swapped and the other without and they work!"

Connecting it this way should give extremely bad performance(range).

"This realy doesnt make any sense to me though, could this be a firmware issue? that the software running on the CC8520 has enumerated the pins incorrectly or something...  Thats one of the big issues i have with this system: the purepath configurator does make life easier for us, but the moment something is wrong, its like a big screen blocking you from whats really going on in the chip; I would very much like to have some code to look at and preferably be able to step through/debug."

This seems extremely strange (if it is correct) and should not be possible. I would be happy if you could send me the HW so I can have a look at it. (I will send you the address in a private message :-))

"As a side note, can I just ask someone with a CC8520 evaluation kit to try pair the 2 cc8520 + cc2590 boards. From my theory they should only be able to connect if the master is one of the boards without a CC2590."

We ship our CC85xxDK with cc8520 + cc2590EMs talking to each other. So I am 100% sure you can have a CC2590 on the Master. Since you and sparkchaser found this error in the documentation.  I will ship you a CC85xxDK each so you can see it by yourselves!  Hearing is believing! ;-)    

 Cheers,

Pelle

Pelle,

I am sorry if you have taken offense to the negative comments about this chip. I know how it feels to have others pop shots at something that is in essence a very good design, and I also know from past experience that if the reference design is copied exactly pin for pin, the boards have always worked the way they are supposed to work.  I am very excited about using the CC8520 because I have previously developed lossless wireless audio streaming solutions using the CC2500 (two of them in parallel), and the Nordic Semi NRF24Z1 wireless audio codec, and everything about this new chip seems to be a real improvement over both of those solutions.  That being said, there is another place where the LNAEN and PAEN are wrongly labeled.  In the PurePath Wireless Configurator IOMapping, the PPWC shows GIO14_XLNAEN (GIO14 is pin 36 LNAEN is pin 38) and GIO15_XPAEN (GIO15 is pin 38 and PAEN in 36).

Sparkchaser

Pelle, could you please clarify what it is you meant when you said this:

"Connecting it this way should give extremely bad performance(range)"

Beacause it seems your statement was right; the range performance does seem to be very low if we use it like this - about 4m. But again we couldn't get it working any other way.

What I would like you to explain is, how, if one of the PAEN and LNAEN sets is reversed, can anything still come through? shurely you cant receive data if your LNA is off, and you cant send data when your PA is off?  

Kobus,

If I remember correctly we measured a 30-40dB insertion loss when the LNA or PA is off on the CC2590.  So what Sparkchaser says makes sense... I would double-check the connections between the CC8520 and the CC2590. There is something that is not correct there..

-P

By reversed, sparkchaser, I mean i have pins connected 38-6 36-5 on one board, as i believe it should be (this is how the copper trace is layed) and on the other I have cut the traces and soldered in wires to 38-5 36-6.

Again, with the copper traces as is, ie 38-6 36-5  nothing happens. I suppose this could be a soldeing fault, but I'm pretty confident on that part. I guess what you mentioned makes sense.

I wasn't very clear when I asked what you meant by reversed.  I wasn't so much asking about the physical configuration of the pin connections, instead I was asking about the signals being applied to the cc2590 direction pins.  If you monitor the LNAEN pins, or the PAEN pins, on both transmitting and receiving boards, do both boards' LNAEN pins go high at the same time?  If they do this, then this is wrong because as one board is transmitting the other should be receiving meaning the pins' respective logic levels should be the opposites of each other.  One more thing, have you left the RXTX pin floating?

Sparkchaser

Yes. I cant really remember what the guy who tested them said, if I remember correctly, the slave was right, its LNAen seemed to stay high and the PAen pulsed high momentarily.

The master device's were diferent... can remember exactly how, but i think its PAen stayed low and the LNAen stayed high and pulsed low or something. obviously this was before we swopped the pins. We also havent actually done this test while they are paired, hich i guess is what your refering to... obviously if they arent paired there  is little chance of the pins being sincronised.  

Kobus,

"its LNAen seemed to stay high and the PAen pulsed high momentarily"

Taking a look at table 4 of the cc2590 datasheet, driving the two pins high at the same time is a "not allowed" condition, and I would assume that the cc8520 is not configured to drive both of these pins high at the same time.  If one of your pins is staying high, this would indicate that the trace is either shorted to high somewhere, is not being properly driven by the cc8520, or that the cc8520 you are working with has been damaged.

Sparkchaser

Hi I'm gumilard,,

I have the CC85XX_CC2590 EVM.,

I got the trouble again.,  I want to build the wireless microphone., I build my own CC8520 and the extender ( CC2590) with TLV320AIC3101., currently I built my Master and want to communicate that with the slave CC85XX EVM., I configure for mic and successfully done,

the Indicator has sign and show that they are connected Pairing., but unfortunatelly I didn't hear anything at my speaker., someone please give me some light ..

Thx

Hi gumilard,

Is it working if you use the CC85XX EVM as master?

-Kristoffer