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

Ivano Calabrese alphaemmeo at gmail.com
Wed Oct 22 17:30:42 CEST 2014


Hi Thomas, hi folks.
it seems I don't find a solution to this issue. Since I believe that
RIOT-OS is a good OS and I need a board with 802.15.4 link layer, can you
suggest me which board is really compatible with RIOT-OS. Of sure I'll come
back on this issue but now I need to go along on my project.

Thanks a lot guys.







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

On 22 October 2014 12:18, Ivano Calabrese <alphaemmeo at gmail.com> wrote:

> Hi Thomas,
> I tried to set monitor 1(on telosb_A) but I didn't obtain success. After
> you remind me to use monitor 1 command, I tried again. Now having some
> print debugs I can look that if I set monitor to 1 (on telosb_A), the
> msp430 doesn't receive interrupt signal. Come back to monitor 0, the
> telosb_A restart to receive only after a new transmission (from telosb_A to
> telosb_B).
>
> the same happen if I change A with B.
>
> Best
>
> ____________________________________
> *Ivano Calabrese*, MSc.
> http://www.dei.unipd.it/~icalabre/
> https://www.linkedin.com/in/ivanocalabrese
>
> On 22 October 2014 11:25, Thomas Eichinger <thomas.eichinger at fu-berlin.de>
> wrote:
>
>> Hi Ivano,
>>
>> could you check if it is the same situation if you set the receiving node
>> into
>> promiscuous mode using the shell command
>>
>> monitor 1
>>
>> Reading the cc2420 spec FIFOP should rise independently of the threshold
>> if a
>> valid packet is received.
>>
>> cc2420 data sheet p. 33
>> > When address recognition is enabled the FIFOP pin will remain inactive
>> > until the incoming frame passes address recognition, even if the number
>> > of bytes in the RXFIFO exceeds the programmed threshold.
>>
>> Maybe the address encoding in the default example does not match the
>> cc2420’s decoding rules.
>>
>> Best, Thomas
>>
>> On 21 Oct 2014, at 18:17, Ivano Calabrese <alphaemmeo at gmail.com> wrote:
>>
>> Hi Thomas,
>> debugging the .../RIOT/boards/telosb/driver_cc2420.c  file, I have in void
>> cc2420_init_interrupts(void) the following values:
>> 2014-10-21 17:02:55,338 - INFO # P1IN: x10
>> 2014-10-21 17:02:55,340 - INFO # P1IFG: x10
>> 2014-10-21 17:02:55,341 - INFO # P1IES: x29
>> 2014-10-21 17:02:55,343 - INFO # P1IE: x09
>> 2014-10-21 17:02:55,344 - INFO # P1SEL: x02
>> 2014-10-21 17:02:55,347 - INFO # CC2420_FIFOP: x00
>> 2014-10-21 17:02:55,349 - INFO # CC2420_GIO0: x00
>> 2014-10-21 17:02:55,351 - INFO # CC2420_GIO1: x10
>> 2014-10-21 17:02:55,354 - INFO # CC2420_SFD: x00
>>
>> and these ones in interrupt(PORT1_VECTOR) __attribute__((naked))
>> cc2420_isr(void)
>> 2014-10-21 17:04:06,609 - INFO # P1IN: x00
>> 2014-10-21 17:04:06,610 - INFO # P1IFG: x18
>> 2014-10-21 17:04:06,612 - INFO # P1IES: x29
>> 2014-10-21 17:04:06,614 - INFO # P1IE: x09
>> 2014-10-21 17:04:06,615 - INFO # P1SEL: x02
>>
>> To receive a pkt, the msp430 needs a P1IFG=xxxx xxx1, didn't it?
>> I hope you have some suggestion :)
>>
>> I also tried to change the FIFOP threshold from 127(max) to 20(cc2420
>> default value), but nothing.
>>
>>
>> ____________________________________
>> *Ivano Calabrese*, MSc.
>> http://www.dei.unipd.it/~icalabre/
>> https://www.linkedin.com/in/ivanocalabrese
>>
>> On 21 October 2014 10:08, Ivano Calabrese <alphaemmeo at gmail.com> wrote:
>>
>>> 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
>>>>
>>>>
>>>
>> _______________________________________________
>> 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/20141022/7ea29968/attachment-0001.html>


More information about the devel mailing list