Original author: mortenthansen (November 24, 2010 00:41:45)

When receiving a packet from the serial in TOSSIM the current code assumes that the incoming serial packet is aligned with the message_t structure. As the message_header_t structure is a union of the tossim_header_t and serial_header_t this is not the case when sizeof(tossim_header_t)>sizeof(serial_header_t).

Thus when the tossim/sf/sim/SerialActiveMessageC receives a packet from the serial it needs to be copied into the message_t at the correct offset. The diff of the tossim/sf/sim/SerialActiveMessageC below fixes this issue:

@@ -276,8 +276,9 @@ implementation {

 sim_event_t* allocate_serial_deliver_event(int node, message_t* msg, sim_time_t t) {
     sim_event_t* evt = (sim_event_t*)malloc(sizeof(sim_event_t));

•   memcpy(newMsg, msg, sizeof(message_t));
  

•    uint8_t payloadLength = ((serial_header_t*)msg->header)->length;
  

•    memcpy(getHeader(newMsg), msg, sizeof(serial_header_t)+payloadLength);
  
   evt->mote = node;
   evt->time = t;
  

Original issue: http://code.google.com/p/tinyos-main/issues/detail?id=9

Original author: [email protected] (October 17, 2010 23:43:13)

This problem is present in the tinyos svn core as of 9/30/2010, rev 5194 (git://hinrg.cs.jhu.edu/git/tinyos-2.x.svn, 562c381)

Under heavy receive loads the serial stack can corrupt and/or lose incoming packets.

SerialP is part of the tinyOS serial stack. It collects bytes from underlying layers and signals the next higher layer when packets start, on byte availability, and packet end.

The signals for packet start and end are critical to the correct functioning of the next higher layer as these events are used for controlling buffer allocation and mutual exclusion of that packet data. Allocation, mutual exclusion protection, and data storage are performed by the higher layer which in this case is SerialDispatcherP.

SerialDispatcherP implements a two slot (double buffer) receive path. It allocates (locks) a slot (and its associated buffer) when a startPacket is received and it hands the buffer to the next higher layer for processing when it receives an endPacket(SUCCESS). It unlocks and recycles a buffer when it receives an endPacket(FAIL). This makes the buffer available for future incoming data.

For proper functioning, interlayer signaling should only allow sequences that have a successful startPacket followed by an endPacket. endPacket without a preceeding valid startPacket are illegal and cause the upper layer to misbehave.

Due to problems with SerialP's implementation, solitary endPackets can be generated. This can occur in the following cases:

1. Invalid serial protocol. The first byte following the HDLC start of packet delimiter is the low level serial protocol. Anything other than SERIAL_PROTO_PACKET_ACK will cause an endPACKET(FAIL) to be signalled.

2. If startPacket() (the upper layer signal) returns FALSE, endPACKET(FAIL) is signalled.

3. At the termination of a valid packet, endPacket(SUCCESS) immediately followed by endPacket(FAIL) is signalled.

(Note: #3 above has been fixed by a fix from Phil Levis, rev 5204, hinrg git: c143598)

This problem will only cause a failure iff there are two buffers at the SerialDispatcherP layer waiting to be delivered. This delivery is done via a task. This situation will be more likely to occur if there is heavy receive traffic and/or heavy task loading (delaying the processing of incoming packets).

When the faulty endPacket(FAIL) occurs, the result is a valid buffer is freed and SerialDispatcherP will now consider it available for any new incoming packets. The failure scenerio will only be seen if new data does arrive. One of the following will be seen:

1. no problem. No new data has come in before the packet has been processed by the delivery task and the intended receipient. Full processing has to be completed before new incoming data shows up.

2. New incoming data has started and the packet buffer is partially overwritten. Beginning of the buffer is the new packet while the trailer is the old packet.

3. New incoming data completes and the buffer now contains the state for the new packet. The previous packet is lost.

Note that in all of these cases, the dispatcher task has been launched and the buffer that is now marked free will be delivered when the dispatcher task runs. What will be delivered is indeterminate and depends on external arrival of incoming data.

What steps will reproduce the problem?

Demonstrating this problem is difficult because it is a series of race conditions.

Heavy receive traffic is needed. When the original error occurs it opens a window that closes when a packet has completed processing. During the window time, new receive data will cause the problem to manifest.

Heavy task loading will delay the delivery of a completed buffer which causes the window to stay open longer.

Actual failures have been observed in a system being debugged using JTAG and GDB using a hand built scenerio.

Original issue: http://code.google.com/p/tinyos-main/issues/detail?id=1

Original author: [email protected] (June 10, 2011 00:50:42)

Purpose of code changes on this branch:

• Provide DMA support on UART RX when using PPP on telos-based platforms
• place the default PlatformSerialHdlcUart support in tos/lib/serial so it is overridden by platform-specific components when present.

This support has been tested locally and improves ppp performance in the presence of other interrupts; the overriding concern is long interrupt handlers (like the cc2420's) cause the default UART driver to drop bytes. Since PPP does not do retransmission, this causes lots of dropped packets.

After the review, I'll merge this branch into:
/trunk

The proposed changes are in /branches/blip-rpl-devel@5628

Original issue: http://code.google.com/p/tinyos-main/issues/detail?id=45

Original author: [email protected] (February 18, 2011 08:49:52)

Found by review.
Start with an example from todays SVN (there are several in this source)

addr->s6_addr16[0] = htons(0xfe80);
addr->s6_addr16[4] = htons(panid);
addr->s6_addr16[5] = ntohs(0x00FF);
addr->s6_addr16[6] = ntohs(0xFE00);
addr->s6_addr16[7] = htons(saddr);

As you can see in this code both htons(0xfe80) and ntohs(0x00FF) are used on what would be native constants.

htons and ntohs will always have the same implementation (either both will swap or not). So there will be no runtime error only confusion when reading...

Original issue: http://code.google.com/p/tinyos-main/issues/detail?id=19

Original author: [email protected] (November 24, 2010 16:14:54)

I have recently noticed that the floating point division operation for calculating the slope of the linear regression line in TimeSyncP.nc file of FTSP protocol in TinyOS has some problems. If we take a look at the following nesC code of FTSP, we can see that localSum and offsetSum variables are int64_t. However, division of these two 64 bit numbers by casting to the float is problematic.

    for(i = 0; i < MAX_ENTRIES; ++i)
        if( table[i].state == ENTRY_FULL ) {
            int32_t a = table[i].localTime - newLocalAverage;
            int32_t b = table[i].timeOffset - newOffsetAverage;

            localSum += (int64_t)a * a;
            offsetSum += (int64_t)a * b;
        }

    if( localSum != 0 )
        newSkew = (float)offsetSum / (float)localSum;

    atomic
    {
        skew = newSkew;
        offsetAverage = newOffsetAverage;
        localAverage = newLocalAverage;
        numEntries = tableEntries;
    }

The main issue is, in Micaz platform floating point numbers are 32 bit numbers! (And may be in most other platforms). And if we cast an int64_t to float, we will get garbage data (especially when the casted variables are negative).

Consider the following localtime-globaltime pairs. These are the values I have recorded when running Ftsp between 2 nodes (1 root and 1 slave). The following 8 entries are the pairs which the slave node used to fill its regression table. If you run the linear regression code with the current code of FTSP in the tinyos 2.1.1 you wont get 0x4d457df value when the local time of the slave node is 0x4c61357.

[local=0x7b28be] [global=0x896e7b]
[local=0x1048612] [global=0x112cba8]
[local=0x18de365] [global=0x19c28d5]
[local=0x21740b9] [global=0x2258602]
[local=0x2a09e0c] [global=0x2aee32e]
[local=0x329fb5f] [global=0x338405b]
[local=0x3b358b2] [global=0x3c19d87]
[local=0x43cb605] [global=0x44afab3]
[local=0x4c61357] [global=0x4d457df]

My suggestion is adding a getSlope function as follows:

float getSlope(int64_t a,int64_t b){
bool negative = FALSE;
float s = 0.0;

if(a<0){                    // get the original positive number
  negative = TRUE;
  a--;                    
  a =~a;                   
}

if(b<0){
  if(negative==FALSE){
    negative = TRUE;
  }
  else{
    negative = FALSE;
  }

  b--;
  b =~b;
}

while(((a>>32)&0xFFFFFFFF) || ((b>>32)&0xFFFFFFFF)){
  a>>=4;
  b>>=4;
}

s = (float)a/(float)b;

if(negative == TRUE){
  s*=-1.0;
}

return s;

}

This function converts int64_t variables to int32_t and then calculates the slope. Then we can change TimeSyncP.nc as:

    for(i = 0; i < MAX_ENTRIES; ++i)
        if( table[i].state == ENTRY_FULL ) {
            int32_t a = table[i].localTime - newLocalAverage;
            int32_t b = table[i].timeOffset - newOffsetAverage;

            localSum += (int64_t)a * a;
            offsetSum += (int64_t)a * b;
        }

    if( localSum != 0 )
        newSkew = getSlope(offsetSum,localSum);

    atomic
    {
        skew = newSkew;
        offsetAverage = newOffsetAverage;
        localAverage = newLocalAverage;
        numEntries = tableEntries;
    }

Any other suggestions or ideas??

Sinan

Ege University
Computer Engineering Department
Izmir, TURKEY

Original issue: http://code.google.com/p/tinyos-main/issues/detail?id=10

Original author: mortenthansen (November 18, 2010 01:31:10)

When compiling sim-sf with python2.6 I get quite a few deprecated warnings due to some missing char* casts

The following should solve the problem and also fix a printf warning when compiling with sim-sf

diff --git a/tos/lib/tossim/sf/Throttle.cpp b/tos/lib/tossim/sf/Throttle.cpp
index 2a5350c..01520cb 100644
--- a/tos/lib/tossim/sf/Throttle.cpp
+++ b/tos/lib/tossim/sf/Throttle.cpp
@@ -111,7 +111,7 @@ int Throttle::simSleep(double seconds) {

void Throttle::printStatistics() {

• printf("Number of throttle events %d\n", throttleCount);
• printf("Number of throttle events %lu\n", throttleCount);

if (simEndTime > 0.0) {
printf("Total Sim Time: %.6f\n", simEndTime - simStartTime);
diff --git a/tos/lib/tossim/sf/tossim.c b/tos/lib/tossim/sf/tossim.c
index 5a07d71..73db9e6 100644
--- a/tos/lib/tossim/sf/tossim.c
+++ b/tos/lib/tossim/sf/tossim.c
@@ -123,8 +123,8 @@ variable_string_t Variable::getData() {
memcpy(data, ptr, len);
}
else {

• str.ptr = "<no such variable>";
• str.type = "<no such variable>";
• str.ptr = (char*)"<no such variable>";
• str.type = (char*)"<no such variable>";
  str.len = strlen("<no such variable>");
  str.isArray = 0;
  }
  @@ -176,7 +176,7 @@ void Mote::setID(unsigned long val) {
  }

Variable* Mote::getVariable(char* name) {

• char* typeStr = "";
• char* typeStr = (char_)"";
  int isArray;
  Variable_ var;

diff --git a/tos/lib/tossim/sf/tossim.i b/tos/lib/tossim/sf/tossim.i
index 7789c3b..509acab 100644
--- a/tos/lib/tossim/sf/tossim.i
+++ b/tos/lib/tossim/sf/tossim.i
@@ -312,8 +312,8 @@ PyObject* listFromArray(char* type, char* ptr, int len) {
}
}
else {

•    app->variableNames[i] = "<bad string>";
  

•    app->variableTypes[i] = "<bad string>";
  

•    app->variableNames[i] = (char*)"<bad string>";
  

•    app->variableTypes[i] = (char*)"<bad string>";
  

  }
  }

Original issue: http://code.google.com/p/tinyos-main/issues/detail?id=5

Original author: [email protected] (February 02, 2011 16:20:37)

What steps will reproduce the problem?

I did the following:

...
interface BusyWait<TMilli,uint16_t>;
...
...
components new BusyWaitCounterC(TMilli, uint16_t);
...
...
App.BusyWait->BusyWaitCounterC;
BusyWaitCounterC.Counter->CounterMilli16C;
...

What is the expected output? What do you see instead?

: cannot find `CounterMilli16C'
make: *** [sim-exe] Error 1

What version of the product are you using? On what operating system?

TinyOs 2.1.1, Ubuntu 10.04 64bit

Please provide any additional information below.

I know that CounterMilli16C comes from msp430 and I am running on tossim, but I dont know how to do..

Original issue: http://code.google.com/p/tinyos-main/issues/detail?id=13

Original author: [email protected] (May 06, 2011 19:19:19)

Hi everyone,
I have an application that performs several readings consecuitves with different ports of the ADC. Specifically, first read the internal voltage of the microcontroller IRIS, and then performed a reading of a temperature sensor that I have connected. To make both readings the results are erroneous and meaningless. But however, if instead of making two readings modify the application and made only one of two different readings, the value is correct. I think the problem is on the internal components of TinyOS-2.1.1 Adc. Has anyone had the same problem?

If anyone wants I can send you the source code of components that perform the reading of the ADC, which I relied on to implement Tep.

Regards, Antonio Rosa.

Original issue: http://code.google.com/p/tinyos-main/issues/detail?id=40

Original author: [email protected] (April 14, 2011 06:14:43)

What steps will reproduce the problem?

1. cd apps/UDPEcho ;
2. make iris blip

What is the expected output? What do you see instead?

In tos/lib/net/blip/Ieee154AddressC.nc
tos/lib/net/blip/Ieee154AddressP.nc
the Interface CC2420Config and component CC2420RadioC only works for mica family, not iris. iris platform use atm1281 and rf230 chips.

What version of the product are you using? On what operating system?

tinyos-main r5538 and linux fedora 13 system

Original issue: http://code.google.com/p/tinyos-main/issues/detail?id=30

Original author: [email protected] (August 01, 2011 12:13:18)

What steps will reproduce the problem?

1. cd apps/RadioCountToLeds;
2. make telosb safe

What is the expected output? What do you see instead?

Expected:

Successful compilation of the code

Actual:

/opt/tinyos-main-read-only/apps/RadioCountToLeds$ make telosb safe

mkdir -p build/telosb
javac RadioCountMsg.java
compiling RadioCountToLedsAppC to a telosb binary
ncc -o build/telosb/main.exe -DSAFE_TINYOS -I/opt/tinyos-main-read-only/tos/lib/safe -fnesc-deputy -fnesc-deputy-args='-I/opt/tinyos-main-read-only/tos/lib/safe/include --FLIDs=build/telosb/flids.txt --envmachine -DSAFE_TINYOS --nolib ' -Os -O -mdisable-hwmul -fnesc-separator=__ -Wall -Wshadow -Wnesc-all -target=telosb -fnesc-cfile=build/telosb/app.c -board= -DDEFINED_TOS_AM_GROUP=0x22 -DIDENT_APPNAME="RadioCountToLed" -DIDENT_USERNAME="user" -DIDENT_HOSTNAME="pc" -DIDENT_USERHASH=0xd9ffb6daL -DIDENT_TIMESTAMP=0x4e369674L -DIDENT_UIDHASH=0x5fe7ddecL RadioCountToLedsAppC.nc -lm
/opt/tinyos-main-read-only/tos/chips/cc2420/lpl/DummyLplC.nc:39:2: warning: #warning "*** LOW POWER COMMUNICATIONS DISABLED ***"
/opt/tinyos-main-read-only/tos/chips/cc2420/CC2420ActiveMessageP.nc:72: Warning: Type "struct message_t *" in global "CC2420ActiveMessageP__pending_message" needs a bound annotation.

/opt/tinyos-main-read-only/tos/chips/cc2420/interfaces/CC2420Packet.nc:75: Warning: Type "struct message_t *" in formal "p_msg" of CC2420PacketP__CC2420Packet__getNetwork needs a bound annotation.

/opt/tinyos-main-read-only/tos/chips/cc2420/interfaces/CC2420Packet.nc:75: Warning: Type "struct message_t *" in formal "p_msg" of CC2420TinyosNetworkP__CC2420Packet__getNetwork needs a bound annotation.

/opt/tinyos-main-read-only/tos/chips/cc2420/interfaces/CC2420Packet.nc:77: Warning: Type "struct message_t *" in formal "p_msg" of CC2420PacketP__CC2420Packet__setNetwork needs a bound annotation.

/opt/tinyos-main-read-only/tos/chips/cc2420/interfaces/CC2420Packet.nc:77: Warning: Type "struct message_t *" in formal "p_msg" of CC2420TinyosNetworkP__CC2420Packet__setNetwork needs a bound annotation.

/opt/tinyos-main-read-only/tos/chips/cc2420/packet/CC2420PacketP.nc:90: Warning: Type "struct message_t *" in formal "msg" of CC2420PacketP__getNetwork needs a bound annotation.

/opt/tinyos-main-read-only/tos/chips/cc2420/unique/UniqueReceiveP.nc:83: Warning: Type "struct message_t *" in formal "msg" of UniqueReceiveP__getSourceKey needs a bound annotation.

/opt/tinyos-main-read-only/tos/chips/cc2420/receive/CC2420ReceiveP.nc:838: Error: Assertion will always fail in upper bound coercion:
& header->dest == 0 || (struct ieee_eui64 * SAFE )(& header->dest) + 1 <= & header->dest + 1

make: *** [exe0] Error 1

What version of the product are you using? On what operating system?

tinyos-main r5660 and ubuntu 11.10

Original issue: http://code.google.com/p/tinyos-main/issues/detail?id=49

Original author: [email protected] (February 13, 2011 09:27:39)

What steps will reproduce the problem?

1. cd tinyos-2.x/tools
2. ./Bootstrap
3. ./configure

What is the expected output? What do you see instead?

In Step 2, the following warning is found.
platforms/makefile.am:3 required directory platforms/sam3u does not exist

In Step 3, after ignoring Step 2 warning, the following error is found.
config.status: error: cannot find input file: `Makefile.in'

What version of the product are you using? On what operating system?
tinyos-2.x from main trunk and try compiling on Ubuntu/Linux and Mac OSX.

Original issue: http://code.google.com/p/tinyos-main/issues/detail?id=17

Original author: [email protected] (November 19, 2010 16:56:25)

A user reports that setting LPL parameters with Makefile works fine but setting those parameters (sleep interval) using the interface results in high link ETX. Possible bug in the LPL stack.

Original issue: http://code.google.com/p/tinyos-main/issues/detail?id=8

Original author: mortenthansen (November 18, 2010 01:47:22)

TOSSIM MainC includes TossimActiveMessageC which makes it hard for chip dependent radio drivers to override the default chip independent TOSSIM radio stack.

It is enough for MainC to include ActiveMessageC. See the below diff which applies the changes to both the sim and sim-sf targets.

diff --git a/tos/lib/tossim/MainC.nc b/tos/lib/tossim/MainC.nc
index 4323d51..b0c0c7a 100644
--- a/tos/lib/tossim/MainC.nc
+++ b/tos/lib/tossim/MainC.nc
@@ -69,7 +69,7 @@ implementation {
// the application does not wire this up to, e.g., ActiveMessageC,
// the default handlers make sure nothing happens when a script
// tries to deliver a packet to a node that has no radio stack.

• components TossimActiveMessageC;
• components ActiveMessageC;

}

diff --git a/tos/lib/tossim/sf/sim/MainC.nc b/tos/lib/tossim/sf/sim/MainC.nc
index 819f25a..934b353 100644
--- a/tos/lib/tossim/sf/sim/MainC.nc
+++ b/tos/lib/tossim/sf/sim/MainC.nc
@@ -70,7 +70,7 @@ implementation {
// the application does not wire this up to, e.g., ActiveMessageC,
// the default handlers make sure nothing happens when a script
// tries to deliver a packet to a node that has no radio stack.

• components TossimActiveMessageC;
• components ActiveMessageC;
  components SerialActiveMessageC;

}

Original issue: http://code.google.com/p/tinyos-main/issues/detail?id=6

Original author: mortenthansen (January 06, 2011 06:31:54)

See tos/lib/net/drip/DisseminationEngineImplP line 224 where sendObject is called without checking for m_running and m_bufBusy flags as done for all other calls to sendObject.

Line 224:
sendObject( key );

Should be changed to:

if ( !m_running || m_bufBusy ) { return msg; }
sendObject( key );

Alternatively, the trickle timer could be reset instead of sending object immediately.

This is a copy of an old post on tinyos-devel which never got any response:
https://www.millennium.berkeley.edu/pipermail/tinyos-devel/2010-June/004468.html

Original issue: http://code.google.com/p/tinyos-main/issues/detail?id=12

Original author: [email protected] (October 23, 2010 10:02:58)

What steps will reproduce the problem?

While using the component at45db on an micaz mote, if you use the command copyPage with a destination page greater than or equal to AT45_PAGE_SIZE.

What is the expected output? What do you see instead?

The result of the command in all cases is the same: FAIL. If the destination page is less than AT45_PAGE_SIZE, the operation do its work and the most times return SUCCESS.

What version of the product are you using? On what operating system?

I am using the version "r5108" with header: "// $Id: At45dbP.nc,v 1.11 2010-06-29 22:07:43 scipio Exp $" on a XubunTOS virtual machine 2.1.

Please provide any additional information below.

I think the problem comes in lines from 394 to 399 at "At45dbP.nc" file, because if you replace that lines for the following code, the problem seems to be fixed:

ifdef CHECKARGS

if (page >= AT45_MAX_PAGES || (offset >= AT45_PAGE_SIZE && req != R_COPY) ||
n > AT45_PAGE_SIZE || (offset + n > AT45_PAGE_SIZE && req != R_COPY) ||
(offset >= AT45_MAX_PAGES && req == R_COPY))
post taskFail();
else

endif

with these lines I add an exception if the command is copyPage in order to not always return FAIL if the destination page is greater than or equal to AT45_PAGE_SIZE, instead of, it return FAIL if the destination page is greather than or equal to AT45_MAX_PAGES.

Thanks for reading.
Enrique Castellanos.

Original issue: http://code.google.com/p/tinyos-main/issues/detail?id=3

Original author: [email protected] (April 25, 2011 12:12:50)

What steps will reproduce the problem?

1. cd apps/AnyAppDir/
2. vim Makefile ; add CFLAGS += PRINTFUART_ENBALED
3. make $(platform)

What is the expected output? What do you see instead?

the tos/lib/net/blip/PrintfUART.h do not define a printUART function for IRIS platform

What version of the product are you using? On what operating system?

r5538

Please provide any additional information below.

add IRIS platform-dependent code to the PrintfUART.h file to fit the bug.

Original issue: http://code.google.com/p/tinyos-main/issues/detail?id=36

Original author: [email protected] (February 18, 2011 08:30:20)

What steps will reproduce the problem?

1. Compile/Download BaseStation for one mote
2. Compile/Download Oscilloscope for a remote mote
3. Send an update, sample interval, from host through BaseStation to remote mote

_What is the expected output?
I expect to see BaseStation toggle the send LED once.
And the message sent to remote motes.
Remote mote to change its sample rate

_What do you see instead?
Message is received in the remote mote - sample rate changes.
But BaseStation fails to recognize that.
It will resend the message over and over at a high rate
(radio & error indication blinking fast)
No more updates / parameter changes will get through.

What version of the product are you using? On what operating system?
TinyOS r5427 and later on Fedora 14

Please provide any additional information below.

Patch attached

Description of the bug
the error return from SubSend was lost, later code would assume failure unless acknowledged... Probably works when retry is enabled.
With this change clients will actually see if message was sent, failed in some way or canceled

PS
The BaseStation code is not well behaved. Resending is retried without delay.
And it will never give up in cases like this...

Original issue: http://code.google.com/p/tinyos-main/issues/detail?id=18

Original author: [email protected] (December 08, 2010 21:59:33)

What steps will reproduce the problem?

1. I downloaded and AccelGyro files examples from http://tinyos.cvs.sourceforge.net/viewvc/tinyos/tinyos-2.x-contrib/shimmer/apps/AccelGyro/
2. I did: make shimmer
3. I had compilation errors

What is the expected output? What do you see instead?

What version of the product are you using? On what operating system?
I compiled the example in VMWare with Ubuntu to work with the shimmer SDK.

Please provide any additional information below.

Original issue: http://code.google.com/p/tinyos-main/issues/detail?id=11

Original author: [email protected] (April 17, 2011 09:17:40)

These code from googlecode tinyos-main, r5538
In tos/lib/net/blip/UdpP.nc line 27 - 52 .

the alloc_lport function is used to allocate a port number for a udp client by the sendtov() command of the UDP Interface.

but the statment "last_localport = (last_localport < LOCAL_PORT_START) ? last_localport + 1 : LOCAL_PORT_START;" will always return the value LOCAL_PORT_START since the condition (last_localport < LOCAL_PORT_START) will always be false;

it seem that this statement should be modified to last_localport = (last_localport < LOCAL_PORT_STOP) ? last_localport + 1 : LOCAL_PORT_START;

Code for allocate port:

uint16_t local_ports[N_CLIENTS];

enum {
LOCAL_PORT_START = 51024U, // 0xc750
LOCAL_PORT_STOP = 54999U, // 0xd6d7
};
uint16_t last_localport = LOCAL_PORT_START;

uint16_t alloc_lport(uint8_t clnt) {
int i, done = 0;
uint16_t compare = htons(last_localport);
last_localport = (last_localport < LOCAL_PORT_START) ? last_localport + 1 : LOCAL_PORT_START;
while (!done) {
done = 1;
for (i = 0; i < N_CLIENTS; i++) {
if (local_ports[i] == compare) {
last_localport = (last_localport < LOCAL_PORT_START) ? last_localport + 1 : LOCAL_PORT_START;
compare = htons(last_localport);
done = 0;
break;
}
}
}
return last_localport;
}

Original issue: http://code.google.com/p/tinyos-main/issues/detail?id=31

Original author: [email protected] (October 18, 2010 00:21:59)

SerialDispatcherP implements a double buffer receive queue for incoming serial packets. This double buffer queue is intended to operate in a FIFO manner.

SerialDispatcherP is implemented as two major parts. The first part operates at the async (interrupt) level and is responsible buffer allocation, byte reception, buffer completion. The second part is responsible for packet delivery and operates at the task level.

Two buffer slots are provided and this implements the double buffering. One buffer can be in delivery while another buffer is receiving an incoming packet. Under heavy loads both buffers will be in delivery and new incoming data should be discarded.

Buffers handed off to the task layer for delivery should be handled in a strictly FIFO order.

The current implemenation of SerialDispatcherP (rev 5204) only provides a single set of state information and can only convey information about one buffer slot to the delivery task.

What steps will reproduce the problem?

1. Single step the code and set up a scenerio where the 2nd buffer is signalled complete prior to the receiveTask running (key variable is receiveTaskPending).

This problem exists because there isn't sufficient state to properly run the 2 slot FIFO queue in strict FIFO order while maintaining proper mutual exclusion.

This problem is a race condition. If the receiveTask executes (and clears receiveTaskPending) prior to a new packet being signalled as available then no problem occurs.

What is the expected output? What do you see instead?

1st packet arrives and completion is signalled to SerialDispatcherP. Buffer is handed off to receiveTask and receiveTaskPending set TRUE. This opens the window. Assume that prior to delivery being complete by receiveTask (clearing of receiveTaskPending), another packet is received and signalled.

Following problems occur:

1. Since there is only one set of state vars for handing information to receiveTask, meta info about the new packet is lost (type, which buffer, etc).

2. The packet in the 2nd buffer is never processed (hence lost). The receiveTask has no way of knowing that another buffer is available.

3. The buffer becomes unavailable for any future packets. It is never freed again and the system drops to one available buffer.

What version of the product are you using? On what operating system?

TinyOS-main SVN rev 5204 (hinrg git: c143598), 10/15/2010

Please provide any additional information below.

Original issue: http://code.google.com/p/tinyos-main/issues/detail?id=2

Original author: [email protected] (February 22, 2011 14:51:01)

What steps will reproduce the problem?

1. Program the sam3s-ek board with TestSerial
2. Launch the java application and see how RX and TX works
3. Hit reset. Only RX on Sam3s works (LEDs show lower 3 bits of received packets). The java application doesn't receive any packets anymore.
4. Power-cycle the board (unplug power). Notice how RX and TX works again.

I am not entirely sure why this behavior happens. Could it be some issue with the clocks not getting reset properly?

Original issue: http://code.google.com/p/tinyos-main/issues/detail?id=20

Original author: [email protected] (February 25, 2011 23:08:12)

Please see my patch at:
errordeveloper/tinyos-wmi@1845e4d

Original issue: http://code.google.com/p/tinyos-main/issues/detail?id=24

Original author: mortenthansen (November 18, 2010 04:54:17)

In tos/lib/tossim/platform_message.h the message_t header is defined to be the union of the tossim_header_t and serial_header_t.

In cases where sizeof(tossim_header_t)>sizeof(serial_header_t) a serial packet will not start from the beginning of the message_t data structure which is assumed in tos/lib/tossim/sf/sim/SerialActiveMessageC line 127.

Instead of passing the message_t pointer to be dispatched the header pointer should be passed. See fix in diff below:

diff --git a/tos/lib/tossim/sf/sim/SerialActiveMessageC.nc b/tos/lib/tossim/sf/sim/SerialActiveMessageC.nc
index df7cb68..a50494a 100644
--- a/tos/lib/tossim/sf/sim/SerialActiveMessageC.nc
+++ b/tos/lib/tossim/sf/sim/SerialActiveMessageC.nc
@@ -127,7 +127,7 @@ implementation {

     dbg("Serial", "Sending serial message (%p) of type %hhu and length %hhu @ %s.\n",
         msg, call AMPacket.type(msg), len, sim_time_string());

•    sim_sf_dispatch_packet((void*)msg, len);
  

•    sim_sf_dispatch_packet((void*)getHeader(msg), len);
  
   post modelSendDone ();
  

Original issue: http://code.google.com/p/tinyos-main/issues/detail?id=7

Original author: [email protected] (February 13, 2011 05:56:17)

It should return U1CTL instead of U0CTL.

Original issue: http://code.google.com/p/tinyos-main/issues/detail?id=16

Original author: [email protected] (April 17, 2011 11:10:19)

Ticket 29 (http://code.google.com/p/tinyos-main/issues/detail?id=29) provided a solution to support ppp on the atm128 IRIS platform. It includes the attached additions which extend the Mica platform. They seem plausible, but I can't validate them, so have extracted them for somebody else to vet and apply.

Original issue: http://code.google.com/p/tinyos-main/issues/detail?id=32

Original author: [email protected] (November 12, 2010 19:51:16)

There might be performance issues with ctp when we run it in a saturated network. With enough nodes, it effectively becomes a high data rate network and with busy wifi traffic in the network, performs poorly.

Original issue: http://code.google.com/p/tinyos-main/issues/detail?id=4

Original author: [email protected] (July 28, 2011 01:32:17)

When using the PppRouter application's RplBorderRouterP module and receiving a packet with an IPV6_HOP header but no RPL_HBH_RANK_TYPE header, IPPacketC's delTLV() ends up trashing memory. This is due to the blind assumption that findTLV() always succeeds. When it doesn't, -1 is used as an offset for iov_update() which results in Bad Things (in my case the board just hung, making this rather "fun" to track down).

Cheers,
/Johny

Original issue: http://code.google.com/p/tinyos-main/issues/detail?id=48

Original author: [email protected] (April 27, 2011 22:23:20)

Found an area of the MSP430 ADC12 code that can cause certain (all?) microcontrollers to lock-up after a software reset. The edge case occurs when the ADC12 is in use before the software reset, and after the software reset the ADC12 interrupt fires. After the software reset and upon boot, the Msp430Adc12ImplP state machine is in an undefined state (0), which is not covered by a switch statement later in the code that handles a new ADC12 interrupt. The ADC12 interrupt fires when interrupts are enabled, and infinitely loops because stopConversion() can never be called.

The solution is simple: add a default case to the switch statement in Msp430Adc12ImplP that stops conversions if the ADC12 interrupt fires while the driver is in an undefined state.

Original issue: http://code.google.com/p/tinyos-main/issues/detail?id=37

Original author: [email protected] (February 04, 2011 18:09:32)

What steps will reproduce the problem?

Try to use I2C after using the SPI0 module on the TI MSP430.

In TinyOS:
call HplUsart.enableSpi(); // Usart0
call HplUsart.disableSpi();
call HplI2C.setModeI2C();

What is the expected output? What do you see instead?
I2C commands should work. Instead, with a write() the address is sent correctly, but the actual data isn't put on the wires. The I2C write() never finishes and doesn't signal writeDone().

What version of the product are you using? On what operating system?
Latest SVN on Ubuntu.

Please provide any additional information below.
The fix I found was to clear the I2CTCTL by setting it to 0x01 before configuring it properly. I don't think it has to be 0x01, necessarily, but I don't think just any value will work. I could not find this in the MSP430 documentation or the errata sheet.

$ svn diff HplMsp430I2C0P.nc

Index: HplMsp430I2C0P.nc

--- HplMsp430I2C0P.nc (revision 5326)
+++ HplMsp430I2C0P.nc (working copy)
@@ -81,6 +81,8 @@
U0CTL &= ~I2CEN;

   U0CTL = (config->i2cRegisters.uctl | (I2C | SYNC)) & ~I2CEN;

•  I2CTCTL = 0x01;  // resetting I2CTCTL first,
  

•                   // before configuring it,
  

•                   // for some reason causes the I2C module to +                       // work after SPI has been used
  

  I2CTCTL = config->i2cRegisters.i2ctctl;
  I2CPSC = config->i2cRegisters.i2cpsc;

Original issue: http://code.google.com/p/tinyos-main/issues/detail?id=14

Original author: [email protected] (May 10, 2011 15:44:20)

It seems that the Dummy Extended Address, named LocalIeeeEui64C, has
been included for micaz, but not for intelmote2.
As the /opt/tinyos-2.x/tos/chips/cc2420/control/CC2420ControlC.nc
file wires it, and since the CC2420ControlP module uses the interface LocalIeeeEui64, then while compiling for imote2 it complains.

What steps will reproduce the problem?

1. ./apps/tutorials/BlinkToRadio/make intelmote2 install.1 openocd

What is the expected output? What do you see instead?

It should compile, but instead it shows:

In file included from /opt/tinyos-2.x//tos/chips/cc2420/csma/CC2420CsmaC.nc:58,
from /opt/tinyos-2.x//tos/chips/cc2420/CC2420RadioC.nc:63,
from
/opt/tinyos-2.x//tos/chips/cc2420/CC2420ActiveMessageC.nc:75,
from
/opt/tinyos-2.x//tos/platforms/intelmote2/ActiveMessageC.nc:74,
from BlinkToRadioAppC.nc:60:
In component `CC2420ControlC':
/opt/tinyos-2.x//tos/chips/cc2420/control/CC2420ControlC.nc:99: component LocalIeeeEui64C not found
/opt/tinyos-2.x//tos/chips/cc2420/control/CC2420ControlC.nc:100: no match1

What version of the product are you using? On what operating system?

TinyOS-2.x sources from the repository on May 2011.

Please provide any additional information below.

A simple work around is to comment lines 99 and 100 in the
configuration
/opt/tinyos-2.x/tos/chips/cc2420/control/CC2420ControlC.nc,
and lines 50, 135 and 291 in the module
/opt/tinyos-2.x/tos/chips/cc2420/control/CC2420ControlP.nc
plus adding lines 292 and 293
ieee_eui64_t dummy;
return dummy;
to remove the warning of the module.

But extending LocalIeeeEui64C and dependent modules functionality to intelmote2 would be great!

Original issue: http://code.google.com/p/tinyos-main/issues/detail?id=41

Original author: mortenthansen (March 17, 2011 14:16:34)

At least for the RF230 and RF212 radio stacks the packet link layer is put below the low power listening layer which makes no sense.

It should be placed above for increased reliability. Putting it below interfere with the workings of the LPL layer if used together.

Morten.

Original issue: http://code.google.com/p/tinyos-main/issues/detail?id=26

Original author: [email protected] (May 04, 2011 23:04:15)

Hi,

I want to install TinyOS on my Mac OS X, 2011 latest model.

I followed the <a href="http://docs.tinyos.net/index.php/Installing_TinyOS-2.x_on_Mac_OS_X_%28Snow_Leopard%29&quot;&gt;Installing TinyOS-2.x on Mac OS X (Snow Leopard)</a>. However, I am not able to compile the $TOSROOT/support/sdk/java. There are a ton of errors when compiling.

Then I looked into this further and got a possible workaround from the forum. <a href="http://old.nabble.com/Re%3A-TinyOS-install-problems-with-MacBook-Pro-%28OS-X-Snow-Leopard%29-p31411792.html&quot;&gt;Re: TinyOS install problems with MacBook Pro (OS X Snow Leopard)</a>.

However, when I tried compiling nesC 1.3.0 with gcc40 from xcode I get the following errors.

rm -f libparser.a
ar cru libparser.a AST.o AST_utils.o AST_walk.o array.o attributes.o c-lex.o c-parse.tab.o constants.o cval.o dd_list.o dhash.o edit.o env.o errors.o expr.o flags.o graph.o init.o lex.nd.o machine.o nesc-abstract.o nesc-atomic.o nesc-attributes.o nesc-c.o nesc-cg.o nesc-component.o nesc-concurrency.o nesc-configuration.o nesc-constants.o nesc-cpp.o nesc-deputy.o nesc-dfilter.o nesc-doc.o nesc-dspec.tab.o nesc-dump.o nesc-env.o nesc-gcc.o nesc-generate.o nesc-inline.o nesc-interface.o nesc-magic.o nesc-main.o nesc-module.o nesc-msg.o nesc-ndoc.o nesc-network.o nesc-paths.o nesc-semantics.o nesc-task.o nesc-uses.o nesc-xml.o sd_list.o semantics.o stmt.o types.o unparse.o utils.o
ranlib libparser.a
gcc -DHAVE_CONFIG_H -I. -I./libcompat -I./../libcpp/include -I./../libcpp -I./../include -g -Wno-long-double -Wall -MT toplev.o -MD -MP -MF .deps/toplev.Tpo -c -o toplev.o toplev.c
mv -f .deps/toplev.Tpo .deps/toplev.Po
gcc -g -Wno-long-double -Wall -o nesc1 toplev.o libparser.a libcompat/libregions.a ../libcpp/libcpp.a ../libiberty/libiberty.a -lm -liconv
ld: warning: in libparser.a, file was built for unsupported file format which is not the architecture being linked (i386)
ld: in libcompat/libregions.a, archive has no table of contents
collect2: ld returned 1 exit status
make[3]: *** [nesc1] Error 1
make[2]: *** [all-recursive] Error 1
make[1]: *** [all] Error 2
make: *** [all-recursive] Error 1

Please help me regarding this. I have tried with many flags for architectures but all in vain. Is this a problem with the new Macbook Pro or has anybody tried compiling it.

Thanks and Regards
Anupam

Original issue: http://code.google.com/p/tinyos-main/issues/detail?id=38

Original author: [email protected] (May 28, 2011 06:44:28)

What steps will reproduce the problem?

1. while compiling TOSSIM
   $ cd apps/Blink
   $ make micaz sim

What is the expected output? What do you see instead?
sasmita@sasmita-laptop:/opt/tinyos-2.1.1/apps/Blink$ make micaz sim
mkdir -p simbuild/micaz
placing object files in simbuild/micaz
writing XML schema to app.xml
compiling BlinkAppC to object file sim.o
ncc -c -shared -fPIC -o simbuild/micaz/sim.o -g -O0 -tossim -fnesc-nido-tosnodes=1000 -fnesc-simulate -fnesc-nido-motenumber=sim_node() -fnesc-gcc=gcc -Wall -Wshadow -Wnesc-all -target=micaz -fnesc-cfile=simbuild/micaz/app.c -board=micasb -DDEFINED_TOS_AM_GROUP=0x22 --param max-inline-insns-single=100000 -DIDENT_APPNAME="BlinkAppC" -DIDENT_USERNAME="sasmita" -DIDENT_HOSTNAME="sasmita-laptop" -DIDENT_USERHASH=0xb6d90fc0L -DIDENT_TIMESTAMP=0x4de08e72L -DIDENT_UIDHASH=0xc651c2faL -I/usr/include/python2.6 -Wno-nesc-data-race BlinkAppC.nc -fnesc-dump=components -fnesc-dump=variables -fnesc-dump=constants -fnesc-dump=typedefs -fnesc-dump=interfacedefs -fnesc-dump=tags -fnesc-dumpfile=app.xml
compiling Python support and C libraries into pytossim.o, tossim.o, and c-support.o
g++ -c -shared -fPIC -o simbuild/micaz/pytossim.o -g -O0 -DIDENT_APPNAME="BlinkAppC" -DIDENT_USERNAME="sasmita" -DIDENT_HOSTNAME="sasmita-laptop" -DIDENT_USERHASH=0xb6d90fc0L -DIDENT_TIMESTAMP=0x4de08e72L -DIDENT_UIDHASH=0xc651c2faL -I/usr/include/python2.6 /opt/tinyos-2.1.1/tos/lib/tossim/tossim_wrap.cxx -I/usr/include/python2.6 -I/opt/tinyos-2.1.1/tos/lib/tossim -DHAVE_CONFIG_H
/opt/tinyos-2.1.1/tos/lib/tossim/tossim_wrap.cxx: In function ‘void SWIG_Python_AddErrorMsg(const char*)’:
/opt/tinyos-2.1.1/tos/lib/tossim/tossim_wrap.cxx:880: warning: format not a string literal and no format arguments
g++ -c -shared -fPIC -o simbuild/micaz/tossim.o -g -O0 -DIDENT_APPNAME="BlinkAppC" -DIDENT_USERNAME="sasmita" -DIDENT_HOSTNAME="sasmita-laptop" -DIDENT_USERHASH=0xb6d90fc0L -DIDENT_TIMESTAMP=0x4de08e72L -DIDENT_UIDHASH=0xc651c2faL -I/usr/include/python2.6 /opt/tinyos-2.1.1/tos/lib/tossim/tossim.c -I/usr/include/python2.6 -I/opt/tinyos-2.1.1/tos/lib/tossim
g++ -c -shared -fPIC -o simbuild/micaz/c-support.o -g -O0 -DIDENT_APPNAME="BlinkAppC" -DIDENT_USERNAME="sasmita" -DIDENT_HOSTNAME="sasmita-laptop" -DIDENT_USERHASH=0xb6d90fc0L -DIDENT_TIMESTAMP=0x4de08e72L -DIDENT_UIDHASH=0xc651c2faL -I/usr/include/python2.6 /opt/tinyos-2.1.1/tos/lib/tossim/hashtable.c -I/usr/include/python2.6 -I/opt/tinyos-2.1.1/tos/lib/tossim
linking into shared object ./_TOSSIMmodule.so
g++ -shared -fPIC simbuild/micaz/pytossim.o simbuild/micaz/sim.o simbuild/micaz/tossim.o simbuild/micaz/c-support.o -lstdc++ -o _TOSSIMmodule.so
copying Python script interface TOSSIM.py from lib/tossim to local directory

*** Successfully built micaz TOSSIM library.

What version of the product are you using? On what operating system?
Ubuntu 10.04 Lucid
TinyOS 2.1.1

Please provide any additional information below.

Installed swig, python-setuptools python-dev
sudo apt-get install swig python-setuptools python-dev

How to regenerate Python support? The script sing-generate does not exist in tos/lib/tossim.

Original issue: http://code.google.com/p/tinyos-main/issues/detail?id=42

Original author: [email protected] (February 24, 2011 20:09:42)

I am implementing à Kalman filter target tracking application on TinyOS 2.x and I hope visualize my sensor network.

1. there is any tool like TinyViz that work with TOSSIM-T2 ?
2. if there is not ; haw can I simulate the target proximity ... i.e
   2.a Can we get the node position (x,y) with Tossim ?
   2.b how could I simulate the target proximity .. the sensors that are near the target that senses it ?
   Regards,
   ByDOS®

Original issue: http://code.google.com/p/tinyos-main/issues/detail?id=23

Original author: [email protected] (May 05, 2011 17:31:05)

What steps will reproduce the problem?

1. Use I2CPacket.write() to write write anything to the I2C bus; use a START condition but not a STOP condition
2. Use I2CPacket.write() a second time to keep writing to the same slave device; do not use START condition; may or may not use STOP condition

In the second write the slave address will be written again even though it does not have a START condition, which will cause the slave device to accept it as part of the data.

The problem seems to be in "tos/chips/atm128/Atm128FIF2CMasterPacketP.nc", inside of I2CPacket.write(), on line 248, it sends the slave address if it's not a I2C_START condition and length of packet is greater than 0:

241: if (flags & I2C_START) {
242: call I2C.setStart(TRUE);
243: // call WriteDebugLeds.led0On();
244: state = I2C_STARTING;
245: }
246: else if (len > 0) {
247: state = I2C_DATA;
248: call I2C.write(((packetAddr & 0x7f) << 1) | ATM128_I2C_SLA_WRITE);
249: }

I believe it should be something like this:

241: if (flags & I2C_START) {
242: call I2C.setStart(TRUE);
243: // call WriteDebugLeds.led0On();
244: state = I2C_STARTING;
245: }
246: else if (len > 0) {
247: state = I2C_DATA;
248: call I2C.write(packetPtr[index]);
249: index++;
250: }

Original issue: http://code.google.com/p/tinyos-main/issues/detail?id=39

Original author: [email protected] (July 28, 2011 01:15:36)

While working on getting blip to work on a different board (modflex), I ran into application restarts when attempting to send UDP packets. Eventually I traced this down a memset scribbling past the end of the struct it was meant to clear. I presume other architectures have been a lot more forgiving about this for this to have gone undetected so far...

Cheers,
/Johny

Original issue: http://code.google.com/p/tinyos-main/issues/detail?id=47

Original author: [email protected] (June 08, 2011 23:10:37)

add support in the core msp430 files for the new uniarch toolchain.

Original issue: http://code.google.com/p/tinyos-main/issues/detail?id=43

Original author: [email protected] (June 09, 2011 03:16:53)

This patch to deluge removes the wiring to VoltageC() in ReprogramGuardC on telos platforms and instead wires directly to the MSP430 ADC -- the arbiters and everything are still used but a lot of other things are no longer pulled in. By my measurements, this saves 2.2k when nothing else is using the ADC and does the same thing. I'd like to get this into 2.1.2 because deluge tends to make apps pretty tight on code.

Also, ReprogramGuard* under tos/lib/net/Deluge/extra/telosb should be removed because they're not pulled in -- the include order pulls in the ones under telos instead, which is fine.

Original issue: http://code.google.com/p/tinyos-main/issues/detail?id=44

Original author: [email protected] (March 22, 2011 09:17:02)

What steps will reproduce the problem?

"http://research-machine.blogspot.com/2010/01/how-to-install-tinyos-2-on-macosx-106.html"

a)The first one is "file not found: PrintMsg.java"
I don't know why, but thefile "support\sdk\java\net\tinyos\message\SerialPacket.java" is missing in the newest version of TinyOS
Just copy it from and an older repository and run again.

What is the expected output? What do you see instead?
a)The first one is "file not found: PrintMsg.java"
I don't know why, but thefile "support\sdk\java\net\tinyos\message\SerialPacket.java" is missing in the newest version of TinyOS
Just copy it from and an older repository and run again.

What version of the product are you using? On what operating system?
Mac OS X 10.6.6

Please provide any additional information below.
Please add the file back or I can't finish thie guide. I don't know where to look for that file.

Original issue: http://code.google.com/p/tinyos-main/issues/detail?id=28

Original author: [email protected] (February 09, 2011 12:05:48)

In line 44: uses interface DiagMsg;

1. this interface is never used within the module.
2. No wiring is provided for this interface which causes the following error:

In component `Taos2550ReaderP':
/opt/tinyos-updated/tos/sensorboards/mts400/Taos2550ReaderP.nc:44: interface DiagMsg not found

Original issue: http://code.google.com/p/tinyos-main/issues/detail?id=15

Original author: [email protected] (April 18, 2011 20:05:18)

What steps will reproduce the problem?

1. Install tinyos-main/apps/tests/cc2420/TestSecurity/RadioCountToLeds1 on an appropriate mote (I've tested with telosbs and various shimmer revs).
2. Using a sniffer look at the transmitted data. Do not use a receiver mote as the receive side is equally broken and hides the problem.

What is the expected output? What do you see instead?
As CCM mode is selected the data should be encrypted and authenticated with a 16byte MIC. Instead the data, i.e. the count, is transmitted in plain text, and only 4 bytes of the MIC are set. I haven't tested whether these 4 bytes are set correctly or not. I've checked this with each mode and there are serious problems with all of them.

Specfically in CTR mode the data is sent in plain text instead of encrypted. Additionally the last 4 bytes of the data are truncated (related to the MIC issues in the other modes???).
In CBC_MAC mode only the last 4 bytes of the MIC are over written by the CC2420 driver (again I've not checked if this MIC is in any way correct) even if the MIC size is set to 8 or 16.
And when no security is set only the very first packet seems to be sent after the mote boots up, I don't see any sign of any subsequent packet.

What version of the product are you using? On what operating system?
This is an issue with the current SVN head (rev 5538). I've tested as far back as SVN rev 5173, and while the problem is different, it is still very much broken. When I test with the final version of tinyos-2.x in sourceforge it works as expected.

Please provide any additional information below.
As an example here are 3 (full) subsequent packets from the RadioCountToLeds1 application, using tinyos-main SVN rev 5538:
69 88 e3 22 00 ff ff 01 00 3f 00 00 0a e4 01 00 06 0a e4 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b9 0e 1c 60 18 ca ff

69 88 e4 22 00 ff ff 01 00 3f 00 00 0a e5 01 00 06 0a e5 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b9 0e 1c 60 11 4f ff

69 88 e5 22 00 ff ff 01 00 3f 00 00 0a e6 01 00 06 0a e6 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b9 0e 1c 60 d8 d8 ff

and here are 3 packets from the exact same applications using the last tinyos-2.x rev from sourceforge:
69 88 4d 22 00 ff ff 01 00 e8 00 00 00 4e 01 3f 06 23 0d 15 6c ca cd 0c d4 ba 7e 17 a0 72 b6 ca 38 99 fa 1b 73 13 41 4e 92 6c 96 54 48 6e 20 c6 b4 09 f6 5c 98 ef a1 58 6d 61 fb e2 70 b1 5b 6b dc 85 1e f3 d3 eb 7c 8d 5d 2c d5 80 2f ff

69 88 4e 22 00 ff ff 01 00 e8 00 00 00 4f 01 3f 06 63 1a 3f d0 65 6d 0d 84 df 68 0f 07 bf 23 9d 88 4f cf 14 ef d0 c4 e8 c8 26 99 65 b9 57 31 d9 26 78 2b 1e a0 0b a2 45 d9 af e7 48 e4 8a 9d f4 56 eb df 53 35 36 43 0d d5 c7 b9 a7 36 ff

69 88 4f 22 00 ff ff 01 00 e8 00 00 00 50 01 3f 06 87 19 06 58 60 01 41 f7 76 e1 69 77 ce b3 ed 65 aa 83 2a 27 1b 67 ea 06 0f dd 89 34 44 4b ae 11 ec cf 79 ad bc cf 6f ce 5a a3 a9 d8 b1 98 6c d9 90 5b bb b1 60 d0 03 a3 cd 3a 51 47 ff

The count is obvious in the SVN rev 5538 version, i.e. 0xe4, 0xe5, 0xe6.

The count is impossible to determine from the data section of the tinyos-2.x sourceforge rev (even though from the sequence number it is obvious that it is 0x4e, 0x4f, 0x50).

Original issue: http://code.google.com/p/tinyos-main/issues/detail?id=34

Original author: [email protected] (March 18, 2011 12:00:17)

What steps will reproduce the problem?

1. Set power level to lower than maximum power
2. Use SACK/HACK
3. Let one telosb node sending packets, requesting an ack and printing the rssi of the ack
4. Let the other node receiving without sending anything and printing the rssi value of the received packet as well
5. Compare the rssi values of the ack and received packet

Hello,
I think I have found a bug in the cc2420 stack concerning the transmission power of the acknowledgements.
I am using the svn revision 5304 on the cc2420 folder.

In my setup a telosb node is continuously sending packets, requests an ack and prints the rssi value of the ack. Another node is receiving and prints out the rssi value of the received packet.

The problem occurs when I reduce the transmission power by setting
CFLAGS += -DCC2420_DEF_RFPOWER=1. The rssi of the acknowledgement
equals the transmission power of power level 31 and not the rssi of
the received packet.
It seems that the initial transmission power for the receiving node
was not set to DCC2420_DEF_RFPOWER. It looks like this should be done by CC2420Control.Init. But the m_power_level is never used as well as synchronized with the cc2420 chip.
For the maximum transmission power the rssi values of the ack and
received packet equals. The behavior occurs for SACK and HACK.

I found out that I can fix the problem by the transmission of one
packet on the receiving node. It seems like after the SoftwareInit the radio chip resets once more or the CC2420Config.sync() will never be called to commit changes to TXCTRL.

I think the problem could be fixed by setting the TXCTRL in the CC2420ConfigP in CC2420Power.startOscillator().

Best regards,
Tobias

Some code snippets of my test application:

event void RadioControl.startDone(error_t err){
if (err == SUCCESS){
call CC2420Config.setAutoAck(1,0); //enable auto-sw-acks
call CC2420Config.sync();
}
else {
call RadioControl.start();
}
}

event void CC2420Config.syncDone(error_t error){
if (error == SUCCESS){
call Timer1.startPeriodic(600);
}
else{
call CC2420Config.setAutoAck(1,0); //enable auto-sw-acks
call CC2420Config.sync();
}
}

event void Timer1.fired(){
am_addr_t dest = 1;
test_pkt_t* pkt = call
RadioSend.getPayload(&radio_pkt,sizeof(test_pkt_t));
seqno++;
pkt->seqno = seqno;
call Acks.requestAck(&radio_pkt);
call RadioSend.send(dest,&radio_pkt,sizeof(test_pkt_t));
}

event void RadioSend.sendDone(message_t* msg, error_t err){
if (msg==&radio_pkt && err==SUCCESS){
if (call Acks.wasAcked(msg)){
printf("ACK received seqno:%u rssi:%02d\n \n",seqno, call
CC2420Packet.getRssi(msg)-45);
}
else {
printf("Packet LOST seqno:%u \n",seqno);
}
}
printfflush();
}

event message_t* RadioReceive.receive(message_t* msg, void*
payload, uint8_t len){
test_pkt_t* pkt = payload;
printf("RECEIVED seqno:%u rssi:%02d\n \n",pkt->seqno, call CC2420Packet.getRssi(msg)-45);
printfflush();
return msg;
}

Original issue: http://code.google.com/p/tinyos-main/issues/detail?id=27

Original author: [email protected] (April 20, 2011 15:17:42)

What steps will reproduce the problem?

1. python version is 2.6.5
2. go to app/Blink
3. make micaz sim

What is the expected output? What do you see instead?
python2.5-config command not found

What version of the product are you using? On what operating system?
tinyos 2.1.1 ubuntu 10.04

Please provide any additional information below.
if edit support/sim/extra make python version 2.6 , the problem is fixed.
Can tinyos get python version automatically

Original issue: http://code.google.com/p/tinyos-main/issues/detail?id=35

Original author: [email protected] (June 13, 2011 10:24:19)

Radio startCount is not incremented in TrafficMonitorLayerP.

Original issue: http://code.google.com/p/tinyos-main/issues/detail?id=46

Original author: [email protected] (April 17, 2011 11:15:29)

Current practice has individual components (PrintfC, SerialPrintfC, and PppPrintfC) all implementing the low-level libc interface to whatever function libc on a specific platform uses for single-character output. This patch refactors the platform-specific material to a new PutcharP component in $(TOSDIR)/lib/printf. Developers of components that provide printf capability should wire their implementation of the Putchar interface, isolating them from anything platform-specific.

Tested with apps/tutorials/Printf (PrintfC), apps/TestSerialPrintf (SerialPrintfC), and tos/lib/ppp/tests/Ipv6 (PppPrintfC). FWIW, apps/tests/TestPrintf does not build and should be removed.

Original issue: http://code.google.com/p/tinyos-main/issues/detail?id=33

Original author: [email protected] (April 08, 2011 10:09:13)

What steps will reproduce the problem?

1. apps that use ppp protocol such as 'tos/lib/ppp/tests/Ipv6' can't compile on atm128-based platforms(mica-serial,iris), due to the lack of AlarmMilli32C/CounterMilli32C/PlatformLedC/avr_stdio.h.
2. On avr-based platforms, the mote resets when printf() is called, because the putchar() function in PppPrintfP only works for msp430.

What version of the product are you using? On what operating system?

tinyos-main svn r5536, IRIS platform, Linux

Please provide any additional information below.

I attached the patch which makes ppp works on IRIS as I tested, hope to solve the problem.

Original issue: http://code.google.com/p/tinyos-main/issues/detail?id=29

Original author: [email protected] (August 03, 2011 04:16:36)

Msp430Adc12ClientAutoRVGC is currently not releasing the ADC resource when done, which is causing a problem in Deluge (issue #44).

Original issue: http://code.google.com/p/tinyos-main/issues/detail?id=50

Original author: [email protected] (February 22, 2011 16:08:44)

What steps will reproduce the problem?

1. running blink application by using "make micaz sim" and make micaz.
2. error:Unknown target micaz
   Known targets for TinyOS directory /opt/tinyos-2.x/tos are:none.
   make: *** [exe0] Error 2
3. if i use "make pc" or "make pc sim"
4. ERROR, "pc ident_flags tos_image bnp" does not specify a valid target. Stop.

What is the expected output? What do you see instead?
no idea..

What version of the product are you using? On what operating system?
window xp,cygwin,tinyos-2.x

Please provide any additional information below.

Original issue: http://code.google.com/p/tinyos-main/issues/detail?id=22

Original author: [email protected] (February 22, 2011 14:55:34)

What steps will reproduce the problem?

1. Connect ERASE and reset the board.
2. Connect JTAG and lauch openocd. Make sure the output shows how many watchpoints and breakpoints the board supports.
3. Run GDB and execute the following script:

target remote :3333
mon halt
load
mon at91sam3 gpnvm set 1
mon soft_reset_halt
b main
continue

1. At the breakpoint, step (next) through until the Platform.init call. This call will block and never return. For some reason, the main clock never gets ready after the last switch to the PLLA clock.
2. execute "mon soft_reset_halt"
3. Continue the execution, and step again through the code. This time, Platform.init will return and not get stuck at the mainclock switch.

I have no idea why we get stuck the first time, but not the second time. Might be related to issue 20 (http://code.google.com/p/tinyos-main/issues/detail?id=20)?

Original issue: http://code.google.com/p/tinyos-main/issues/detail?id=21

Original author: [email protected] (March 02, 2011 23:28:09)

What steps will reproduce the problem?

1. Install an application with PrintfP that does not explicitly start the serial port.
2. Measure idle current of the platform.
   3.

What is the expected output? What do you see instead?

Since the application has not started the serial port, it should be able to go into an ultra-low power state. But PrintfP starts the serial port, precluding low power operation.

Serial port power control (along with the radio) should be left to the application. PrintfP should not handle the booted event to start the serial stack.

Please use labels and text to provide additional information.

Original issue: http://code.google.com/p/tinyos-main/issues/detail?id=25