Texas Instruments just did a press release announcing their CC2520. As some of you know, I'm using an AVR+CC2420 as my main platform, from which I'm going to branch off to other combinations. So when I heard that the CC2520 was out, I took some time to check out the datasheet to see what kind of benefit it bestows on the user versus the CC2420.

There are many improvements to the CC2420, but probably the main benefit to the users is that this chip can be had for a lower cost. It looks like this chip incorporated a die shrink since the operating voltage changed. Whereas the CC2420 had an operating range of 2.5-3.3V (actual 2.1-3.6V), the CC2520 can now run at 1.8V-3.3V (actual 1.8-3.8V). This means that, most likely, they shrunk the core down to 0.18u or below, whereas the CC2420 was probably done in a 0.25u process. The CC2520 also has a smaller package size, weighing in at a QFN-28 5x5mm package, where the CC2420 had a QFN-48 and 7x7mm package. These two changes, a die shrink and smaller package, translate into a lower cost. A quick look at Digikey (the chips seem like they are already available there) show that the CC2520 costs $3.35 in 5k volumes and the CC2420 costs $4.09 at 4k volumes which confirms the lower cost suspicions.

Here are some of the other more interesting improvements:

• Improved adjacent channel rejection (coexist better with other 802.15.4 networks)
• Improved sensitivity and output power (longer range, 400m line of sight claimed by TI)
• Clock output (1-16 MHz output available)
• Using Opcodes to control the chip, ie: it has an onboard computing engine (CC2420 uses command strobes and register accesses)
• Random number generator (useful for initializing NWK sequence numbers, APS counters, and for manual CSMA/CA backoffs)
• Double the RAM buffer size
• Source Address matching table (this one is cool and I'll talk more about it later)
• GPIOs
• Radio state machine in hardware (for turning radio on and off...yes...you need a state machine for this)

As I'm writing this, I'm watching the TI online video on the CC2520 page . I'm surprised why marketing people think that customers are completely clueless about their products. They dumbed down the CC2520 benefits to a remedial high school level (using a crowded party analogy) when anyone that would be watching the video and reading their datasheet would obviously be knowledgeable enough about the technology to want a decently detailed treatment. So here is my attempt to provide more insight into some of the improvements.

The new clock output that was added is an attempt to lower the overall BOM cost of the 802.15.4 system. With that, you ideally won't need to use two crystals, one for the MCU, and one for the transceiver. Instead, you can just use a 32MHz xtal for the transceiver and feed the CC2520 clock output to the MCU. The reason I am using the words "attempt" and "ideally" is that for all the good intentions of the clock output, the datasheet specifies that the MCU needs to have an internal RC oscillator if you want to realistally use it. It doesn't exactly put it in those terms, but you will need the internal RC oscillator on the MCU if you want to put the CC2520 in sleep mode (LPM2) and wake it up again.

"The procedure for waking a system up from LPM2 is as follows:

• MCU is running on RC oscillator, CC2520 is in LPM2

• Change CC2520 from LPM2 to active mode.

• Switch the MCU over to the 1 MHz clock that CC2520 outputs on GPIO0.

• Change to the desired clock frequency.

The procedure for bringing a system from active mode to LPM2 is as follows:

• Switch MCU over to RC oscillator.

• Set CC2520 in LPM2."

If you have an internal RC oscillator, then why go through the hassle of switching? I'm interested to see how TI envisioned this feature to be used.

Another change is the use of opcodes for controlling the chip instead of strobes. This means that they must have implemented a simple CPU engine on their chip. The interface is a bit primitive since you have to send in the actual opcodes in hex format and using the correct length according to their table. However using the opcodes, they created a lot of new features that couldn't be done by simply using strobes. An example is that you can do bitwise OR, AND, and SET/UNSET in single instructions instead of doing the standard READ/MODIFY/WRITE via the SPI bus. Now, you can chain the commands into cute little opcode scripts that run when certain events happen.

The random number generator is also a nice feature. Previously, you would need to pull a random number off a free-running MCU timer which is a problem if your MCU is using all its timers. Random numbers are used in the CSMA/CA protocol for random backoffs and also used to initialize certain variables in the Zigbee stack.

The source address matching table implements a feature thats kind of hidden in the 802.15.4 spec, but bites you in the ass. When you're doing an indirect transaction, you're only supposed to ACK, with the frame pending bit set, if you have data for the device. However the time it takes to respond to an ACK is short, and if you're AUTOACKing, you need to check the whole indirect queue for a frame with an address that matches the src address of the data poll you just received. If a match is found, then set the frame pending bit (SACKPEND in the CC2420 case) or if a match is not found, send a normal ack. Its basically impossible to respond in time since you only have 800 usec or 4/5 of a msec to respond with an ACK. Actually, you have even less time because you have to set the pending bit before the ACk goes out. Whew! Oh, you didn't know that? I thought everyone knew that.

So the dirty workaround is that if you have ANY data in your indirect queue, you would set the pending bit in ALL of the ACKs. This would satisfy the ACK response time requirement. If its a data poll, you then scan your list and if there's data for that node, send it. If not, send an empty frame (0-payload size). With the CC2520, if you have an indirect data frame, then you can put the src address in the matching table. When a data poll arrives asking for data, then the hardware will automatically respond with the pending bit set or not depending on the src address of the poll. You can then leisurely retrieve the indirect frame from the queue and kick it out to the node. Nice feature!!!

Well, thats about it for the features that are most interesting to me. Its should also be noted that TI chose to continue the standalone transceiver as well as having their CC2430/2431 integrated MCU+transceiver chips. The standalone transceiver is good because it allows the customer to use whatever MCU they choose. I'd hate to continually change my toolchain and ICE every time I want to use a different radio which is what you need to do if you're working with a lot of the integrated MCU+transceiver chips (Ember, Jennic, TI CC2430). According to the current trend of integrating the MCU and radio at most Zigbee companies, TI may just end up with the only up-to-date cost-competitive standalone transceiver.

TrackBack URI for this entry

Comments (15)

Subscribe to this comment's feed

FYI: AT86RF230
written by nobody, March 03, 2008

"TI may just end up with the only up-to-date cost-competitive standalone transceiver."

What about: ?

report abuse

vote down

vote up

Votes: +0

FYI: AT86RF230
written by nobody, March 03, 2008

Link disappeared.. trying again:
AT86RF230: http://www.atmel.com/dyn/produ...rt_id=3941.

report abuse

vote down

vote up

Votes: +0

FYI: AT86RF230
written by Akiba, March 06, 2008

Actually, the AT86RF230 is the first generation 802.15.4 chip from Atmel. There are many first generation radios: Microchip, Ubec, Freescale, and TI.
What I meant was that it doesn't seem like anyone is focusing on making "just a radio" anymore. Everyone is just making integrated transceiver MCU chips which is only good in applications where Zigbee plays a central role. However many applications already have the central processor and just want to use Zigbee for simple wireless communications.

Also, I talked with my friend at Atmel's Zigbee group in Dresden. Seems like they're working on a second generation Zigbee chip, but he can't say what type of chip it will be. I'm a little excited to see it. I'm in tight with the local Atmel disti in Tokyo.

2008-03-18 Update:
Sorry, I had thought the comment was referring to the AT86RF210. After making the chip comparison guide, I realized that the AT86RF230 is not a first generation chip and actually, the specs are quite impressive.

report abuse

vote down

vote up

Votes: +1

BTW....Thanks
written by Akiba, March 06, 2008

By the way, thanks for posting a comment. You're the first person to comment on my blog.

report abuse

vote down

vote up

Votes: +0

...
written by ubisys, April 23, 2009

By the way: You can create a random number on CC2420 using the ADCTST registers. Combining the I and Q branches of the ADC value gives you a true random number which one can use a seed for the C RTL rand() function, for example.

report abuse

vote down

vote up

Votes: +1

...
written by Akiba, April 23, 2009

Wow...that's a cool trick. I was using a free-running timer for the random seed generation, but this is much easier and doesn't take any timer resources.

report abuse

vote down

vote up

Votes: +0

...
written by coldfire, February 26, 2010

hi,could any one show some detail of how to get a random number by cc2420?
i tried but failed. i set the CCAMUX, read the LSB of ADCTST. but i always get 0.

report abuse

vote down

vote up

Votes: +0

...
written by mats nilsson, March 05, 2010

Anyone knowing about vendors that have nodes with cc2520 onboard.

report abuse

vote down

vote up

Votes: +0

...
written by Akiba, March 05, 2010

I would just say google it, but it might be kind of tough since many module makers dont want you to know what they're using. I'm sure its a popular chip to use, especially since there is a well documented interface to the CC2590 and CC2591 RF front ends. However I can't name any module makers that use it off the top of my head.

report abuse

vote down

vote up

Votes: +0

Antenna for CC2520
written by rasha, July 06, 2010

You have a nice blog here. I'm currently looking at at86rf231 and cc2520 for simple
wireless connectivity on my xMOS board.
It seems that it's nearly impossible (or I have failed so far) to obtain output
impedance characteristics for cc2520. TI just won't give them, and most of the ANs
do not show anything useful, and even less of it is related to cc2520. Is it possible
that then only way to use this chip is to importthe layout they provide for single-ended
antenna and use it? This is very disappointing if it's true...

On the other hand, is there any way to get at86rf231 to be 3.3v IO tolerant? The supply
can go up to 3.6v, but it seems that they always want (either internal or external)
regulation to 1.8v. I would really like to avoid level shifters but it seems that
it is impossible ... On the other hand, if they are .18u they probably do not have
3.3v tolerant digital IO.

report abuse

vote down

vote up

Votes: +0

...
written by Akiba, July 07, 2010

The best way is just use a network analyzer and check to make sure your path from antenna to chip is 50 ohms. As for the RF231 and 3.3V IO, it should be fine. There should be no problem running it at that voltage.

report abuse

vote down

vote up

Votes: +0

Random number with CC2420
written by Arasch Honarbacht, September 16, 2010

In response to coldfires comment (sorry, a bit late): This is how we did it:

unsigned int CPhysicalCC2420::GetRandomValue()
{
CCriticalSectionLock csl;
unsigned int nResult = 0;

ASSERT(!(GetStatus() & statusSynthesizerLocked));

for (unsigned int i = 0; i < 16; i )
{
// Turn off radio, and wait until it has been turned off
InvokeCommand(commandRadioOff, false);
InvokeCommand(commandFlushRX);
WaitStatus(0, statusSynthesizerLocked);

// Turn on radio, and wait until synthesizer has locked and receiver
// has run for a while to avoid start-up transients
InvokeCommand(commandEnableRX);
WaitStatus(statusSynthesizerLocked | statusRSSIValid);

// Read a value from the ADC test register and combine the I and Q
// LSBs
const unsigned int nADC = ReadRegister(0x2d);

// TRACE2("ADC = &#xuI;/&#xuQ;
", (nADC >> & 0x7f, nADC & 0x7f);
nResult |= ((nADC & 0x0001) | ((nADC & 0x0100) >> 7))

report abuse

vote down

vote up

Votes: +0

Random number with CC2420, part #2
written by Arasch Honarbacht, September 16, 2010

This was missing above (some problem with the web form):


// Finally, turn off radio
InvokeCommand(commandRadioOff, false);
InvokeCommand(commandFlushRX);

// Wait until radio is turned off
WaitStatus(0, statusSynthesizerLocked);

return nResult;
}

report abuse

vote down

vote up

Votes: +0

low power applications
written by ramdev, February 04, 2011

it was good to see a comment like this.but for low power applicaions,is it advantageous to use 2520 prior to 2420....since iam trying to build a wireless mote for a low power application this information can be a great advantage for me....

report abuse

vote down

vote up

Votes: +0

Registration ?
written by don vukovic, April 14, 2013

1. Is registration still open for your forum ?

2. In the source files in FreakZ_v075, there are some files missing.

#include "dev/spi.h"
#include "dev/cc2420.h"

Has FreakZ been ported to the CC2420 ?

Thank you for any information.

don

report abuse

vote down

vote up

Votes: +0

Show/Hide comment form

Name

Email

Website

Title

Comment

smaller | bigger

Subscribe via email (Registered users only)

I have read and agree to the Terms of Usage.

Add Comment