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

Thomas Eichinger thomas.eichinger at fu-berlin.de
Mon Oct 20 18:03:58 CEST 2014


Hi Ivano,

just checked, my TelosB doesn't receive anything neither. As you mentioned the ISR doesn't get triggered correctly. 
I'm wondering what's the source of this as there were no recent changes to this code. 
As a start could you tell me your toolchain version you are using?
Will investigate this more in detail tomorrow and let you know of my findings. 

Best, Thomas 



> On 20 Oct 2014, at 15:54, Ivano Calabrese <alphaemmeo at gmail.com> wrote:
> 
> 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
> 
> _______________________________________________
> 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/0d70dd26/attachment-0001.html>


More information about the devel mailing list