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

Ivano Calabrese alphaemmeo at gmail.com
Tue Oct 21 10:08:33 CEST 2014


Hi Thomas,
I'm using the linked toolchain in the RIOT-OS wiki (
http://sourceforge.net/projects/mspgcc/) [LTS-20120406].

I don't know if this issue is related to the toolchain. Yesterday evening
debugging the .../RIOT/boards/telosb/driver_cc2420.c  file, I notice that
when a radio interrupt happens the if/else check hooks the the following
code snippet:
[...]
/* GIO0 is falling => check if FIFOP is high, indicating an RXFIFO overflow
*/
else if ((P1IFG & CC2420_GIO0_PIN) != 0) {
    P1IFG &= ~CC2420_GIO0_PIN;
    if (cc2420_get_fifop()) {
        cc2420_rxoverflow_irq();
        DEBUG("[CC2420] rxfifo overflow");
    }
}
[...]
but this is strange. Today I'm debugging this issue and if I find the
solution I'll inform you.

thanks a lot for the support.

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

On 20 October 2014 18:03, Thomas Eichinger <thomas.eichinger at fu-berlin.de>
wrote:

> 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
>
>
> _______________________________________________
> 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/20141021/1189d02c/attachment-0001.html>


More information about the devel mailing list