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

Ivano Calabrese alphaemmeo at gmail.com
Wed Oct 22 12:18:57 CEST 2014


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/19bf0f55/attachment-0001.html>


More information about the devel mailing list