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)
- 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.