naren0nindiatimes / tinyos-main Goto Github PK

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

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.

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...

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

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.

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.

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;
   }

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

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">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">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

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: 
c143598ae)


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.

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>";
       }
     }

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

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.

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 ();

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.

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.

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

4. 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.
5. execute "mon soft_reset_halt"
6. 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)?

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

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

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).

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

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.

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?

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...

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.

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.

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

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;
}

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. 

Radio startCount is not incremented in TrafficMonitorLayerP.

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

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.

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.

Please see my patch at:
https://github.com/errordeveloper/tinyos-wmi/commit/1845e4d30428d68c427e8c0dccd2
09223236fa45

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.

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

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!

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..

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;

It should return U1CTL instead of U0CTL.

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.

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®

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.

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.

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;

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

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.

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.

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;

 }

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