[Tinyos-help] CC2420: length field in 802.15.4 header is used without initialisation, fcf field not set in any case

Silvan Nellen Nellen at cmc.ca
Thu Nov 4 13:34:54 PDT 2010


Hello,

I have two issues regarding revision 5214 (the newest at the time of writing) of the trunk (https://tinyos-main.googlecode.com/svn/trunk):

1.
After updating from revision 5160 to 5214, Zigbee communication stopped working on Shimmer. Using a Zigbee packet sniffer I found out that all updated nodes send packets with the length field of the header set to an invalid value. After looking at the source code of the CC2420 driver (Shimmer uses CC2420) I found the reason why: the code that sets the length field in the header had been commented out (/trunk/tos/chips/cc2420/csma/CC2420CsmaP.nc, line 136)! The change was introduced in r5174.

Am I missing something or is this a serious bug that needs to be fixed ?

2.
Another CC2420 related issue is that the fcf field in the header is not set in some cases. In the current version of the trunk the fcf field is set in the RadioResource.granted() event handler in /trunk/tos/chips/cc2420/csma/CC2420ActiveMessageP.nc. However this event is not triggered if access to the radio is granted immediately (line 104), in this case fcf remains uninitialized!

Why was the initialization fcf code moved from the Send.send() command in tos/chips/cc2420/csma/CC2420CsmaP.nc to RadioResource.granted() ? What would be the cleanest way to fix this ? Move the initialization code back to CC2420CsmaP.nc?

Regards,
 Silvan Nellen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www.millennium.berkeley.edu/pipermail/tinyos-help/attachments/20101104/48d97b9a/attachment.htm 


More information about the Tinyos-help mailing list