[Akiba] I spent the weekend checking out the Freescale MC13224 datasheet and writing the review. There are a lot of features so this is going to be a long post. For my sake, I've divided it up into sections. So grab a cup of coffee and sit back 'cuz this is gonna take some time...[/Akiba]

Freescale recently announced its MC13224 Platform in Package chip. Aside from the attempt at creating a new semiconductor marketing buzzword, it's a highly integrated chip that is almost an entire 802.15.4/Zigbee module on one chip. This is Freescale's 3rd generation 802.15.4 radio and it is definitely head and shoulders above its previous 802.15.4 SoC, the MC1321x series. The chip comes in a 9.5 x 9.5 mm, 99-pin LGA package and supports a temperature range of -40 to 105 degrees Celsius, otherwise known as industrial temp.

MCU
Just as a reference, the MC1321x series was based on the HCS08 line of 8-bit micros and feature tiny amounts of RAM and flash. The largest of the series, MC13213, had 60 kB of flash and 4 kB of RAM. In terms of Zigbee, you could probably fit the stack inside it, but you wouldn't have much room for anything else. Also, with 4 kB of RAM, it'd be extremely difficult to use that chip as a router. Since a router (ideally) requires a frame buffer pool, routing table, neighbor table, discovery table, indirect transmission queue, address table, binding table, group table, and discovery cache (did I miss anything?), it'd be amazing if you could fit all of that in 4 kB of code and still have room for a decent application.

The resource issue has been addressed in the MC13224. It features an ARM7 TDMI 32-bit processor, one of the first of the SoCs to use an ARM7 in fact. If you don't know about ARM7's, you've probably been hiding underneath a rock for the past 10 years. It's an extremely energy efficient 32-bit microprocessor and there's a wealth of tools available for development on it. There is an open source JTAG tool called OpenOCD which interfaces to the GNU Debugger (GDB) and also includes schematics for building your own JTAG hardware probe. The ARM-GCC compiler is actively maintained and has been stable and well optimized for a long time for the ARM7s. Also, there are a lot of OSes that are ported to it such as uCLinux, uCOS-II (RTOS), eCOS (RTOS), and FreeRTOS (RTOS). And that's just some of the open source OSes!

Also for those that believe that 8-bit micros are easier to use than 32-bit ones, I'd beg to differ. If you've ever programmed an 8051 using Keil, you'd know that you have to use a lot of non-ANSI compiler specific extensions due to limitations of the microcontroller. On the other hand, you can program an ARM7 in (almost) 100% ANSI C and have it portable to an AVR, MIPS, x86, or any other chip that supports an ANSI compiler.

Okay…enough with the microcontroller architecture preaching…let's get back to business...

 MCU Memory Configuration
As mentioned, the MCU consists of an ARM7 that can run at up to 26 MHz. It'd be funny to try overclocking this chip, but that's another post. According to the specs, this chip comes with 128 kB of flash memory and 96 kB of RAM. Wow…that's a lot of RAM. However if you look at the datasheet more closely, you'll see that they are using serial flash. This means that on startup, the MCU will need to copy the serial flash into RAM and run out of RAM. That means that if you are using 60 kB of flash for your stack, then you're available RAM will be 36 kB because the other 60 kB of RAM will be used as an image of your code.  One interesting question is why they used a 128 kB serial flash, but only include 96 kB of RAM. This means that if you're stack is greater than 96 kB, your SOL (shit out of luck) because your stack won't fit into RAM.

They also included 80 kB of mask ROM in which they burned their 802.15.4 MAC stack. Code can be run directly from the ROM so none of your RAM will need to be wasted to image the ROM code. I need to get more information regarding the ROM code because if you need to hook into it via compiler to use it, then it will be incompatible with the GPL. According to the GPL, all source code that is statically linked will itself fall under the GPL. This is called reciprocation and it prevents people from using open source code without opening up their own code. It also means that GPL code can only be used with other GPL-compatible code. This is only an issue with my project though and probably won't affect the larger WSN community much.

There is a bigger issue that I can see in using the 802.15.4 stack in the ROM and that is customer lock-in. If you use the Freescale MAC, the stack of your choice will need to be written on top of it and that creates a reliance on the Freescale MAC services. This will create a fairly large deterrent in changing platforms since the code would need to be re-written or at least ported to use a different MAC and PHY layer. I can easily imagine the pain of switching from this chip to something like an Ember or TI 802.15.4 SoC. I would say that it's non-trivial so users should be aware of this issue in choosing to use the ROM'd 802.15.4 code.

Aside from my obviously paranoid issues, there are some benefits in having an 802.15.4. MAC. One of them is that 802.15.4 is becoming increasingly popular for WSN protocols. 6LoWPAN, RF4CE, Zigbee, ISA100, Wirelss HART, Synkro (RF4CE?), SimpliciTI, MiWi, and a bunch of others are gradually converging on this method of transport so it might make the user's life easier to have built-in software support for the MAC.

In regards to the memory configuration, I would say that Freescale should have scrapped the serial flash, scrapped the ROM, implemented a 128 kB parallel flash on the memory bus so they can run directly off of it, reduced the RAM to something like 32 kB, and offered an option to have the 802.15.4 MAC code preprogrammed in the flash. That way, they get rid of the serial flash, ROM, and reduce the RAM. Doing this would have allowed them to offer the same functionality (ie: pre-programmed MAC code) at a lower die cost due to reduced RAM and trashing the ROM. The flash would have been a wash since you'd be replacing 128 kB serial flash with 128 kB parallel flash. Also, there's almost no cost advantage to using mask ROM versus flash these days. Just my 010'b cents.

MCU Peripherals
The MC13224 is rich on peripheral features. I won't spend a huge amount of time on them, however here's a brief overview:

Probably one of the most important of the peripheral features is the ADC. The MC13224 contains dual on-board 12-bit ADCs and 8 analog input channels that can be assigned to either one. As a lot of you know, achieving full 12-bits of ADC resolution is difficult, however according to the datasheet, you can get a very nice 10.5 equivalent number of bits (ENOB) of resolution.

There are many different serial interface options: I2C, SPI, dual UARTs, and even I2S. The I2C interface is good for sensors since it's a common sensor interface. The I2S interface is a little bit unusual in that it's normally associated with audio applications but it can enable easy interfacing to audio chips and DSPs.

There is also a 4x4 matrix keypad interface. It's not surprising that this exists because people that are following the news on my site should know that Freescale is also a principal member of RF4CE. This group is targeting a standard wireless protocol for RF remotes based on 802.15.4. A keypad interface will allow easy design of RF-based remote controls.

And, in my opinion, one of the most important features of an MCU is the development environment. As I mentioned, since the chip is ARM7 based, then we can just use the standard ARM-GCC to write software for it. However Freescale has teamed up with IAR for software development tools which is a bit annoying. This means that their stack and possibly even the ROM code requires an IAR ARM compiler. More research needs to be done on the development environment, however this should only apply to the Freecale Beestack and it's ROM'd MAC. It's too bad though because they'll lose a lot of grassroots support by not providing their Beestack on GCC.

They also mention that they are using a Nexus interface for JTAG debug support. This interface is supposed to provide more functionality for debugging, but it may require a special debugger to access these capabilities. I need to also do research on this to see if the Nexus interface can support OpenOCD. As I mentioned above, OpenOCD is a JTAG debugger that supports ARM chips and is both open source and open hardware. It's also GDB compatible which is a huge, huge, huge benefit. Many years ago, you could only debug ARM micros using the Multi-ICE debugger from ARM which cost about $3,000 and the ADS compiler which was an additional couple thousand.

802.15.4 MAC
Now that the MCU stuff is out of the way, we can get to the nitty-gritty of the chip. The part that most of the readers probably care about is the RF circuitry; more specifically the MAC and radio.

The part comes with an encryption engine which I believe is a required component on all 802.15.4 chips now. Wireless is too easy to sniff and hack unless encryption is employed. You can see this just by all the people that freeload off of unsecured wireless connections to access the internet. Actually, I do that also, but you don't want random strangers monitoring your home security system or controlling your network via a rogue node that they set up. Hence the need for encryption for any type of wireless network.

The Freescale MAC comes with automated features including Auto-ACK on received frames, auto-ACK checking on transmitted frames (retry on timeout if valid ACK is not received), and even automated beacon mode support.

Since the datasheet is still in a preliminary condition, registers and detailed specifics were not available on the automated MAC functions. The description of the MAC ran about two pages as of this post, which is not a lot of room to provide details. It's still not clear how they are handling the Auto-ACK transmission. As I mentioned in the previous review of the Atmel AT86RF23x, the Auto-ACK transmission is tricky. You need to account for the special function of the ACK to signal pending data on indirect transmissions. This is part of the 802.15.4 spec. This requires some sophistication on the hardware logic. If this feature is not implemented correctly, then having Auto-ACK is almost meaningless. In that case, you would need to check every frame to see if it's a data request and if so, do a bunch of processing and finally set a flag to set the pending_data bit. The timing of doing this is tricky so it's almost easier to turn off Auto-ACK altogether and handle ACK's manually. On their datasheet, they state that they support "assist for efficient response to MAC data.request" so it remains to be seen how the assist is implemented.

Freescale implemented a DMA function to automatically transfer a frame from the Rx FIFO to data memory and the memory to the TX FIFO. This is more beneficial on the Rx side since you have no control over when frames come in. Since the FIFO size is limited, automating the movement of data from the FIFO to memory has the advantage that even if your application is heavy enough to slow the response time of the CPU, you won't have to worry about incoming frames overwriting each other in the Rx FIFO since they're automatically sent to memory. This is actually quite a nice feature to have.

A random number generator is also included in the MAC. It seems that in this latest generation of 802.15.4 chips, many companies are now implementing the random number generator. Random numbers are used a lot in the 802.15.4 and Zigbee stacks. Some examples of their usage are: initialization of MAC and NWK sequence numbers, initialization of the APS counter, random jitter of broadcast and route request frames, random delay before transmission of frames, random backoff in CSMA, and of course encryption key generation.

One problem with the random number generator in the MAC is that it's based on a linear feedback shift register (LFSR). Aside from the complicated name, it's basically a simple shift register (string of flip flops) with some XOR logic sprinkled around in a feedback fashion. This type of structure generates a pseudo-random number sequence which means that it will generate a different random number on each access until it spans its complete range at which point it will repeat (ie: for 32-bits this would be ~4 billion random numbers).

LFSRs are frequently used in encryption and communication applications because of it's pseudo-random property where for the same initial seed value, it will generate random numbers in an identical sequence. Hence you can have random numbers but in a repeatable sequence. This is a bad thing for protocol stacks though, where you don't want to have all nodes transmitting frames with the same pattern of frame sequence numbers. This means that you will need to generate a random number for the seed value to your random number generator on each node, a sort of funny catch-22. I guess a possible workaround is to use the node's extended address as the seed for the LFSR, but since this is a 64-bit value, you won't know if the bottom or top word is unique. The Atmel AT86RF23x approaches random number generation in a smarter way which is to sample noise and use that as the random number.

802.15.4 Radio
One of the things that impressed me about the MC13224 is the radio's analog circuitry implementation. They included everything on-board so you theoretically only need a straight PCB trace to a 50 ohm antenna. The PCB layout is the scariest part of designing an RF board because you're at the mercy of your discretes, PCB supplier, and (in my case) lack of RF knowledge. Thus you need to make sure your balun is designed correctly, the discretes are positioned correctly, all traces maintain the correct impedance, and the impedance is matched to the antenna. You normally need some type of simulator if you want to ensure everything is correct, and then you need to verify it with a network analyzer after the PCB comes back. In the Freescale case, everything is already on-board and matched to 50 ohms so you only need to make sure your PCB trace impedance is matched to the 50 ohm antenna. Bypass capacitors are also integrated. Excellent!

Power Management
The MC13224 supports different power down modes which, by now, should be expected of any 802.15.4 chip. It also provides a buck converter which is a nice touch. Most ICs use voltage regulators to drop input voltage from 3.3V to 1.8V (or something like that). The problem with using voltage regulators is that the excess voltage is basically burned off as resistive heat which is inefficient. The 13224 has the option to implement a buck converter which will drop the voltage by switching current on and off. This way, the efficiency is greatly enhanced which is a big advantage for wireless applications. The buck converter requires an external inductor and capacitor, however I think that the increase in battery life should be worth it.

Conclusion
Well, I think I covered most of the key parts of the MC13224. Overall, it looks like a very nice chip and I'm looking forward to a more detailed datasheet which includes the register descriptions. If anyone has anything to add, please feel free to do so. I'd like to hear actual user experiences with this chip.

TrackBack URI for this entry

Comments (2)

Subscribe to this comment's feed

...
written by Yifeng, September 27, 2008

Very good review. Thumbs up.

BTW, I didn't find your review on Atmel AT86RF23x. Would you please let me know where it is.

Regarding the auto ack for data request, there is a trick. In 15.4, there is only 54 symbols, or about 850us for you to figure out if there is a pending packet and send out the acknowledgement. Usually, that time period is tight for a MCU to respond promptly. The trick is to let the radio always respond with pending bit set for Data request command. Then the MCU will check if there is a real data for the polling end device. If there is no data pending, just send a packet without any MAC payload or let the end device timeout. Playing this trick will significantly reduce the requirement for MCU speed.

report abuse

vote down

vote up

Votes: +0

...
written by Akiba, September 27, 2008

Hi Yifeng.
Yeah, I found out about the trick in the 802.15.4 spec. Its kind of funny because it kind of defeats the purpose of the data pending flag. Looks like its a common practice though.

Here's the link to the Atmel review.
Link

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