ping error: Destination off-link but no route
作者 codercjg 在 23 四月 2015, 4:23 下午
在coojar上仿真边缘路由器实验能正常ping通，但移植到iar上下载到cc2530上却总出现Destination off-link but no route ，并且打印的ip地址错位了。
后来发现原来是slip串口rx_buf里收到的数据不对，在linux上用wireshark抓到的ping6数据包发送104字节，而经过串口后到cc2530上却显示只收到102字节。
原来是串口收发有问题，估计是速度快了丢了数据。
解决方法：把通信的波特率由115200改为38400。
修改contiki/cpu/cc253x/dev/uart0.c源码
//UARTSETSPEED(0, UART115M, UART115E);
** UARTSETSPEED(0, UART38M, UART38E);**
然后 sudo ./tunslip6 aaaa::1/64 -s /dev/ttyUSB0 -B 38600 -v6
之后就可以正常ping通了。
相关讨论如下：http://sourceforge.net/p/contiki/mailman/message/29819188/
[Contiki-developers] Frquent Message: slip-bridge: Destination off-link but no route src=aaaa::1 dst=aaaa::12:7400:1466:ab6
From: Kapil
Hi all,> I am getting the statement:> slip-bridge: Destination off-link but no route src=aaaa::1dst=aaaa::12:7400:1466:ab6while pinging the RPL border-router and other nods (UDP server) through RPLborder router. > Its not that I am not able to ping at all but I get this message quitefrequently. I have gone through some other posts related to this, but couldn'tfigure out what is causing the problem.> could it be the problem with some layer selection? When I enable the debugmessages, I could see the message:> Addeed a route via: IPaddress> So it should not be the problem of not having a route to the destination.> I am using nullrdc, csma and sicslowpan drivers for RDC, mac and network.Below is what I get when I try to ping border-router itself> Server IPv6 addresses:> aaaa::212:7400:137b:fa2e> fe80::212:7400:137b:fa2eSIN: 104SUT: 104SIN: 102SIN: 102SIN: 102> slip-bridge: Destination off-link but no route src=aaaa::1dst=aaaa::7400:137b:fa2e:8000SIN: 102> slip-bridge: Destination off-link but no route src=aaaa::1dst=aaaa::200:137b:fa2e:8000SIN: 104SUT: 104SIN: 102> slip-bridge: Destination off-link but no route src=aaaa::1:aaaadst=::212:7400:137b:fa2e:8000SIN: 104SUT: 104SIN: 102> slip-bridge: Destination off-link but no route src=aaaa::1:aaaadst=::212:7400:137b:fa2e:8000SIN: 102And below is the ping statistics:--- aaaa::212:7400:137b:fa2e ping statistics ---41 packets transmitted, 17 received, 58% packet loss, time 40507msrtt min/avg/max/mdev = 24.250/25.042/26.391/0.600 msSo why should there be 58% packet loss, I am just pinging my border-router.> When I simulate same setup in cooja, there is not even a single packet loss.> I am not able to figure out what exactly is the problem?Please helpThanksKapil
Thread view
[Contiki-developers] Frquent Message: slip-bridge: Destination off-link but no route src=aaaa::1 dst=aaaa::12:7400:1466:ab6
From: Kapil
Hi all,> I am getting the statement:> slip-bridge: Destination off-link but no route src=aaaa::1dst=aaaa::12:7400:1466:ab6while pinging the RPL border-router and other nods (UDP server) through RPLborder router. > Its not that I am not able to ping at all but I get this message quitefrequently. I have gone through some other posts related to this, but couldn'tfigure out what is causing the problem.> could it be the problem with some layer selection? When I enable the debugmessages, I could see the message:> Addeed a route via: IPaddress> So it should not be the problem of not having a route to the destination.> I am using nullrdc, csma and sicslowpan drivers for RDC, mac and network.Below is what I get when I try to ping border-router itself> Server IPv6 addresses:> aaaa::212:7400:137b:fa2e> fe80::212:7400:137b:fa2eSIN: 104SUT: 104SIN: 102SIN: 102SIN: 102> slip-bridge: Destination off-link but no route src=aaaa::1dst=aaaa::7400:137b:fa2e:8000SIN: 102> slip-bridge: Destination off-link but no route src=aaaa::1dst=aaaa::200:137b:fa2e:8000SIN: 104SUT: 104SIN: 102> slip-bridge: Destination off-link but no route src=aaaa::1:aaaadst=::212:7400:137b:fa2e:8000SIN: 104SUT: 104SIN: 102> slip-bridge: Destination off-link but no route src=aaaa::1:aaaadst=::212:7400:137b:fa2e:8000SIN: 102And below is the ping statistics:--- aaaa::212:7400:137b:fa2e ping statistics ---41 packets transmitted, 17 received, 58% packet loss, time 40507msrtt min/avg/max/mdev = 24.250/25.042/26.391/0.600 msSo why should there be 58% packet loss, I am just pinging my border-router.> When I simulate same setup in cooja, there is not even a single packet loss.> I am not able to figure out what exactly is the problem?Please helpThanksKapil
Re: [Contiki-developers] Frquent Message: slip-bridge: Destinationoff-link but no route src=aaaa::1 dst=aaaa::12:7400:1466:ab6
From: David Kopf
When the border router gets a packet through SLIP it checks for its owndestination address, if no match it looks up the destination address in therouting table. That error message occurs when there is no match to either;there may be routes in the table but they don’t match.There is some corruption in the serial transfers I think. The successfulpings are to aaaa::212:7400:137b:fa2e, the unsuccessful ones are toaaaa::12:7400:1466:ab6aaaa::7400:137b:fa2e:8000aaaa::200:137b:fa2e:8000::212:7400:137b:fa2e:8000Characters are being lost during the serial transfers because the baud rateis too high, not within tolerance, buffers filling without hardware orsoftware flow control, etc.If this is the econotag on an old Ubuntu, there was a problem with the FTDIdrivers losing two bytes on occasion. Also possible, but not likely, isthe slip buffer is being overwritten during transfer.Run wireshark on the tun0 interface to verify the packets are going out tothe correct address, and run tunslip6 with -v6 to show what is sent andreceived through the serial link. A lower baud rate will help reduce errorsfrom clock rate out of spec.-----Original Message-----From: KapilSent: Monday, September 17, 2012 4:46 AMTo: [email protected]: [Contiki-developers] Frquent Message: slip-bridge:Destinationoff-link but no route src=aaaa::1 dst=aaaa::12:7400:1466:ab6Hi all,> I am getting the statement:> slip-bridge: Destination off-link but no route src=aaaa::1dst=aaaa::12:7400:1466:ab6while pinging the RPL border-router and other nods (UDP server) through RPLborder router.> Its not that I am not able to ping at all but I get this message quitefrequently. I have gone through some other posts related to this, butcouldn'tfigure out what is causing the problem.> could it be the problem with some layer selection? When I enable the> debugmessages, I could see the message:> Addeed a route via: IPaddress> So it should not be the problem of not having a route to the destination.> I am using nullrdc, csma and sicslowpan drivers for RDC, mac and network.Below is what I get when I try to ping border-router itself> Server IPv6 addresses:> aaaa::212:7400:137b:fa2e> fe80::212:7400:137b:fa2eSIN: 104SUT: 104SIN: 102SIN: 102SIN: 102> slip-bridge: Destination off-link but no route src=aaaa::1dst=aaaa::7400:137b:fa2e:8000SIN: 102> slip-bridge: Destination off-link but no route src=aaaa::1dst=aaaa::200:137b:fa2e:8000SIN: 104SUT: 104SIN: 102> slip-bridge: Destination off-link but no route src=aaaa::1:aaaadst=::212:7400:137b:fa2e:8000SIN: 104SUT: 104SIN: 102> slip-bridge: Destination off-link but no route src=aaaa::1:aaaadst=::212:7400:137b:fa2e:8000SIN: 102And below is the ping statistics:--- aaaa::212:7400:137b:fa2e ping statistics ---41 packets transmitted, 17 received, 58% packet loss, time 40507msrtt min/avg/max/mdev = 24.250/25.042/26.391/0.600 msSo why should there be 58% packet loss, I am just pinging my border-router.> When I simulate same setup in cooja, there is not even a single packet> loss.> I am not able to figure out what exactly is the problem?Please helpThanksKapil------------------------------------------------------------------------------Live Security Virtual ConferenceExclusive live event will cover all the ways today's security andthreat landscape has changed and how IT managers can respond. Discussionswill include endpoint security, mobile security and the latest in malwarethreats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/_______________________________________________Contiki-developers mailing [email protected]://lists.sourceforge.net/lists/listinfo/contiki-developers
Re: [Contiki-developers] Frquent Message: slip-bridge: Destinationoff-link but no route src=aaaa::1 dst=aaaa::12:7400:1466:ab6
From: Kapil
David Kopf
Re: [Contiki-developers] Frquent Message: slip-bridge: Destinationoff-link but no route src=aaaa::1 dst=aaaa::12:7400:1466:ab6
From: David Kopf
It appears you have msp430 hardware. I don't know the consequences of thatdefine or the baud rate tradeoff. Since maximum 802.15.4 throughput isaround 150 kilobits/second, serial baud rates below 115200 can become abottleneck that leads to full buffers and lost packets.-----Original Message-----From: KapilSent: Tuesday, September 18, 2012 5:15 AMTo: [email protected]: Re: [Contiki-developers]Frquent Message: slip-bridge:Destinationoff-link but no route src=aaaa::1 dst=aaaa::12:7400:1466:ab6David Kopf
Re: [Contiki-developers] Frquent Message: slip-bridge: Destinationoff-link but no route src=aaaa::1 dst=aaaa::12:7400:1466:ab6
From: Hakan G.
Yore right David but my 15.4a Radio have an throuput of 30 kbyte/secondsand i configured the usart interface to 921600.Im using stm32f103 Platform and i think there are several radio hardwarethat have an higher throuput as ~18kbyte/second like you mentioned.i thought that flow control is if cpu or application is to slow forincoming data.And because incoming data is interrupt controlled there cant be anbottleneck of cpu. What do you mean?Am 18.09.2012 16:33, schrieb David Kopf:> It appears you have msp430 hardware. I don't know the consequences of> that define or the baud rate tradeoff. Since maximum 802.15.4> throughput is around 150 kilobits/second, serial baud rates below> 115200 can become a bottleneck that leads to full buffers and lost> packets.>> -----Original Message----- From: Kapil> Sent: Tuesday, September 18, 2012 5:15 AM> To: contiki-developers@...> Subject: Re: [Contiki-developers]Frquent Message: slip-bridge:> Destinationoff-link but no route src=aaaa::1 dst=aaaa::12:7400:1466:ab6>>> David Kopf
Re: [Contiki-developers] Frquent Message: slip-bridge: Destinationoff-link but no route src=aaaa::1 dst=aaaa::12:7400:1466:ab6
From: David Kopf
I mean, if all incoming RF packets have to be sent through the serial linkto the host, and the incoming rate is a sustained 20 kilobytes/second butthe maximum serial rate is only 10 kilobytes/second, the packets will stackup in the dongle RF/RAM/serial buffers and be lost after they fill,regardless of any serial flow control that prevents the bytes from beinglost once they get buffered. Incoming packets can come from multiple sourcesso the dongle can not control the maximum arrival rate.On output, transmitted RF packets are naturally limited by the rate they canbe sent from the host through the serial link, so even 300 baud would notcause packet losswBut there you have potentially the opposite problem, a 921600 link couldfill the tx queue at 100 kilobytes/second but the RF link can empty it atonly 10 KB/sec. Flow control to stop the host from sending is needed in thatcase. I have seen that on econotags with several ~1KB browser GETs forembedded images in a web page, if more than one connection to the server isallowed. The jackdaw USB link has no flow control and is overwhelmed by aburst of packets to the RNDIS interface (sometimes hanging due to someinsidious bug).-----Original Message-----From: Hakan G.Sent: Tuesday, September 18, 2012 11:10 AMTo: Contiki developer mailing listSubject: Re: [Contiki-developers] Frquent Message: slip-bridge:Destinationoff-link but no route src=aaaa::1 dst=aaaa::12:7400:1466:ab6Yore right David but my 15.4a Radio have an throuput of 30 kbyte/secondsand i configured the usart interface to 921600.Im using stm32f103 Platform and i think there are several radio hardwarethat have an higher throuput as ~18kbyte/second like you mentioned.i thought that flow control is if cpu or application is to slow forincoming data.And because incoming data is interrupt controlled there cant be anbottleneck of cpu. What do you mean?Am 18.09.2012 16:33, schrieb David Kopf:> It appears you have msp430 hardware. I don't know the consequences of> that define or the baud rate tradeoff. Since maximum 802.15.4> throughput is around 150 kilobits/second, serial baud rates below> 115200 can become a bottleneck that leads to full buffers and lost> packets.>> -----Original Message----- From: Kapil> Sent: Tuesday, September 18, 2012 5:15 AM> To: contiki-developers@...> Subject: Re: [Contiki-developers]Frquent Message: slip-bridge:> Destinationoff-link but no route src=aaaa::1 dst=aaaa::12:7400:1466:ab6>>> David Kopf
Re: [Contiki-developers] Frquent Message: slip-bridge: Destination off-link but no route src=aaaa::1 dst=aaaa::12:7400:1466:ab6
From: Hakan G.
Hi,i have seen this msg if i try to ping or send to an node that isntlocated by Border Router.The msg disappear after the Border Router locate the node.But i also seen this if i stresstest the radio by sending higherfrequent ping commands. then the msg appear with random src and dstadress.Doesnt make sense but then i found the note below in ringbuf.c Ithink there is a plausibility that race condition can occur. I dontfigured out. But ARM CPU have an own mechanism to be atomic for memoryand peripheral access. the keyword is bit-Banding. What platform you use?/* XXX: there is a potential risk for a race condition here, because the ->get_ptr field may be written concurrently by the ringbuf_get() function. To avoid this, access to ->get_ptr must be atomic. We use an uint8_t type, which makes access atomic on most platforms, but C does not guarantee this. */regardsH.G.Am 17.09.2012 10:46, schrieb Kapil:> Hi all,>>> I am getting the statement:>> slip-bridge: Destination off-link but no route src=aaaa::1> dst=aaaa::12:7400:1466:ab6> while pinging the RPL border-router and other nods (UDP server) through RPL> border router.>>> Its not that I am not able to ping at all but I get this message quite> frequently. I have gone through some other posts related to this, but couldn't> figure out what is causing the problem.>>> could it be the problem with some layer selection? When I enable the debug> messages, I could see the message:>> Addeed a route via: IPaddress>> So it should not be the problem of not having a route to the destination.>> I am using nullrdc, csma and sicslowpan drivers for RDC, mac and network.> Below is what I get when I try to ping border-router itself>>> Server IPv6 addresses:>> aaaa::212:7400:137b:fa2e>> fe80::212:7400:137b:fa2e> SIN: 104> SUT: 104> SIN: 102> SIN: 102> SIN: 102>> slip-bridge: Destination off-link but no route src=aaaa::1> dst=aaaa::7400:137b:fa2e:8000> SIN: 102>> slip-bridge: Destination off-link but no route src=aaaa::1> dst=aaaa::200:137b:fa2e:8000> SIN: 104> SUT: 104> SIN: 102>> slip-bridge: Destination off-link but no route src=aaaa::1:aaaa> dst=::212:7400:137b:fa2e:8000> SIN: 104> SUT: 104> SIN: 102>> slip-bridge: Destination off-link but no route src=aaaa::1:aaaa> dst=::212:7400:137b:fa2e:8000> SIN: 102>> And below is the ping statistics:>>> --- aaaa::212:7400:137b:fa2e ping statistics ---> 41 packets transmitted, 17 received, 58% packet loss, time 40507ms> rtt min/avg/max/mdev = 24.250/25.042/26.391/0.600 ms>>> So why should there be 58% packet loss, I am just pinging my border-router.>> When I simulate same setup in cooja, there is not even a single packet loss.>> I am not able to figure out what exactly is the problem?>> Please help>> Thanks> Kapil>>>>>
分类: Contiki | 评论
RPL Border Router
作者 codercjg 在 21 四月 2015, 11:05 下午
Introduction:
Border routers are routers that can be found at the edge of a network. Their function is to connect one network to another. In this tutorial we will learn how to run a simulation using the border router in Contiki 2.7. In the example which we will discuss in the rest of this tutorial the border router will be used to route data between a WSN (RPL network) and an external IP network.
Objective
The objective of this tutorial is to give you an understanding of the RPL Border Router code in Contiki 2.7 OS and learn how to simulate a network with a border router on Cooja
At the end of the tutorial you would have learnt the following:
- Understanding the working of the rpl border router code2. Starting a simulation on Cooja simulator.3. Observing and validating the results
Code building blocks.
We will be using the following files - border-router.c2. udp-server.c (udp-client.c can also be used)3. slip-bridge.c (It contains callback function for processing a SLIP connection request)4. httpd-simple.c (A simple web server forwarding page generation to a protothread)
udp-server nodes will form a DAG with the border router set as the root. The border router will receive the prefix through a [SLIP][1] (Serial Line Interface Protocol) connection and it will be communicated to the rest of the nodes in the RPL network.
Refer to the following code snippets in the file border-router.c In this piece of code the node configured as the border router waits for the prefix to be set. Once it receives the prefix, the border router is set as the root of the DAG after which it sets the prefix of the rest of the nodes in the network.
/* Request prefix until it has been received */ while(!prefix_set) { etimer_set(&et, CLOCK_SECOND); request_prefix(); PROCESS_WAIT_EVENT_UNTIL(etimer_expired(&et)); } dag = rpl_set_root(RPL_DEFAULT_INSTANCE,(uip_ip6addr_t )dag_id); if(dag != NULL) { rpl_set_prefix(dag, &prefix, 64); PRINTF("created a new RPL dag\n"); }
By default the border router hosts a simple web page. However, this can be disabled by defining WEBSERVER as seen the code snippet below. This webpage is displayed when the IPv6 address of the border router is entered in the browser. Refer to the file httpd-simple.c for the following code snippet
PROCESS(border_router_process, "Border router process");#if WEBSERVER==0/ No webserver /AUTOSTART_PROCESSES(&border_router_process);#elif WEBSERVER>1/ Use an external webserver application */#include "webserver-nogui.h"AUTOSTART_PROCESSES(&border_router_process,&webserver_nogui_process);
Compiling the code
The code for RPL border router can be found at /contiki-2.7/examples/ipv6/rpl-border-router. Use the following command to compile the code for the border router
cd /contiki-2.7/examples/ipv6/rpl-border-router make TARGET=sky.
Once this command has been successfully executed, a file named border-router.sky will be created. This file will be used to program one of the motes as the border router on Cooja. For the purpose of this tutorial we will select TMote Sky as our target.
In order to demonstrate the functionality of the border router we will create a network of nodes with the border router as the root. For creating such a network we will user the udp-server.c code. This code can be found at /contiki-2.7/examples/ipv6/rpl-udp . Use the following command to compile the code for rpl-udp
cd /contiki-2.7/examples/ipv6/rpl-udp make TARGET=sky
Once this command has been successfully executed a file named udp-server.sky will be created. This file will be used to program the remaining nodes in Cooja simulator. These nodes will form a DAG with the rpl border router as the root.
Testing on Cooja
Upon the successful completion of the above mentioned steps we are ready to create a simulation in Cooja. Start the Cooja simulator using the following command
cd /contiki-2.7/tools/cooja ant run
When the GUI launches execute the following steps to create a simulation. - From ‘File’ select ‘New Simulation’. Select ‘UDGM’, enter the name of the simulation and click on ‘create’.2. Click on ‘Motes’. From the drop down menu select ‘Add New Motes’ followed by ‘Create new motes’ and select the mote type as ‘Sky’.3. Browse to the location ‘/contiki-2.7/examples/ipv6/rpl-border-router’ and select the file rpl-border-router.sky. Click on ‘Create’. Add one mote of this type.4. Repeat step 2 and 3 but this time browse to the location /contiki-2.7/examples/ipv6/rpl-udp’ and select the file udp-server.sky. Add 3 – 4 motes of the type udp-server5. Once the motes have been added you can position the motes.
Cooja motes.png
Select the options under View as shown below. These will help you creating a topology of your choice.
Motes view.png - Now, we need to create a bridge between the RPL network simulated on Cooja and the local machine. This can be done by right clicking on the mote which is programmed as the border router. Select ‘More tools for border router’ and then select ‘Serial Socket (SERVER)’. You will get the following message on the successful completion of this step.Note that the message says ‘Listening on port 60001′
Serial Socket.png - Now start the simulation by clicking on Start
Tunslip utility
As mentioned in the introduction a border router helps in connecting one network to another. In this example the border router is used to route data between an RPL network and an external network. Till now we have only created the RPL network. Now we need to simulate the scenario in which this RPL network is connected to an external network. For this purpose we will use the Tunslip utility provided in Contiki. In this example tunslip creates a bridge between the RPL network and the local machine. tunslip6.c can be found in /contiki-2.7/tools Compile the tunslip6 code.
make tunslip6
Make a connection between the RPL network and your local machine.
sudo ./tunslip6 -a 127.0.0.1 aaaa::1/64
On the successful execution this command the following output will be printed on the terminal.
slip connected to127.0.0.1:60001''opened tun device/dev/tun0''ifconfig tun0 inethostnameupifconfig tun0 add aaaa::1/64ifconfig tun0 add fe80::0:0:0:1/64ifconfig tun0tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 inet addr:127.0.1.1 P-t-P:127.0.1.1 Mask:255.255.255.255 inet6 addr: fe80::1/64 Scope:Link inet6 addr: aaaa::1/64 Scope:Global UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:500 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)Rime started with address 0.18.116.1.0.1.1.1MAC 00:12:74:01:00:01:01:01 Contiki 2.7 started. Node id is set to 1.CSMA ContikiMAC, channel check rate 8 Hz, radio channel 26Tentative link-local IPv6 address fe80:0000:0000:0000:0212:7401:0001:0101Starting 'Border router process' 'Web server'*** Address:aaaa::1 => aaaa:0000:0000:0000Got configuration message of type PSetting prefix aaaa::Server IPv6 addresses: aaaa::212:7401:1:101 fe80::212:7401:1:101
Go back to the Cooja simulator GUI and look at the dialogue box. The message has now changed to ‘Client connected: /127.0.0.1′
Client Connected.png
Verifying Results
You can verify that the address of the border router has been set by using the ping command.
user@instant-contiki:~/contiki-2.7$ ping6 aaaa::212:7401:1:101PING aaaa::212:7401:1:101(aaaa::212:7401:1:101) 56 data bytes64 bytes from aaaa::212:7401:1:101: icmp_seq=1 ttl=64 time=86.0 ms64 bytes from aaaa::212:7401:1:101: icmp_seq=2 ttl=64 time=33.6 ms64 bytes from aaaa::212:7401:1:101: icmp_seq=3 ttl=64 time=82.3 ms64 bytes from aaaa::212:7401:1:101: icmp_seq=4 ttl=64 time=43.3 ms64 bytes from aaaa::212:7401:1:101: icmp_seq=5 ttl=64 time=70.1 ms^C--- aaaa::212:7401:1:101 ping statistics ---5 packets transmitted, 5 received, 0% packet loss, time 4006msrtt min/avg/max/mdev = 33.669/63.090/86.015/20.985 ms
You can also ping one of the other nodes in the network. Here we are pinging node 4
user@instant-contiki:~/contiki-2.7$ ping6 aaaa::212:7404:4:404PING aaaa::212:7404:4:404(aaaa::212:7404:4:404) 56 data bytes64 bytes from aaaa::212:7404:4:404: icmp_seq=1 ttl=63 time=670 ms64 bytes from aaaa::212:7404:4:404: icmp_seq=2 ttl=63 time=703 ms64 bytes from aaaa::212:7404:4:404: icmp_seq=3 ttl=63 time=746 ms64 bytes from aaaa::212:7404:4:404: icmp_seq=4 ttl=63 time=674 ms^C--- aaaa::212:7404:4:404 ping statistics ---5 packets transmitted, 4 received, 20% packet loss, time 4001msrtt min/avg/max/mdev = 670.230/698.666/746.619/30.514 msuser@instant-contiki:~/contiki-2.7$
The IPv6 address of a node can be checked from the log screen on Cooja. Filter the nodes by their ID
You can enter the address of the border router in the web browser. The border router hosts a page which will be displayed on the browser as shown below.
Common Issues
- Make sure that you enter the IPv6 address properly in the command sudo ./tunslip6 -a 127.0.0.1 aaaa::1/64 . There should be no spaces in aaaa::1/64. Otherwise the code will give unexpected behavior.2. When you pause the simulation the SLIP connection is lost. It might not work properly on resuming the simulation. In such cases reload the simulation. Create a fresh SLIP connection and then run the simulation again.
References
[2] https://github.com/njh/contiki/blob/master/cpu/mc1322x/doc/rpl-tutorial.md[3] Using the Contiki Cooja Simulator – Anuj Sehgal
quote from: http://anrg.usc.edu/contiki/index.php/RPL_Border_Router
I think the site http://anrg.usc.edu/contiki/index.php is good for learning contiki os.
分类: Contiki | 评论
Cmder 命令行工具
作者 codercjg 在 20 四月 2015, 9:03 上午
windows自带的命令行工具太烂了，有一个cmder软件非常好用。
完整版比较大，可以下个cmder mini版
下载地址： http://gooseberrycreative.com/cmder/
xp下运行不了，需要下载一个补丁覆盖cmder.exe
补丁地址： http://gooseberrycreative.com/cmder/
xp下可运行版本，已用补丁替换的 http://pan.baidu.com/s/1mgzfg1q
安装好后，还会出现中文乱码和字符重叠，解决方法如下：
1，中文乱码：
将下面的4行命令添加到cmder/config/aliases文件末尾
l=ls --show-control-chars
la=ls -aF --show-control-chars
ll=ls -alF --show-control-chars
ls=ls --show-control-chars -F
2，此时，乱码没有了，但是中文字还会重叠，操作如下
通过快捷键win+alt+p:打开设置面板，去掉Monospace前面的勾选
quote from: http://www.cnblogs.com/wenber/p/3740948.html
分类: 工具 | 评论
cc253x Socs Memory Spaces
作者 codercjg 在 19 四月 2015, 9:52 下午
quote from https://github.com/contiki-os/contiki/wiki/8051-Memory-Spaces#wiki-The_Stack
8051 Memory Spaces
Paul Sokolovsky edited this page May 7, 2013
· 8 revisions
TI’s cc2x3x SoCs are based on the Intel 8051 microcontroller. This is a harvard-based architecture, which means that program memory and data memory are separate. Terms such as .bss, .text etc don’t apply.
Compared to other CPUs running Contiki, the 8051 has a couple of unique characteristics: The first is its very limited stack, the second is code banking. This guide’s ulterior motives is to highlight the stack-related limitations and to point out a few tips to keep in mind when writing 8051 code. Following these tips will help you avoid stack overflows and frustration.
This guide only applies to contiki’s 8051-based platforms. If you are using some other micro, such as AVR or MSP430, information in this page is totally irrelevant.
This introductory page aims to describe the basics and only focuses on SoCs supported by Contiki. It is not intended as a replacement for the SDCC manual nor the SoC datasheets. Please see the reference list.
Table of Contents
SoC Physical Memory and Memory SpacesPhysical Memory
Memory Spaces
SDCC Terminology
Building Software with SDCCSDCC Memory Models. Variables, Function Parameters and the Stack
The Stack
Understand (and Avoid) Stack OverflowsTips
More Reading
SoC Physical Memory and Memory Spaces
First, we need to understand our hardware’s physical memory and memory addressing scheme.
Physical Memory
The physical memory on SoCs has the following parts:
Flash: Aimed for program code and const data.
Static RAM – (S)RAM: For data memory
Special Function Registers (SFRs): To control the hardware
Flash Information Page (Info Page): Device information and configuration
XREG: Additional registers, which are not called SFRs for reasons that will become clear below.
Memory Spaces
In very simple terms, the 8051-based SoCs have 4 distinct but partially overlapping memory spaces: DATA, CODE, SFR and XDATA.
CODE: Read-only program memory. Can address 64KB. Maps the flash.
DATA: Fast access (single instruction), read/write data memory. Addresses 256 Bytes. Maps the SRAM.The lower 128 bytes of DATA can be addressed either directly or indirectly.
The upper 128 bytes of DATA can be addressed only indirectly.
SFR: Read/Write register memory, directly accessible by a single CPU instruction.SFR registers whose address is divisible by eight are also bit-addressable.
XREGs are NOT mapped in SFR (which is why they are not called SFRs)
XDATA: Slow access (4-5 instruction cycles, usually), 16-bit wide, read/write data memory. XDATA addresses the entire RAM (including stuff addressed by DATA). It also addresses SFRs, parts of the flash, RF registers, XREGs. On the cc2530, XDATA also maps the Info Page.
SDCC Terminology
SDCC uses its own terms (storage classes) to describe memory locations. On most (but not all) cases, it is easy to understand which hardware memory space each storage class refers to. The table below disambiguates.
Mapping between physical memory, hardware memory spaces and SDCC storage classes
SoC Memory Space
SDCC
Storage Class Specifier
Physical Memory
XDATA
xdata / far / external RAM
__xdata
or __far
SRAM, (parts of) Flash,SFR, RFR, XREG, Info Page…
DATA
idata / internal RAM
__idata
SRAM
lower 128 bytes of DATA(the directly-addressable part)
data / near
__data
or __near
SRAM
lower 256 bytes of XDATA
pdata / Paged Data
__pdata
SRAM
CODE
code
__code
Flash
SFR
sfr
__sfr
or __sfr16
or __sfr32
or __sbit
SFR
Building Software with SDCC
Now that we understand our hardware, we need to understand what variables will get allocated to which memory space. This is heavily influenced by SDCC’s command line arguments (or #pragma
directives which achieve similar things but are not discussed here).
SDCC Memory Models. Variables, Function Parameters and the Stack
When building code for 8051-compatible micros, SDCC uses one out of a possible four memory models: Small, Medium, Large, Huge. These are specified in the command line using the option --model-foo
(e.g. --model-large
). The choice of memory model influences the following things:
Allocation strategy for variables lacking a storage class specifier.
Code banking strategy
This guide focuses on the former. More on the latter in the guide on code banking.
The user also has the choice of enabling an option called --stack-auto
. The presence of --stack-auto
(or lack thereof) influences the allocation strategy for function parameters and automatic variables. This also has an indirect but very important implication on function re-entrancy.
When --stack-auto
is not specified, the default action of the compiler is to place local variables in the internal or external RAM (depending on memory model). This in fact makes those variables behave as if they were static! Thus, without --stack-auto
, functions are non-reentrant. When --stack-auto
is specified, local variables are moved to the stack.
If this sounds confusing, the table below lists a bunch of variable declaration examples and shows how they will be allocated for various memory model / stack-auto combinations.
SDCC Memory Models and Variable Allocation
Example Code
Small
Medium
Large / Huge
Small + stack-auto
Medium + stack-auto
Large / Huge + stack-auto
File Scope
int foo;
data
pdata
xdata
data
pdata
xdata
static int foo;
data
pdata
xdata
data
pdata
xdata
__data int foo;
data
data
data
data
data
data
__xdata int foo;
xdata
xdata
xdata
xdata
xdata
xdata
__data static int foo;
data
data
data
data
data
data
__xdata static int foo;
xdata
xdata
xdata
xdata
xdata
xdata
Local Scope
int foo;
data
pdata
xdata
stack
stack
stack
static int foo;
data
pdata
xdata
data
pdata
xdata
__data int foo;
data
data
data
error
error
error
__xdata int foo;
xdata
xdata
xdata
error
error
error
__data static int foo;
data
data
data
data
data
data
__xdata static int foo;
xdata
xdata
xdata
xdata
xdata
xdata
Function Parameters
void bar(int a, int b, int c);
data
pdata
xdata
registers and stack
registers and stack
registers and stack
Due to Contiki’s size, it will not compile without --stack-auto
. For the same reason, the small and medium memory models are unsuitable. Therefore, for all 8051-based ports, we use either the large or huge memory model.
The Stack
By now it should be clear which variables get allocated to the stack and how the developer may influence this. This is all very important because the 8051′s stack is very limited. Basically, the stack resides in the DATA memory space. DATA also hosts bit variables, R0-R7 register banks and variables placed there by the developer. The stack goes and sits in whatever’s left in DATA. Thus, the absolute theoretical maximum stack depth is 256 bytes, assuming nothing else resides in DATA. Contiki’s 8051-based ports leave 223 bytes for the stack.
Understand (and Avoid) Stack Overflows
As seen above, our stack’s maximum depth is 223 bytes. This is very important: If during a particular execution branch we get more bytes on the stack, the node will crash spectacularly. A few tips will help you write stack-friendly code. Let’s first summarise the variable allocation rules from previous sections (for --model-large
(or -huge
) --stack-auto
):
A variable declared with a storage class is allocated where the storage class says.Local, non-static variables may not be declared with a storage class (this leads to a compiler error).
A dynamic, locally scoped variable gets allocated on stack and destroyed when it falls out of scope.
Global variables get allocated to external RAM (XRAM).
Static variables (regardless of scope) get allocated to external RAM (XRAM).
A const is allocated on flash, thus shares space with code.
Each function call places bytes on the stack, which are removed when the function returns. Exactly how many bytes depends on the number and type of its parameters and return value.
Tips
Careful when allocating big variables dynamically. If you define a 50 byte long struct and allocate a variable of that type on stack, you are playing with fire. Only do this if you really know that the variable will fall out of scope safely without crashing the node.
When writing a new function, don’t use more arguments than necessary
Aim to use the smallest datatype possible. For instance, if you only need int8_t
, use int8_t
and not int
.
Avoid printf()
like the devil, especially calls with many arguments.
Bear in mind that an interrupt may occur while the stack is deep.
Let’s elaborate a few of the above with an example:
struct some_big_struct { uint32_t first_field; uint32_t second_field; uint8_t and_a_buffer[64];};static struct some_big_struct do_this; /* This goes to XDATA /int some_function { struct some_big_struct eeek; / Doing this is asking for trouble / unsigned char huge_buffer[128]; / and so is this / / This is a very evil printf / printf("Avoid this way of printing the values of a, b, c and d, which are %u, %lu, %lu and %d respectively\n", a, b, c, d); / This is somewhat safer but will increase code footprint... */ printf("Vals: \n"); printf("a= %u ", a); printf("b= %lu ", b); printf("c= %lu ", c); printf("d= %d\n", d);}
In the example above, some_big_struct
is 72 bytes long. The eeek
variable, is local scope and allocated dynamically. See rules above, this will get allocated on stack. This means that you just used about 30% of our MCU’s stack on a single variable.
The do_this
variable is allocated in XRAM, of which we have just under 8KBytes. This variable also consumes 72 bytes but it won’t crash our node. However, there are two downsides: i) we still need to be careful not to overassign and exhaust our XRAM space. ii) This variable is static. Once it’s allocated, it will stay there. Forever. So if you only every use it once during the software’s lifetime, you are again effectively wasting valuable space.
At the end of the day, it’s a design decision and you need good understanding of what your software is doing.
Pros
Cons
On Stack
It will fall out of scope when no longer used
Ideal when we won’t be using the variable for the entire software lifecycle
It may lead to stack overflows
Overallocating will lead to a crash: The toolchain does not warn us at all
On XDATA
Ideal when the varible will be used a lot
Takes burden away from the stack
Overallocating is easy to debug: The linker throws an error
Once declared, the space is reserved “forever”
May result in “Insufficient XRAM errors” (but this happens at build time)
More Reading
SDCC Manual: “SDCC Compiler User Guide” (In revision 7399, 2012 – 03 – 04, the relevant sections are: sec. 3.4.1 “MCS51/DS390 Storage Class Language Extensions” and 3.18.1 “MCS51 Memory Models”)
cc253x/4x User Guide (Rev. C), Sec 2.2 “Memory”: “CC253x System-on-Chip Solution for 2.4-GHz IEEE 802.15.4 and ZigBee® Applications (Literature Number: SWRU191C April 2009–Revised January 2012)”
CC2430 Data Sheet (rev. 2.1) SWRS036F, Sec 11.2 “Memory”: “A True System-on-Chip solution for 2.4 GHz IEEE 802.15.4 / ZigBee®“