Mounting VM Home folder with sshfs

In addition to using scp command to transfer files between your computer and the senslab virtual machines you may be interested to get a direct access to your VM home folder from your computer like if it was stored locally.

This tutorial will explain how to mount your remote home folder using sshfs on linux. It should work for windows too using an sshfs equivalent program.

Configuration

On the virtual machine

There is nothing to configure, ssh server is already installed.

On the client computer

1. Be sure that you can access your VM using ssh. If it fails sshfs will fail too so make it work at first.
2. Install sshfs on your computer.
3. Create an empty folder that will be the destination for the VM home folder.
4. Mount the home directory by executing the following command as regular user

sshfs <USER>@<SITE>.senslab.info: <LOCAL_FOLDER>

You can specify another directory than the home folder by setting its path after the ‘:’ .

To unmount the remote folder, execute the command as normal user too

fusermount -u <LOCAL_FOLDER>

 Troubleshooting

Sometime after an inactivity time the sshfs process hangs up, probably because of the ssh connection terminating. You may want to try adding the option “-o reconnect” to sshfs command.

Either, when the folder is unaccessible and even freeze your terminal, the solution is to kill sshfs and execute the fusermount command.

pkill -KILL sshfs
fusermount -u <LOCAL_FOLDER>

Automated scripts

To simplify the manipulation, you can find two scripts to mount and unmount your home folder in the following archive.

Download

In addition to the release archives provided, you can get the last up to date code from the git repository, more information at: Senslab Git Repository page

• home_folder_mount_scripts-v2012-04-04.tar.gz, CHANGELOG:
• Initial version, with mount, umount (+force) README

Git repository

To give an easier access to the code updates and last versions, in addition to the releases archives that can be found on senslab.info website, you can find the up to date code for Senslab in the following git repository:

git clone git://scm.gforge.inria.fr/fit-eco/fit-eco.git

All the history of the former svn repository has been kept in the git repository for the included files.

Content

The repository contains:

• WSN430 Drivers
• WSN430 Libraries
• Sample applications
• the three supported Operating Systems:
• Contiki
• FreeRTOS
• TinyOS
• A folder for tools and scripts

Contributing

The repository is read only, but you can send patches on senslab-users mailing-list to fix bugs or suggest improvement. Just remember to tell on which commit they are based.

Title

Test

Conducted by

Ressources

Description

Description

Title

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

Title

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

Title

IPv6 Communication beetween nodes from different sites

Conducted by

Ressources

Description

The goal was to make a node from Grenoble ping a node from Strasbourg over ipv6

Setting up:
* RPL networks with a border router and tunslip6 and idle Contiki nodes on each platform
* VPN tunnel over ssh between the VMs using ssh+ppp (documentation in the external link)
* 3 different subnets, one for the Grenoble, one for Strasbourg and one for the VPN
* Set up routes from Grenoble Virtual Machine to Strasbourg nodes network and vice-versa

Significant results

It works

Illustrating chart picture

Title

IPv6 Communication beetween nodes from different sites

Conducted by

Ressources

Description

The goal was to make a node from Grenoble ping a node from Strasbourg over ipv6

Setting up:
* RPL networks with a border router and tunslip6 and idle Contiki nodes on each platform
* VPN tunnel over ssh between the VMs using ssh+ppp (documentation in the external link)
* 3 different subnets, one for the Grenoble, one for Strasbourg and one for the VPN
* Set up routes from Grenoble Virtual Machine to Strasbourg nodes network and vice-versa

Significant results

It works

Illustrating chart picture

Title

IPv6 Communication beetween nodes from different sites

Conducted by

Ressources

Description

The goal was to make a node from Grenoble ping a node from Strasbourg over ipv6

Setting up:
* RPL networks with a border router and tunslip6 and idle Contiki nodes on each platform
* VPN tunnel over ssh between the VMs using ssh+ppp (documentation in the external link)
* 3 different subnets, one for the Grenoble, one for Strasbourg and one for the VPN
* Set up routes from Grenoble Virtual Machine to Strasbourg nodes network and vice-versa

Significant results

It works

Illustrating chart picture

Title

IPv6 Communication beetween nodes from different sites

Conducted by

Ressources

Description

The goal was to make a node from Grenoble ping a node from Strasbourg over ipv6

Setting up:
* RPL networks with a border router and tunslip6 and idle Contiki nodes on each platform
* VPN tunnel over ssh between the VMs using ssh+ppp (documentation in the external link)
* 3 different subnets, one for the Grenoble, one for Strasbourg and one for the VPN
* Set up routes from Grenoble Virtual Machine to Strasbourg nodes network and vice-versa

Significant results

It works

Illustrating chart picture

Title

IPv6 Communication beetween nodes from different sites

Contributors

Laboratory

inria

Operating System

Contiki

Status

Achieved

Radio

CC1101

Sites

Several sites

Time of platforms usage

Hours

Description

The goal was to test if I could make a node from Grenoble ping a node from Strasbourg.

Setting up:
* RPL networks with a border router and tunslip6 and idle Contiki nodes on each platform
* VPN tunnel over ssh between the VMs using ssh+ppp (documentation in the external link)
* 3 different subnets, one for the Grenoble, one for Strasbourg and one for the VPN
* Set up routes from Grenoble Virtual Machine to Strasbourg nodes network and vice-versa
*

Illustrating chart picture

http://wikinet.u-strasbg.fr/~erkan/captures/banniere.png

External website or Publication URL

http://www.tldp.org/HOWTO/ppp-ssh/index.html

Description

super tests yeah

Operating System

Contiki

Status

finished

Description

w00t

Operating System

Contiki

Status

pending

Experiment Report Post

This page is made to simply report your experiments run using SensLAB.

You must be logged in to report an experiment

Several Senslab sites provide a webcam that allow users to monitor the nodes. This can be usefull to check the nodes leds or their environment (luminosity of the room : is the light turned on ?).
Here are the urls to display those cameras and the associated login/password

Grenoble : demo/demo=gre

Strabourg : demo/demo=gre

Lille :

Several Senslab sites provide a webcam that allow users to monitor the nodes. This can be usefull to check the nodes leds or their environment (luminosity of the room : is the light turned on ?).
Here are the urls to display those cameras and the associated login/password

Grenoble : demo/demo=gre

Strabourg : demo/demo=gre

Lille :

It is possible to setup a network link between any machine of the internet and your senslab virtual machine using an ssh tunnel.
For exemple, execute the following command on your internet host :
ssh -L 50001:vmnturro:50001 nturro@grenoble.senslab.info -N
(replace vmnturro with the name of your senslab virtual machine, and nturro@grenoble with your login and senslab site)
Then the local port 50001 of your internet host will be connected with the port 50001 or you VM.

This tunnel can be used, for exemple, to redirect the serial line of the senslab node to any host on the internet :
First, execute this command on your virtual machine :
socat TCP-LISTEN:50001 TCP:experiment:30001
It will redirect the serial output of your first sensor node (TCP:experiment:30001) to one end of your ssh tunnel.
Then, establish the ssh tunnel as explained above, and then, you might be able to read the serial output of your senslab node on your internet host by running :
nc localhost 50001

It is possible to setup a network link between any machine of the internet and your senslab virtual machine using an ssh tunnel.
For exemple, execute the following command on your internet host :
ssh -L 50001:vmnturro:50001 nturro@grenoble.senslab.info -N
(replace vmnturro with the name of your senslab virtual machine, and nturro@grenoble with your login and senslab site)
Then the local port 50001 of your internet host will be connected with the port 50001 or you VM.

This tunnel can be used, for exemple, to redirect the serial line of the senslab node to any host on the internet :
First, execute this command on your virtual machine :
socat TCP-LISTEN:50001 TCP:experiment:30001
It will redirect the serial output of your first sensor node (TCP:experiment:30001) to one end of your ssh tunnel.
Then, establish the ssh tunnel as explained above, and then, you might be able to read the serial output of your senslab node on your internet host by running :
nc localhost 50001

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 cc1100 has a PCB antenna and the cc2420 an antenna in a chip

• The first is a Senslabv13b node with cc1100 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 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 cc1100 has a PCB antenna and the cc2420 an antenna in a chip

• The first is a Senslabv13b node with cc1100 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 !

Introduction

This page explains basic things required to be able to build programs for the Senslab platform. It is written for linux users. Either on your machine or on your dedicated virtual machine.

msp430-gcc

mspgcc versions and the given headers have changed with time and not all versions are natively supported. Source : mspgcc wiki

mspgcc3

The original development by Dmitry Diky and Chris Liechti among others.

Version stopped at 3.2.3

mspgcc4

mspgcc4 forked to provide MSP430 support on newer versions of the GNU toolchain when mspgcc3 was stuck at gcc 3.2.3 for several years.

Versions ≤ 4.4.5

uniarch

Uniarch continued the work of mspgcc4, returning those contributions to the mspgcc project and generalizing the infrastructure to support all 300+ variants of the MSP430 microcontroller. The name “uniarch” is no longer used: the project is again simply “mspgcc“.

Versions ≥ 4.5.X

mspgcc versions and Senslab

When I will talk about a mspgcc version, it will includes the header files version given with the compiler.

Senslab WSN430 drivers and examples have been developed for mspgcc3 and are compatible with mspgcc4. On the virtual machine, msp430-gcc version 3.2.3 is installed.

The new uniarch version changed and moved some of the files so the drivers do not compile anymore.

mspgcc uniarch beta support

So either than giving two versions for the drivers, a hack has been added to allow support for all the versions. When using the uniarch version, the included headers should be the ones found in the wsn430-drivers-v1.8/gcc-uniarch/ folder.

The Makefile architecture has been modified to use a Makefile.common found in the wsn430-drivers folder (since v1.8). And the hack is automatically managed by the Makefile.common.

For the moment, only the os-free and the FreeRTOS Makefiles have been updated, if you need to use the new gcc versions other OS’s or compilation toolchain, the trick is to include the patch folder at first, a way is to do

# replace
CC = msp430-gcc
# by
CC = msp430-gcc -I$(WSN430_DRIVERS_PATH)/gcc_uniarch

It has been tested on all the wsn430-lib, the drivers and the FreeRTOS examples but there may still be some support missing. If you get a problem, please report on senslab-user mailing list.

Folder hierarchy

Here is what your folder hierarchy can look like, with the environment variable to set.

senslab/
│
├── wsn430-drivers-vX.X/                                  WSN430_DRIVERS_PATH
│   │
│   ├── examples/
│   ├── gcc_uniarch/
│   │
│   ├── Makefile.common
│   └── drivers_files.{c,h}
│
├── wsn430-lib/                                           WSN430_LIB_PATH
│   ├── mac/
│   │   └── csma/tdma/xmac/simplemac implementations
│   ├── phy/
│   │
│   ├── gradient/
│   ├── SimpliciTI/
│   ├── Single/
│   │
│   └── net/
│
└── OS/
    ├── Contiki/                                          CONTIKY
    ├── FreeRTOS/                                         FREERTOS_PATH
    │
    └── TinyOS/                                           See dedicated page

So for example for the drivers, add this line to your .bashrc and execute ‘source ~/.bashrc‘ to reload the ENV variables

test -d ${HOME}/senslab/wsn430-drivers-v1.8/ && export WSN430_DRIVERS_PATH=${HOME}/senslab/wsn430-drivers-v1.8/

Additional documentation and downloadable content can be found on the dedicated pages

• Drivers
• WSN430 Libraries
• FreeRTOS
• Contiky
• TinyOS

Compilation with Makefile.common

The following explanation is based on the files version contained in the wsn430-drivers-v1.8 archive.

The compilation is based on a Makefile that defines the minimum things includes the Makefile.common and get simple support for multiple targets with many common source files, header dependency, mspgcc “uniarch” support and all the .elf and .hex files generation.

Makefile

This is all what a Makefile must contain to work

• Check required environment variable existence. It’s better to see a well written error message than a gcc error saying than one of the source file is missing.
• NAMES variable with one name for each target
• SRC variable containing the source files common to all the targets
• If required, SRC_target_name variable containing the source files specific to <target_name>
• INCLUDES variable with the gcc include arguments
• Include the Makefile.common

Here is the Makefile.example given in the wsn430-drivers (v1.8) archive

ifndef WSN430_DRIVERS_PATH
$(error Please set environment variable WSN430_DRIVERS_PATH to the drivers folder)
endif

# define one name for each executable to be built
NAMES  = firt_target second_target

# the specific sources files must be stored in a variable called SRC_target_name to be found automatically
# These variables can be undefined or empty

# sources files specific to 'first_target'
SRC_first_target  = main_first_target.c

# sources files specific to 'second_target'
SRC_second_target  = main_second_target.c
SRC_second_target += specific_file_for_second_target.c

# common sources for all targets
SRC  = $(WSN430_DRIVERS_PATH)/cc2420.c
SRC += $(WSN430_DRIVERS_PATH)/uart0.c
SRC += $(WSN430_DRIVERS_PATH)/spi1.c
SRC += $(WSN430_DRIVERS_PATH)/clock.c

INCLUDES  = -I. -I$(WSN430_DRIVERS_PATH)

# the makefile common will generate NAMES.hex and NAMES.elf files, and define 'all' and 'clean' directives
-include $(WSN430_DRIVERS_PATH)/Makefile.common

Introduction

This page explains basic things required to be able to build programs for the Senslab platform. It is written for linux users. Either on your machine or on your dedicated virtual machine.

msp430-gcc

mspgcc versions and the given headers have changed with time and not all versions are natively supported. Source : mspgcc wiki

mspgcc3

The original development by Dmitry Diky and Chris Liechti among others.

Version stopped at 3.2.3

mspgcc4

mspgcc4 forked to provide MSP430 support on newer versions of the GNU toolchain when mspgcc3 was stuck at gcc 3.2.3 for several years.

Versions ≤ 4.4.5

uniarch

Uniarch continued the work of mspgcc4, returning those contributions to the mspgcc project and generalizing the infrastructure to support all 300+ variants of the MSP430 microcontroller. The name “uniarch” is no longer used: the project is again simply “mspgcc“.

Versions ≥ 4.5.X

mspgcc versions and Senslab

When I will talk about a mspgcc version, it will includes the header files version given with the compiler.

Senslab WSN430 drivers and examples have been developed for mspgcc3 and are compatible with mspgcc4. On the virtual machine, msp430-gcc version 3.2.3 is installed.

The new uniarch version changed and moved some of the files so the drivers do not compile anymore.

mspgcc uniarch beta support

So either than giving two versions for the drivers, a hack has been added to allow support for all the versions. When using the uniarch version, the included headers should be the ones found in the wsn430-drivers-v1.8/gcc-uniarch/ folder.

The Makefile architecture has been modified to use a Makefile.common found in the wsn430-drivers folder (since v1.8). And the hack is automatically managed by the Makefile.common.

For the moment, only the os-free and the FreeRTOS Makefiles have been updated, if you need to use the new gcc versions other OS’s or compilation toolchain, the trick is to include the patch folder at first, a way is to do

# replace
CC = msp430-gcc
# by
CC = msp430-gcc -I$(WSN430_DRIVERS_PATH)/gcc_uniarch

It has been tested on all the wsn430-lib, the drivers and the FreeRTOS examples but there may still be some support missing. If you get a problem, please report on senslab-user mailing list.

Folder hierarchy

Here is what your folder hierarchy can look like, with the environment variable to set.

senslab/
│
├── wsn430-drivers-vX.X/                                  WSN430_DRIVERS_PATH
│   │
│   ├── examples/
│   ├── gcc_uniarch/
│   │
│   ├── Makefile.common
│   └── drivers_files.{c,h}
│
├── wsn430-lib/                                           WSN430_LIB_PATH
│   ├── mac/
│   │   └── csma/tdma/xmac/simplemac implementations
│   ├── phy/
│   │
│   ├── gradient/
│   ├── SimpliciTI/
│   ├── Single/
│   │
│   └── net/
│
└── OS/
    ├── Contiki/                                          CONTIKY
    ├── FreeRTOS/                                         FREERTOS_PATH
    │
    └── TinyOS/                                           See dedicated page

So for example for the drivers, add this line to your .bashrc and execute ‘source ~/.bashrc‘ to reload the ENV variables

test -d ${HOME}/senslab/wsn430-drivers-v1.8/ && export WSN430_DRIVERS_PATH=${HOME}/senslab/wsn430-drivers-v1.8/

Additional documentation and download-able content can be found on the dedicated pages:

• Drivers
• WSN430 Libraries
• Operating Systems
• Contiky
• FreeRTOS
• TinyOS

In addition to the release archives provided, you can get the last up to date code from the git repository, more information at: Senslab Git Repository page

Compilation with Makefile.common

The following explanation is based on the files version contained in the wsn430-drivers-v1.8 archive.

The compilation is based on a Makefile that defines the minimum things includes the Makefile.common and get simple support for multiple targets with many common source files, header dependency, mspgcc “uniarch” support and all the .elf and .hex files generation.

Makefile

This is all what a Makefile must contain to work

• Check required environment variable existence. It’s better to see a well written error message than a gcc error saying than one of the source file is missing.
• NAMES variable with one name for each target
• SRC variable containing the source files common to all the targets
• If required, SRC_target_name variable containing the source files specific to <target_name>
• INCLUDES variable with the gcc include arguments
• Include the Makefile.common

Here is the Makefile.example given in the wsn430-drivers (v1.8) archive

ifndef WSN430_DRIVERS_PATH
$(error Please set environment variable WSN430_DRIVERS_PATH to the drivers folder)
endif

# define one name for each executable to be built
NAMES  = firt_target second_target

# the specific sources files must be stored in a variable called SRC_target_name to be found automatically
# These variables can be undefined or empty

# sources files specific to 'first_target'
SRC_first_target  = main_first_target.c

# sources files specific to 'second_target'
SRC_second_target  = main_second_target.c
SRC_second_target += specific_file_for_second_target.c

# common sources for all targets
SRC  = $(WSN430_DRIVERS_PATH)/cc2420.c
SRC += $(WSN430_DRIVERS_PATH)/uart0.c
SRC += $(WSN430_DRIVERS_PATH)/spi1.c
SRC += $(WSN430_DRIVERS_PATH)/clock.c

INCLUDES  = -I. -I$(WSN430_DRIVERS_PATH)

# the makefile common will generate NAMES.hex and NAMES.elf files, and define 'all' and 'clean' directives
-include $(WSN430_DRIVERS_PATH)/Makefile.common

We are pleased to announce the opening of the fourth SENSLAB site.

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

We are pleased to announce the opening of the fourth SENSLAB site.

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 libraries have been developed with the SensTOOLS project funded by INRIA.

Introduction

The pack of libraries gives a good starting point for writing applications. As a part of them or simply as an examples to develop completely new things.

It can be found in the Download section below. It requires the WSN430 drivers (Requires the Makefile.common file from driver version ≥ 1.8, it can just be copied from the last version if needed)

The WSN430_LIB_PATH environment variable must be set to point at the downloaded library folder.

 Mac Layers

OS-Free implementation

Senstools provides a small set of MAC layers implementations not using an OS, as described below. They are designed OS-free, executing mainly on interrupt routines for timing purpose, but may be integrated in C-based OSes.

 Implementation description

CSMA: the easy way

The Carrier-Sense Multiple Access (CSMA) MAC implementation is a general-purpose low-latency non-energy-optimized MAC layer.

It a simple listen-before-talk mechanism where the node checks if the radio channel is active before sending (i.e. data is being transmitted by another node). If it appears busy, they will wait for a random time before trying again.

The nodes are always in RX mode, hence they consume a lot of energy.

TDMA: the synchronized way

The Time Division Multiple Access (TDMA) MAC implementation defines the network as one coordinator node, and several end nodes. Time is divided in slots, managed by the coordinator. Slots may be allocated to the nodes by the coordinator, thus they will use this defined time duration to send packets to the coordinator.

This type of network is useful to handle a large number of nodes (>10) on a same channel while offering an interesting throughput from the nodes to the coordinator.

XMAC: the low-power way

The XMAC protocol is a preamble-sampling low-power duty-cycled MAC protocol. It is especially suited for low traffic networks.

When using this MAC implementation, the nodes in the network listen to the radio channel once in a while. If they detect some activity they wake up, otherwise the go back to sleep.

1. When a node wants to send a data packet to another node, it will repeatedly send a preamble frame and listen for a preamble acknowledgment, until an acknowledgment is received.
2. The destination node, during its periodic wake up, should receive one preamble frame, recognize its address in the destination field, and send an acknowledgment frame.
3. The sending node, upon reception of the preamble ACK, sends the data packet. The destination node after receiving the data packet, sends a data ACK, to tell the sender the transaction is successful.

In order to send broadcast messages, a node sends the preamble frames during a complete listening period, in order to wake all the neighbor nodes, then sends the data packet. No ACK is transmitted after the broadcast.

Sending a packet thus takes some time, but it may be worth it to save power.

 Protocols

All the implementation can be found in the WSN430 library archive given in the Dowload section below.

Simplicity

SimpliciTI is a TI proprietary low power Radio Frequency network protocol (SimpliciTI page of the TI website). It is intended to support development of wireless end user devices in environment in which the network support is simple and the developer desires a simple means to do messaging over air. Thus SimpliciTI supplies APIs in order to manage easily messaging between devices.

See the dedicated page for more details SimpiciTI.

SINGLE – Simple IN-door Geo-Localization systEm

SINGLE is a wireless sensors network application to localize wireless sensors in an indoor environment. It features energy saving, routing algorithm and data aggregation.

Gradient routing algorithm

Gradient is a simple routing algorithm for wireless sensors networks.

The goal is to simply route messages from specific nodes which can be mobiles to a sink.

1. Each anchor able to comunicate to the sink attach to it and then create the first level of a tree.
2. A level two is created by attaching to nodes at level one and so on for other levels.
3. When a mobile node want to communicate with the sink, it’s broadcast its message and all anchors able to receive the message are sending the message to a node in the upper level in the tree.
4. Hop by hop the message finally arrive to the sink.

Download

The WSN430_LIB_PATH environment variable should be set to point at the downloaded wsn430_lib folder.

The libraries have been developed with the SensTOOLS project funded by INRIA.

Introduction

The pack of libraries gives a good starting point for writing applications. As a part of them or simply as an examples to develop completely new things.

It can be found in the Download section below. It requires the WSN430 drivers (Requires the Makefile.common file from driver version ≥ 1.8, it can just be copied from the last version if needed)

The WSN430_LIB_PATH environment variable must be set to point at the downloaded library folder.

 Mac Layers

OS-Free implementation

Senstools provides a small set of MAC layers implementations not using an OS, as described below. They are designed OS-free, executing mainly on interrupt routines for timing purpose, but may be integrated in C-based OSes.

 Implementation description

CSMA: the easy way

The Carrier-Sense Multiple Access (CSMA) MAC implementation is a general-purpose low-latency non-energy-optimized MAC layer.

It a simple listen-before-talk mechanism where the node checks if the radio channel is active before sending (i.e. data is being transmitted by another node). If it appears busy, they will wait for a random time before trying again.

The nodes are always in RX mode, hence they consume a lot of energy.

TDMA: the synchronized way

The Time Division Multiple Access (TDMA) MAC implementation defines the network as one coordinator node, and several end nodes. Time is divided in slots, managed by the coordinator. Slots may be allocated to the nodes by the coordinator, thus they will use this defined time duration to send packets to the coordinator.

This type of network is useful to handle a large number of nodes (>10) on a same channel while offering an interesting throughput from the nodes to the coordinator.

XMAC: the low-power way

The XMAC protocol is a preamble-sampling low-power duty-cycled MAC protocol. It is especially suited for low traffic networks.

When using this MAC implementation, the nodes in the network listen to the radio channel once in a while. If they detect some activity they wake up, otherwise the go back to sleep.

1. When a node wants to send a data packet to another node, it will repeatedly send a preamble frame and listen for a preamble acknowledgment, until an acknowledgment is received.
2. The destination node, during its periodic wake up, should receive one preamble frame, recognize its address in the destination field, and send an acknowledgment frame.
3. The sending node, upon reception of the preamble ACK, sends the data packet. The destination node after receiving the data packet, sends a data ACK, to tell the sender the transaction is successful.

In order to send broadcast messages, a node sends the preamble frames during a complete listening period, in order to wake all the neighbor nodes, then sends the data packet. No ACK is transmitted after the broadcast.

Sending a packet thus takes some time, but it may be worth it to save power.

 Protocols

All the implementation can be found in the WSN430 library archive given in the Dowload section below.

Simplicity

SimpliciTI is a TI proprietary low power Radio Frequency network protocol (SimpliciTI page of the TI website). It is intended to support development of wireless end user devices in environment in which the network support is simple and the developer desires a simple means to do messaging over air. Thus SimpliciTI supplies APIs in order to manage easily messaging between devices.

See the dedicated page for more details SimpiciTI.

SINGLE – Simple IN-door Geo-Localization systEm

SINGLE is a wireless sensors network application to localize wireless sensors in an indoor environment. It features energy saving, routing algorithm and data aggregation.

Gradient routing algorithm

Gradient is a simple routing algorithm for wireless sensors networks.

The goal is to simply route messages from specific nodes which can be mobiles to a sink.

1. Each anchor able to comunicate to the sink attach to it and then create the first level of a tree.
2. A level two is created by attaching to nodes at level one and so on for other levels.
3. When a mobile node want to communicate with the sink, it’s broadcast its message and all anchors able to receive the message are sending the message to a node in the upper level in the tree.
4. Hop by hop the message finally arrive to the sink.

Download

In addition to the release archives provided, you can get the last up to date code from the git repository, more information at: Senslab Git Repository page

The WSN430_LIB_PATH environment variable should be set to point at the downloaded wsn430_lib folder.

The Senslab Team provides a new tool to help running experiments.

It allows user to view the topology of SENSLAB’s sites (Lille, Grenoble, Strasbourg sensor nodes position)

To launch the application :

1. Download Senlab 3D Viewer
2. tar -xzvf senslab_viewer-xxx.tar.gz
3. ./run-<distrib>-<arch>.sh

At the top of the archive lies a directory named ‘position’  containing
one CSV file for each Senslab site. The file is made of the following
fields :

• absolute id of the node,
• its position (x, y, z in meters),
• harware node id,

The Senslab Team provides a new tool to help running experiments.

It allows user to view the topology of SENSLAB’s sites (Lille, Grenoble, Strasbourg sensor nodes position)

To launch the application :

1. Download Senlab 3D Viewer
2. tar -xzvf senslab_viewer-xxx.tar.gz
3. ./run-<distrib>-<arch>.sh

At the top of the archive lies a directory named ‘position’  containing
one CSV file for each Senslab site. The file is made of the following
fields :

• absolute id of the node,
• its position (x, y, z in meters),
• harware node id,

The next  RGE event [1] will take place in Strasbourg LSIIT [2] Thursday, October 13. For this event, we organize a half-day tutorial on the SensLab testbed .

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