[riot-devel] RIOT-OS on telosb, issue with default example

Ivano Calabrese alphaemmeo at gmail.com
Mon Oct 20 15:54:46 CEST 2014


Hi Thomas, hi folks.
currently seems the sent packages from a telosb (A) don't arrive to telosb
(B).
Using a sniffer 802.15.4 I can look the packets are correct but, although I
set the same pan id and the telosb (B) as monitor, I don't receive pkt.

I tried to monitor the interrupt (PORT1_VECTOR) __attribute__ ((naked))
cc2420_isr(void) in .../RIOT/boards/telosb/driver_cc2420.c, but seems the
cc2420_isr(void) is never called.

Do you have some hint to debug this issue?

thanks a lot in advance

____________________________________
*Ivano Calabrese*, MSc.
http://www.dei.unipd.it/~icalabre/
https://www.linkedin.com/in/ivanocalabrese

On 20 October 2014 09:37, Ivano Calabrese <alphaemmeo at gmail.com> wrote:

> Hi Thomas,
> friday I solved the issue above. This morning before to sent you a mail, I
> notice you just fixed this problem.
> In a nutshell in my  .../RIOT/sys/shell/commands/sc_transceiver.c file
> there was not  p.frame.fcf.src_addr_m = IEEE_802154_SHORT_ADDR_M; line.
>
> Thanks a lot
>
> ____________________________________
> *Ivano Calabrese*, MSc.
> http://www.dei.unipd.it/~icalabre/
> https://www.linkedin.com/in/ivanocalabrese
>
> On 17 October 2014 17:20, Thomas Eichinger <thomas.eichinger at fu-berlin.de>
> wrote:
>
>> Hi Ivano,
>>
>> thanks for reporting this. I just opened a pull request [1] to fix the
>> `trans_p->data` artefact
>> and an update for the code used by `txtsnd`. Do you mind, testing this
>> with your TelosBs?
>> (I have mine currently not with me).
>>
>> Could you give me a pointer where `packet->frame.fcf.src_addr_m` is fixed
>> to 0x12?
>>
>> Anyways, if the problem persists, could you please open an github issue
>> for this?
>> Thanks in advance!
>>
>> Best, Thomas
>>
>> [1] https://github.com/RIOT-OS/RIOT/pull/1830
>>
>>
>> On 17 Oct 2014, at 16:18, Ivano Calabrese <alphaemmeo at gmail.com> wrote:
>>
>> Hi guys,
>>
>> I installed RIOT-OS on a telosb and I began to discover the several
>> feature starting from the default example.
>> Using two telosb with the same program and different addr I'm not able to
>> sent/receive pkt through them. Using a sniffer I could watch the sent
>> packet has wrong fields.
>>
>> If I send a message in this way:
>> addr 2
>> txtsnd 1 hello
>>
>> I receive this pkt
>>
>>   0 No.     Time           Source                Destination
>> Protocol Length Info
>>   1       1 0.000000000    0x6c6c                0x0000
>>  IEEE 802.15.4 15     Reserved, Dst: 0x0000, Src: 0x6c6c
>>   2
>>   3 Frame 1: 15 bytes on wire (120 bits), 15 bytes captured (120 bits) on
>> interface 0
>>   4 IEEE 802.15.4 Reserved, Dst: 0x0000, Src: 0x6c6c
>>   5     Frame Control Field: Unknown (0x8806)
>>   6         .... .... .... .110 = Frame Type: Unknown (0x0006)
>>   7         .... .... .... 0... = Security Enabled: False
>>   8         .... .... ...0 .... = Frame Pending: False
>>   9         .... .... ..0. .... = Acknowledge Request: False
>>  10         .... .... .0.. .... = Intra-PAN: False
>>  11         .... 10.. .... .... = Destination Addressing Mode:
>> Short/16-bit (0x0002)
>>  12         ..00 .... .... .... = Frame Version: 0
>>  13         10.. .... .... .... = Source Addressing Mode: Short/16-bit
>> (0x0002)
>>  14     Sequence Number: 3
>>  15     Destination PAN: 0x6012
>>  16     Destination: 0x0000
>>  17     Source PAN: 0x6568
>>  18     Source: 0x6c6c
>>  19     FCS: 0xb59a (Correct)
>>  20 Data (2 bytes)
>>  23     Data: 6f00
>>  24     [Length: 2]
>>
>> where the hello payload is in Source PAN: 0x6568 (he), in Source: 0x6c6c
>> (ll) and in Data: 6f00 (o).
>> I noted that when I send a pkt the packet->frame.fcf.src_addr_m filed (in
>> driver/cc2420/cc2420_tx.c) is fixed to 0x12. In a nutshell when the
>> cc2420_send function is called, the check:
>> if (packet->frame.fcf.src_addr_m == 2)
>> ...
>> else if (packet->frame.fcf.src_addr_m == 3)
>> is never matched.
>>
>> ps. In the meant time I found a bug in  DEBUG("transceiver: Content:
>> %s\n", trans_p->data);
>> data field isn't define in ieee802154_packet_t trans_p struct.
>> ____________________________________
>> *Ivano Calabrese*, MSc.
>> http://www.dei.unipd.it/~icalabre/
>> https://www.linkedin.com/in/ivanocalabrese
>>  _______________________________________________
>> devel mailing list
>> devel at riot-os.org
>> http://lists.riot-os.org/mailman/listinfo/devel
>>
>>
>>
>> _______________________________________________
>> devel mailing list
>> devel at riot-os.org
>> http://lists.riot-os.org/mailman/listinfo/devel
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riot-os.org/pipermail/devel/attachments/20141020/c6d497b8/attachment.html>


More information about the devel mailing list