Experimental Evaluation of RPL routing protocol

Conducted by

Ressources

Description

Experimental Evaluation of RPL routing protocol (with the default OF) to evaluate the dynamics of the logical topology, the overhead and the delivery rate.

Significant results

- A strong stability of the path length despite an instability
of the physical topology;
- the stabilization of the logical routing structure takes
time and is subject to change;
- despite the efficiency of the routing protocol to find shortest path, the delivery rate is quite low in particular for very dense networks;
- the major part of the IPv6 traffic is composed by control packets ;
- Presence of important bottlenecks in the network

Illustrating chart picture

IEEE 802.15.4 experimental evaluation

Conducted by

Ressources

Description

We aim here at experimentally measure the performance of IEEE 802.15.4 in multihop topologies (pdr, QoS, etc.)

Significant results

in progress

Migration of the existing sites from September to December

We will proceed by steps for the transition to this new architecture.

1. In September, Grenoble and Rennes sites will be closed, then re-opened with the new architecture in alpha-test version. This version will be private to the dev team and some selected users.
2. In October, the beta-test version will be deployed in Grenoble and Rennes. This beta-test phase will be public.
3. In December, Lille and Strasbourg sites will also run under the new architecture. We will then have a beta-test phase with all SensLAB sites.

Keep working during the migration

Public IPv6 addresses on nodes with servers on an IPv4 connected private network.

Conducted by

Ressources

Description

I gave an IPv6 access from the internet to a sensor network. Where the virtual machine, acting as router between internet and the sensor network has only an IPv4 connectivity.

On the senslab platform, a network was built with RPL routing and a border router making the link between the wireless network and the virtual machine using SLIP.

To get public IPv6 addresses, I used a IPv6 over IPv4 tunnel offered by http://www.gogo6.com/freenet6/tunnelbroker.

I got a /56 tunnel, that allowed me to give a /64 prefix for the sensor network and use another /64 prefix for the configuration.

So each node on the network was accessible from the outside with public IPv6 addresses.

Significant results

I could ping all the nodes on the platform from the internet using their IPv6 addresses, and I could access the webserver that was running on the border router node.

It also work when setting up one virtual machine from another senslab site as an IPv6 router, and route the packets for the sensor network to the VM where the experiment is running.
It is a scenario that may be what the IPv6 deployment on senslab will be: One IPv6 router that gives prefixes to running experiments and routes the packets.

IPv6 Communication between nodes from different sites

Conducted by

Ressources

Description

I tried to establish communication between a node from Grenoble and a node from Strasbourg using IPv6.

On each platform, a network was built with RPL routing and a border router making the link between the wireless network and the virtual machine using SLIP. The nodes in the network where idle, except one on Grenoble running a ’ping6’ application with one node from Strasbourg as destination.

The difficulty is that the virtual machines are on private networks only accessible trough ssh.

Significant results

It works with the following setup:

I looked at ways to built vpn over SSH. It is not possible to use the tunneling feature of ssh because there is no direct access to root account with ssh. So I ended up building a PPP tunnel over SSH like described in this tutorial http://www.tldp.org/HOWTO/ppp-ssh/index.html.

I set up 3 different subnets, one for each part of the network, the wireless networks and the VPN. And I established routes going through the VPN to link the two platforms.

The route of packet is:
Subnet: ”aaaa::\64”
Ping6 Node -> Node -> Node -> Border router: via Radio
Border router -> Virtual Machine: via the serial link
Subnet: ”cccc::\64”
Virtual Machine -> Virtual Machine: via PPP tunnel
Subnet: ”bbbb::\64”
Virtual Machine -> Border router: via the serial link
Border router -> Node -> Destination Node: via Radio
I only wanted to test if a route could be established, I didn’t checked the quality of the connection.

Softwares used:
Contiki + ping6 app (senslab site version)
tunslip6
ip linux command
ssh + ppp

Illustrating chart picture

This page will describe how to perform programming and debugging on a senslab node using a dedicated board and a JTAG debug interface with a Linux operating system. This guide will start with the description of the different hardware systems and the required software, then explain how to setup the different parts. And finally a demonstration of how to do debugging and interact with the serial interface based on an example.

The first picture shows the complete hardware programming/debugging system

Hardware Description

Senslab nodes

There are two types of nodes, with two types of radio chip.

They can be differentiated with their antenna, the cc1101 has a PCB antenna and the cc2420 an antenna in a chip

• The first is a Senslabv13b node with cc1101 radio chip
• The second is a Senslabv14 node with cc2420 radio chip

Node power supply methods

You can power the nodes by 3 ways.

1. Non rechargeable battery (Nominal voltage = 4V)
   Plug the positive and negative battery pins to the JP4 connector (bottom side)
   Put a jumper in the “pile” position on JP5 (top side)
2. Rechargeable battery (Varta Polyflex 383562)
   Plug the positive and negative battery pins to the JP4 connector (bottom side)
   Put a jumper in the “bat” position on JP5 (top side)
   or
   Connect the positive pin of the battery to JP1:1 and the negative pin to JP1:25
   No jumpers are needed on the node.
3. External DC (5V to 6.5V)
   Apply a DC voltage between 5V and 6.5V at JP1:26 (Ext supply) and JP1:25 (GND)
   No jumpers are needed on the node.

Dock board

The Dock board does the interface between the senslab node and the PC + JTAG

• The first is the new generation usb dock board
• The second is the first generation serial dock board (with a senslabv13b node and a battery plugged)

Jumpers configuration

For the new generation usb dock boards, in order to have external DC from USB connector to power up the node, jumpers should be put on VCC and VEXT.

TI MSP-FET430UIF programmer

“The MSP-FET430UIF is a powerful flash emulation tool to quickly begin application development on the MSP430 MCU. It includes USB debugging interface used to program and debug the MSP430 in-system through the JTAG interface or the pin saving Spy Bi-Wire (2-wire JTAG) protocol. The flash memory can be erased and programmed in seconds with only a few keystrokes, and since the MSP430 flash is ultra-low power, no external power supply is required.”
Source: http://processors.wiki.ti.com/index.php/MSP-FET430UIF

It can be ordered at the usual electronic components retailers for less than 100€, like for example:
Digikey : http://www.digikey.fr/
Farnell : http://fr.farnell.com
Radiospares: http://radiospares-fr.rs-online.com/

Software description

Compilation toolchain

Compiling programs requires ‘msp430-gcc‘ (version 3.X.X), ‘msp430-libc‘ and ‘msp430-binutils' packages.
msp430-gcc with versions >= 4.X.X are not supported. If you cannot find the correct packages for your system, you can use your senslab virtual machine to compile programs.

Connection to the board JTAG interface

Connecting to the MSP-FET430UIF debug interface requires two things:

1. ‘ti_usb_3410_5052‘ driver which provides a /dev serial interface for the programmer to the operating system
2. ‘mspdebug‘ uses this serial interface to control the jtag port of the board and provides the basic commands for debugging, but it doesn’t directly make the link with the C sources files. Therefore it can act as a proxy for msp430-gdb which is able to do it.

There is a “Connection closing” issue with version 0.17, so gdb will not know when a breakpoint is reached without interrupting it with ‘Ctrl+c’. I would advice you to use an older or newer one (like the git version)

Access the uart of the node

The second usb cable provides power to the board and gives the PC access to the node uart. The system should recognize it as a /dev tty interface and the communication can be done with a software like ‘gtkterm‘ or ‘moserial‘ which can receive and send characters to the serial interface.

The debugger

The ‘msp430-gdb‘ debugger can use ‘mspdebug‘ as a remote target and do C-level debugging.
The ‘ddd‘ can be used as a graphical interface to any gdb software.

Development tools configuration/installation

MSP-FET430UIF

Plugging the programmer

Plug the JTAG usb at first and then the usb alimentation cable to guaranty the ‘/dev/ttyUSB#‘ interface numbers that will be assigned to each cable.
The output from dmesg command should look like the followings.

• After plugging the JTAG interface MSP-FET430UIF:

$ dmesg
....
usb 5-2: new full speed USB device using uhci_hcd and address 10
usb 5-2: New USB device found, idVendor=0451, idProduct=f430
usb 5-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 5-2: Product: MSP-FET430UIF JTAG Tool
usb 5-2: Manufacturer: Texas Instruments
usb 5-2: SerialNumber: TUSB34103D464945D858FFAF
usb 5-2: configuration #1 chosen from 1 choice
ti_usb_3410_5052 5-2:1.0: TI USB 3410 1 port adapter converter detected
usb 5-2: firmware: requesting ti_usb-v0451-pf430.fw
usb 5-2: firmware: requesting ti_3410.fw
usb 5-2: reset full speed USB device using uhci_hcd and address 10
usb 5-2: device firmware changed
ti_usb_3410_5052: probe of 5-2:1.0 failed with error -5
usb 5-2: USB disconnect, address 10
usb 5-2: new full speed USB device using uhci_hcd and address 11
usb 5-2: New USB device found, idVendor=0451, idProduct=f430
usb 5-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 5-2: Product: MSP-FET430UIF JTAG Tool
usb 5-2: Manufacturer: Texas Instruments
usb 5-2: SerialNumber: TUSB34103D464945D858FFAF
usb 5-2: configuration #1 chosen from 2 choices
ti_usb_3410_5052 5-2:1.0: TI USB 3410 1 port adapter converter detected
ti_usb_3410_5052: probe of 5-2:1.0 failed with error -5
ti_usb_3410_5052 5-2:2.0: TI USB 3410 1 port adapter converter detected
usb 5-2: TI USB 3410 1 port adapter converter now attached to ttyUSB0

Don’t care about the “ti_usb_3410_5052: probe of 5-2:1.0 failed with error -5” error message.

• After plugging the alimentation + serial USB cable:

$ dmesg
....
usb 5-1: new full speed USB device using uhci_hcd and address 12
usb 5-1: New USB device found, idVendor=0403, idProduct=6001
usb 5-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
usb 5-1: Product: USB  Serial
usb 5-1: Manufacturer: FTDI
usb 5-1: configuration #1 chosen from 1 choice
ftdi_sio 5-1:1.0: FTDI USB Serial Device converter detected
usb 5-1: Detected FT232BM
usb 5-1: Number of endpoints 2
usb 5-1: Endpoint 1 MaxPacketSize 64
usb 5-1: Endpoint 2 MaxPacketSize 64
usb 5-1: Setting MaxPacketSize 64
usb 5-1: FTDI USB Serial Device converter now attached to ttyUSB1

Problems solving

He are the different issues we were confronted to

• Everything looks good, but it does not work. It happened the first time the interface was used on a computer or it happened sometimes for no specific reasons Try to unplug/re-plug both cables, it fixes the problem in most cases.
  The time it did not worked, changing the dock board fixed the problem.
• The ti_usb_3410_5052 driver is not installed. I can’t be of any help on this issue as I did not got the problem. I would advice you to take a look to the Low-Level USB VCP Drivers at http://processors.wiki.ti.com/index.php/MSP430_JTAG_Interface_USB_Driver and give us feedback if you got the problem.
• If you get a message in dmesg outputs saying

usb 1-2.1: ti_download_firmware - firmware not found

the system is looking for a file called ‘ti_usb-3410.bin‘ which is in practice called ‘ti_3410.fw‘. The solution is to create a symbolic link with the command:

 sudo ln -s /lib/firmware/ti_3410.fw /lib/firmware/ti_usb-3410.bin

Source: MSPGCC Wiki/Windows msp430-gdbproxy on Linux Howto

msp430-gdb, mspdebug and ddd

Installation

You can install them from your distribution package repository if they are available. Or install them from mspgcc and mspdebug sourceforges mspgcc, mspgebug (there is an issue with version 0.17, so use another one)
For ‘ddd‘ every version should work.

I personally installed msp430-gdb from the sources and I advice you to change the installation prefix to an empty folder like ‘/usr/local/msp430‘ either than only /usr/local, so it won’t mix with others installed programs and it will be easier to remove all the files if needed. At the end don’t forget to add /usr/local/msp430/bin (or your installation folder) to the PATH variable.

Using mspdebug as a regular user

The user should have the right to read and write on the ‘/dev/ttyUSB#‘ interfaces

• The easiest way is to add the user in the dialout group.
  Edit the /etc/group file as root and add your username to the dialout group

…
dialout:x:18:user_name
…

Once this has been done you must logout and login again for the changes to take effect.
And to check that everything went fine,

$ id
uid=53542(harter) gid=50101(sed) groups=50101(sed),14(uucp),18(dialout)

• Another solution is to give RW rights on the interfaces to all users. To make the procedure easier add the command to the ‘.bashrc‘ file and execute the command after plugging the programmer

alias chmod_tty='sudo chmod 666 /dev/ttyUSB0; sudo chmod 666 /dev/ttyUSB1'

Useful commands sum up

mspdebug -j -d /dev/ttyUSB0 uif                    # run in interactive mode
mspdebug -j -d /dev/ttyUSB0 uif "prog example.elf" # program and run a program on the board
mspdebug -j -d /dev/ttyUSB0 uif reset              # reset the board
mspdebug -j -d /dev/ttyUSB0 uif gdb                # listen to incoming gdb connections on port 2000

alias msp='mspdebug -j -d /dev/ttyUSB0 uif'        # be lazy, put this in your .bashrc file

# after running 'msp gdb'
msp430-gdb --tui --ex="target remote localhost:2000" example.elf  # Connect gdb to mspgebug
# inside msp430-gdb
(gdb) load example.elf                             # program the device with example.elf
(gdb) br main                                      # Set a breakpoint at 'main'
(gdb) continue                                     # like 'run' but gdb has the control of the execution
(gdb) monitor             # do mspdebug execute the command, gdb cannot interrupt
(gdb) monitor erase
(gdb) monitor reset

alias mgdb='msp430-gdb --tui --ex="target remote localhost:2000"' # be lazy, put this in your .bashrc file

Gdb commands quick reference.pdf

# ddd graphical interface
ddd --debugger msp430-gdb -ex="target remote localhost:2000" example.elf

alias sddd='ddd --debugger msp430-gdb -ex="target remote localhost:2000"'

Usage

If you want to do some debug, you will want to use the interactive mode and the ‘prog‘, ‘setbreak‘, ‘run‘, ‘step‘ commands. However you won’t have any C-source integration with ‘mspdebug‘

But, one of the important feature of ‘mspdebug‘ is that it implements the gbd stubs and can be used as a remote target for ‘msp430-gdb‘. Then all the debugging can be done from within gdb using the gdb debug commands and the ‘monitor‘ command which allows running ‘mspdebug‘ commands in gdb.

And if you want, you can use ddd as a graphical interface for ‘msp430-gdb‘.

Known problems

• With mspdebug 0.17: On GDB, when you do a “continue“, the connection closes and gdb must be interrupted with a ‘Ctrl + c ‘ to get the control back, even if a breakpoint is reached.

Serial Terminal

It must be connected to /dev/ttyUSB1 (if the plugging order was respected) with, by default a 115200 baud rate.

Gtkterm

gtkterm window and configuration

• In “Wait for this special character before passing to the next line:” text field, paste a line-break.
• Check Configuration->”Local echo”
• Check Configuration->”CR LF”
• Overwrite the ‘default’ configuration with Configuration->”Save Configuration” with the name ‘default’

Unfortunately, Configuration->”CR LF” must be re-enabled after each launch.

Moserial

Unlike gtkterm, “Local echo” must be disabled

moserial window and configuration

Parallel JTAG debugger case

Contrary to the usb jtag debugger, ‘mspdebug‘ functionality are separated in two software:

• msp430-jtag to program the board
• msp430-gdbproxy implements the gdb stubs and can be used as a remote target for ‘msp430-gdb‘

The official documentation for the tools can be found at http://mspgcc.sourceforge.net/tools.html

Programming -> msp430-jtag

Tutorial to install the software: msp430-jtag-installation.txt

Usage:

# Download
$ msp430-jtag -e example.elf

# Restarting the node
$ msp430-jtag -r

Debugging remote target -> msp430-gdbproxy

Take a look at the mspgcc introduction: http://mspgcc.sourceforge.net/tools.html
It can be dowloaded at http://sourceforge.net/projects/mspgcc/files/Outdated/msp430-gdbproxy/2006-11-14/

# Start the remote target for msp430-gdb
msp430-gdbproxy --port=2000 msp430

Doing everything with eclipse

Once you will have understood the overall working and get bored of launching each tools manually you can get a look at this tutorial that presents how to do all the development and debugging with eclipse on windows. It must be adapted to your OS and configuration but it is a good startup to know what to configure.
http://springuin.nl/en/articles/launchpadwindows

Usage

In this section, I assume that you have defined the alias presented before

TP_01 example

Blinkings leds and command through the serial link (with the bug fix applied to the example of v1.7 drivers).
tp_01.tar.gz

Preparation

# Execute the commands from within the source folder

# in a first terminal
msp gdb

# in a second terminal
mgdb example.elf

# Launch gtkterm and enable CR-LF auto

Timeline

# Execution of all the initial commands

(gdb) monitor erase
(gdb) load
(gdb) monitor reset
(gdb) br main
# Breakpoint set at 0x40d8
(gdb) continue
# Running
# Target halted
# gdb is stoped at the beginning of main function
(gdb) br 103
# Breakpoint set at 0x4204
(gdb) continue
# Gtkterm prints the help lines
Type "l" in gtkterm                                   # prints luminosity output
Type "l" in gtkterm                                   # prints luminosity output
Type "t" in gtkterm
# Breakpoint 2, main () at main.c:103
# mspdebug Target halted
# gdb is on the line 103

msp430-gdb window

The “(gdb)” lines are lines where commands are executed

Reading symbols from /home/sed/harter/work/senstools_svn/trunk/software/drivers/wsn430/examples/tp_01/tp.elf...done.
Remote debugging using localhost:2000
Cannot access memory at address 0xffff
(gdb) monitor erase all
Erasing...
(gdb) load
Loading section .text, size 0x12c4 lma 0x4000
Loading section .data, size 0x2 lma 0x52c4
Loading section .vectors, size 0x20 lma 0xffe0
Start address 0x4000, load size	4838
Transfer rate: 2 KB/sec, 1612 bytes/write.
(gdb) monitor reset                                 # this line is not printed in gdb
(gdb) br main
Breakpoint 1 at	0x40d8:	file main.c, line 40.
(gdb) continue
Continuing.

Breakpoint 1, main () at main.c:40
(gdb) br 103                                           # "break;" line in the character case for the letter "t"
Breakpoint 2 at	0x4204:	file main.c, line 103.
(gdb) continue
Continuing.

Breakpoint 2, main () at main.c:103
(gdb)

GtkTerm output

Senslab Simple Demo program
Type command
	t:	temperature measure
	l:	luminosity measure
cmd > lLuminosity measure: 0.0
cmd > lLuminosity measure: 0.0
cmd > t

mspdebug output

MSPDebug version 0.15 - debugging tool for MSP430 MCUs
Copyright (C) 2009-2011 Daniel Beer
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Trying to open UIF on /dev/ttyUSB0...
Initializing FET...
FET protocol version is 20107000
Configured for JTAG (2)
Set Vcc: 3000 mV
Device: MSP430F1611
Code memory starts at 0x4000
Number of breakpoints: 8
Bound to port 2000. Now waiting for connection...
Client connected from 127.0.0.1:46925
Clearing all breakpoints...
Reading    2 bytes from 0x4000
Monitor command received: erase all
Erasing...
Writing 4804 bytes to 0x4000
Writing    2 bytes to 0x52c4
Writing   32 bytes to 0xffe0
Monitor command received: reset
Reading    2 bytes from 0x4000
Reading    2 bytes from 0x40d4
Reading    2 bytes from 0x40d4
Reading    2 bytes from 0x40d6
Reading    2 bytes from 0x40d8
Reading    2 bytes from 0x40d4
Reading    2 bytes from 0x40d4
Reading    2 bytes from 0x40d6
Reading    2 bytes from 0x40d8
Reading    2 bytes from 0x40d8
Breakpoint set at 0x40d8
Running
Target halted
Breakpoint cleared at 0x40d8
Reading    2 bytes from 0x40d8
Reading    2 bytes from 0x40d8
Reading    2 bytes from 0x40d4
Reading    2 bytes from 0x40d6
Reading    2 bytes from 0x40d8
Reading    2 bytes from 0x40d4
Reading    2 bytes from 0x40d4
Reading    2 bytes from 0x40d6
Reading    2 bytes from 0x40d8
Reading    2 bytes from 0x40d4
Reading    2 bytes from 0x40d4
Reading    2 bytes from 0x40d6
Reading    2 bytes from 0x40d8
Reading    2 bytes from 0x4204
Single stepping
Breakpoint set at 0x40d8
Breakpoint set at 0x4204
Running
Target halted
Breakpoint cleared at 0x40d8
Breakpoint cleared at 0x4204
Reading    2 bytes from 0x4204

TP_01 example with the bug

Blinkings leds and command through the serial link (without the bug fix).
tp_01_with_bug.tar.gz

If you haven’t done the example without bug, please do it, I will not repeat everything.

Bug detection

# Launch gtkterm and enable CR-LF auto

# Execute the commands from within the source folder
msp erase        # just to ensure that the outputs will be the same
msp reset

# clear gtkterm screen, because it's now that it is important
msp "prog tp_with_bug.elf"

The led should blink on the board and there should have been some outputs on gtkterm. But nothing happend.
If you redo the “prog” command, nothing changes, there is the good outputs and then some crap while programming but does not work. If you do a ‘msp reset‘ it starts working.

msp reset
# Now the outputs are good.

Debugging

Let’s find where does the problem come from.

msp erase
msp reset
msp
# now from within the text interface
(mspdebug) prog tp_with_bug.elf
Erasing...
Programming...
Writing 4096 bytes to 4000...
Writing  958 bytes to 5000...
Writing   32 bytes to ffe0...
(mspdebug) run
Running. Press Ctrl+C to interrupt...
# Let it run a few seconds and see that nothing goes on gtkterm and that the link does not blink
^C
^C
    ( PC: 04a84)  ( R4: 01f24)  ( R8: 01fb1)  (R12: 00000)
    ( SP: 038f8)  ( R5: 0000e)  ( R9: 00001)  (R13: 00006)
    ( SR: 00002)  ( R6: 01002)  (R10: 00000)  (R14: 038fa)
    ( R3: 00000)  ( R7: 00000)  (R11: 04064)  (R15: 00039)
i2c0_read_single+0x28:
    04a84: fc 27                     JZ      i2c0_read_single+0x22
    04a86: de 42 76 00 00 00         MOV.B   &0x0076, 0x0000(R14)
    04a8c: f2 b0 20 00 72 00         BIT.B   #0x0020, &0x0072
    04a92: fc 23                     JNZ     i2c0_read_single+0x30
(mspdebug) step
    ( PC: 04a7e)  ( R4: 01f24)  ( R8: 01fb1)  (R12: 00000)
    ( SP: 038f8)  ( R5: 0000e)  ( R9: 00001)  (R13: 00006)
    ( SR: 00002)  ( R6: 01002)  (R10: 00000)  (R14: 038fa)
    ( R3: 00000)  ( R7: 00000)  (R11: 04064)  (R15: 00039)
i2c0_read_single+0x22:
    04a7e: f2 b0 10 00 51 00         BIT.B   #0x0010, &0x0051
    04a84: fc 27                     JZ      i2c0_read_single+0x22
    04a86: de 42 76 00 00 00         MOV.B   &0x0076, 0x0000(R14)
    04a8c: f2 b0
(mspdebug) step
    ( PC: 04a84)  ( R4: 01f24)  ( R8: 01fb1)  (R12: 00000)
    ( SP: 038f8)  ( R5: 0000e)  ( R9: 00001)  (R13: 00006)
    ( SR: 00002)  ( R6: 01002)  (R10: 00000)  (R14: 038fa)
    ( R3: 00000)  ( R7: 00000)  (R11: 04064)  (R15: 00039)
i2c0_read_single+0x28:
    04a84: fc 27                     JZ      i2c0_read_single+0x22
    04a86: de 42 76 00 00 00         MOV.B   &0x0076, 0x0000(R14)
    04a8c: f2 b0 20 00 72 00         BIT.B   #0x0020, &0x0072
    04a92: fc 23                     JNZ     i2c0_read_single+0x30
(mspdebug)
# we are stuck in an infinit loop but who did called this i2c0_read_single function ?
(mspdebug) gdb
Bound to port 2000. Now waiting for connection...          # launch gdb in another terminal
Client connected from 127.0.0.1:50505
Clearing all breakpoints...
...

mgdb tp_with_bug.elf
Remote debugging using localhost:2000
0x00004a84 in i2c0_read_single (slaveAddr=57 '9', value=0x38fa "\306L\003")
    at /home/sed/harter/work/senstools_svn/trunk/software/drivers/wsn430/i2c0.c:153
(gdb) backtrace
#0  0x00004a84 in i2c0_read_single (slaveAddr=57 '9', value=0x38fa "\306L\003")
    at /home/sed/harter/work/senstools_svn/trunk/software/drivers/wsn430/i2c0.c:153
#1  0x00004d06 in tsl2550_read_adc1 ()
    at /home/sed/harter/work/senstools_svn/trunk/software/drivers/wsn430/tsl2550.c:118
#2  0x00004cc6 in tsl2550_set_standard ()
    at /home/sed/harter/work/senstools_svn/trunk/software/drivers/wsn430/tsl2550.c:103
#3  0x00004120 in main () at main.c:59
(gdb)

I do not understand what the #2 function does here, but if you drop it you see main.c:59 -> tsl2550_read_adc1 -> i2c0_read_single

main.c

 55         // Initialize the Luminosity sensor
 56         tsl2550_init();
 57         tsl2550_powerup();
 58         tsl2550_set_standard();
 59         tsl2550_read_adc1();    // problematic line
 60

By reading the tp_01 and some other tsl2550 example, I found that this line was useless and that in the rest of the code before each ‘tsl2550_read_*’ call, a ‘tsl255_init’ was done. Adding an ‘init’ call just before the ‘read’ call or removing this line fixed the problem.

What is the reason ?

What I read in the drivers documentation and even the hardware documentation didn’t gave me any piece of information.

Why wasn’t the problem detected before ? On the senslab platform, the nodes are reset automatically after programming, so it didn’t appeared.

Conclusion

Having a debugger does not give the bugs fixes, but it helps finding where they are located.
Also, keep in mind that there is code which is time dependent and which will work without debugger but not with.
Wish you good luck !

This event will take place at INRIA Rennes research center Thursday, December 1.

For this event, we organize one day with presentation (morning) and tutorial (afternoon) on the SensLab testbed.

The participation in the tutorial is free but requires registration for organizational reasons. If you want to participate in this tutorial, thank you to register using this link (for logistical reasons, the tutorial will be limited to first registered)

• official announcement

The tutorial will offer:
- An overview of the testbed
- The handling of the development environment
- Examples testing

The participation in the tutorial is free but requires registration for organizational reasons. If you want to participate in this tutorial, thank you to register using the link:
http://studs.u-strasbg.fr/studs.php?sondage=emkhpipel7nrxar4

For logistical reasons, the tutorial will be limited to first 40 registered.

The tutorial should begin at 14:00 to close around 17:00.

• [1] http://rge.u-strasbg.fr
• [2] http://lsiit.unistra.fr

FIT (Future Internet of Things) aims to develop an experimental facility, a federated and competitive infrastructure with international visibility and a broad panel of customers. It will provide this facility with a set of complementary components that enable experimentation on innovative services for academic and industrial users. The project will give French Internet stakeholders a means to experiment on mobile wireless communications at the network and application layers thereby accelerating the design of advanced networking technologies for the Future Internet.

FIT is one of 52 winning projects from the first wave of the French Ministry of Higher Education and Research’s “Équipements d’Excellence” (Equipex) research grant programme, will run over a nine-year period, the project will benefit from a 5.8 million euro grant from the French government.

The FIT project, through its ECO (“embedded communicating objects”) component, will go beyond the existing SensLAB testbed and provide a very large-scale infrastructure suitable for testing heterogeneous embedded communicating objects of all sorts. The ECO testbeds will encompass:  Internet, wireless networks, mobile networks, sensor and actuator networks (SANETs), home gateways and access networks, and low power and lossy networks (LLNs).

More information on their web site.