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

Thomas Eichinger thomas.eichinger at fu-berlin.de
Wed Oct 22 20:08:49 CEST 2014


Hi Ivano,

sorry we couldn’t solve this problem in the meanwhile. We have a demo in beginning
of November and most core devs are currently very busy preparing for this.
Coming to your question, I’ll first cite Oleg’s answer to a similar question on the users
mailing list:

> Actually, in the past it turned out to be difficult finding widely available
> and not too expensive Cortex driven platforms with a radio chip. Fortunately,
> it seems that the situation is slowly improving with some new boards popping
> up on the market to fill this gap.
> 
> Currently we're mostly focusing on support for the IoT-Lab M3 nodes [1][2]
> which are used in the FIT IoT-LAB [3]. Although these nodes are only available
> as part of the testbed, the IoT-Lab provides open remote access. Otherwise,
> you might consider using the HikoB Fox [4] which is very similar to the
> IoT-Lab hardware. If you work for some company, you can purchase these boards
> from HikoB. 
> 
> We have also preliminary support for the Atmel SAM R21 [5] which also features
> the same radio transceiver. A more functional support for this platform may
> become available in December.

Additionally there is the Zolertia Z1 [6] somehow a successor to the TelosB with
very similar hardware. The RIOT port for this works (yes even receiving :)) and
got a lot of attention lately.

Also there are new ports emerging for boards running a TI CC2538 (OpenMote [8] and
cc2538dk [7]) while currently in an early stage these got some traction lately.

I can’t give you an explicit recommendation because I don’t know your project
needs and timeframe. If you want we could also discuss this off-list.

Hope this helps somehow.

Best, Thomas

[1] https://www.iot-lab.info/hardware/m3/ <https://www.iot-lab.info/hardware/m3/>
[2] https://github.com/RIOT-OS/RIOT/wiki/Board%3A-IoT-LAB_M3 <https://github.com/RIOT-OS/RIOT/wiki/Board%3A-IoT-LAB_M3>
[3] https://www.iot-lab.info/ <https://www.iot-lab.info/>
[4] http://www.hikob.com/assets/uploads/2014/07/HIKOB_FOX_ProductSheet_EN.pdf <http://www.hikob.com/assets/uploads/2014/07/HIKOB_FOX_ProductSheet_EN.pdf>
[5] http://www.atmel.com/tools/atsamr21-xpro.aspx <http://www.atmel.com/tools/atsamr21-xpro.aspx>
[6] http://www.zolertia.com/ti <http://www.zolertia.com/ti>
[7] http://www.ti.com/tool/cc2538dk <http://www.ti.com/tool/cc2538dk>
[8] http://www.openmote.com/openmote-cc2538/ <http://www.openmote.com/openmote-cc2538/>

> On 22 Oct 2014, at 17:30, Ivano Calabrese <alphaemmeo at gmail.com> wrote:
> 
> 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/ <http://www.dei.unipd.it/~icalabre/>
> https://www.linkedin.com/in/ivanocalabrese <https://www.linkedin.com/in/ivanocalabrese>
> 
> On 22 October 2014 12:18, Ivano Calabrese <alphaemmeo at gmail.com <mailto: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/ <http://www.dei.unipd.it/~icalabre/>
> https://www.linkedin.com/in/ivanocalabrese <https://www.linkedin.com/in/ivanocalabrese>
> 
> On 22 October 2014 11:25, Thomas Eichinger <thomas.eichinger at fu-berlin.de <mailto: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 <mailto: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/ <http://www.dei.unipd.it/~icalabre/>
>> https://www.linkedin.com/in/ivanocalabrese <https://www.linkedin.com/in/ivanocalabrese>
>> 
>> On 21 October 2014 10:08, Ivano Calabrese <alphaemmeo at gmail.com <mailto:alphaemmeo at gmail.com>> wrote:
>> Hi Thomas,
>> I'm using the linked toolchain in the RIOT-OS wiki (http://sourceforge.net/projects/mspgcc/ <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/ <http://www.dei.unipd.it/~icalabre/>
>> https://www.linkedin.com/in/ivanocalabrese <https://www.linkedin.com/in/ivanocalabrese>
>> 
>> On 20 October 2014 18:03, Thomas Eichinger <thomas.eichinger at fu-berlin.de <mailto: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 <mailto: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/ <http://www.dei.unipd.it/~icalabre/>
>>> https://www.linkedin.com/in/ivanocalabrese <https://www.linkedin.com/in/ivanocalabrese>
>>> 
>>> On 20 October 2014 09:37, Ivano Calabrese <alphaemmeo at gmail.com <mailto: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/ <http://www.dei.unipd.it/~icalabre/>
>>> https://www.linkedin.com/in/ivanocalabrese <https://www.linkedin.com/in/ivanocalabrese>
>>> On 17 October 2014 17:20, Thomas Eichinger <thomas.eichinger at fu-berlin.de <mailto: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 <https://github.com/RIOT-OS/RIOT/pull/1830>
>>> 
>>> 
>>>> On 17 Oct 2014, at 16:18, Ivano Calabrese <alphaemmeo at gmail.com <mailto: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/ <http://www.dei.unipd.it/~icalabre/>
>>>> https://www.linkedin.com/in/ivanocalabrese <https://www.linkedin.com/in/ivanocalabrese>
>>>> _______________________________________________
>>>> devel mailing list
>>>> devel at riot-os.org <mailto:devel at riot-os.org>
>>>> http://lists.riot-os.org/mailman/listinfo/devel <http://lists.riot-os.org/mailman/listinfo/devel>
>>> 
>>> 
>>> _______________________________________________
>>> devel mailing list
>>> devel at riot-os.org <mailto:devel at riot-os.org>
>>> http://lists.riot-os.org/mailman/listinfo/devel <http://lists.riot-os.org/mailman/listinfo/devel>
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> devel mailing list
>>> devel at riot-os.org <mailto:devel at riot-os.org>
>>> http://lists.riot-os.org/mailman/listinfo/devel <http://lists.riot-os.org/mailman/listinfo/devel>
>> 
>> _______________________________________________
>> devel mailing list
>> devel at riot-os.org <mailto:devel at riot-os.org>
>> http://lists.riot-os.org/mailman/listinfo/devel <http://lists.riot-os.org/mailman/listinfo/devel>
>> 
>> 
>> 
>> _______________________________________________
>> devel mailing list
>> devel at riot-os.org <mailto:devel at riot-os.org>
>> http://lists.riot-os.org/mailman/listinfo/devel <http://lists.riot-os.org/mailman/listinfo/devel>
> 
> 
> _______________________________________________
> devel mailing list
> devel at riot-os.org <mailto:devel at riot-os.org>
> http://lists.riot-os.org/mailman/listinfo/devel <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/fe9d58dc/attachment-0001.html>


More information about the devel mailing list