RIOT-OS on telosb, issue with default example

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.

I clicked Send in error, before to tell you thanks a lot for the help. :stuck_out_tongue:

best regards.

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


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

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

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

Hi Thomas,

I’m using the linked toolchain in the RIOT-OS wiki ( [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.

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 :slight_smile:

I also tried to change the FIFOP threshold from 127(max) to 20(cc2420 default value), but nothing.

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

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.


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.

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] [2] [3] [4] [5] [6] [7] [8]

Hi Thomas, thanks a lot for your reply and availability, it was very useful.

Good luck for your demo ;).