[Tinyos-help] AMSend.send() returns SUCCESS, but AMSend.sendDone() is never signaled.
Hey everyone -
I'm working on some radio code for the telosB motes. Specifically, my code
calls AMSend.send(), and via the printf library, I've proved that it returns
SUCCESS.
Unfortunately, the event for sendDone never gets called.
I've heard that this can be caused due to ack issues, so for now, I've
tossed a
#define CC2420_NO_ACKNOWLEDGEMENTS
right after my include statements.
Anyone have any other ideas of what can cause this?
--- Code Below ---
#include SensorMsg.h
#include printf.h
#define CC2420_NO_ACKNOWLEDGEMENTS
module Uint8_tSenderC{
provides
{
interface ByteSend;
}
uses{
interface Leds;
interface AMSend;
interface SplitControl as AMControl;
interface Packet;
interface AMPacket;
interface Resource as RadioResource;
}
}
implementation{
bool busy = FALSE;
uint8_t sendVal;
event void AMSend.sendDone(message_t *msg, error_t error){
error_t retVal;
printf(AMSend.sendDone(%p, %u), msg, error);
printfflush();
call Leds.led1On();
if(error == SUCCESS)
{ call Leds.led2Toggle();
retVal = call AMControl.stop();
while(!(retVal == SUCCESS || retVal == EALREADY ))
{
retVal = call AMControl.stop();
}
}
else
{
call AMSend.send(AM_BROADCAST_ADDR, msg, sizeof(SensorMessage_t));
}
}
event void AMControl.startDone(error_t error){
error_t retVal;
message_t msgBuf;
printf(AMControl.startDone started. Parameter: %u. SendVal:%u\n,error,
sendVal);
printfflush();
if(error == SUCCESS)
{
if(!busy)
{
SensorMessage_t * payload;
payload = (SensorMessage_t *) call Packet.getPayload(msgBuf,
sizeof(SensorMessage_t));
payload-nodeId=TOS_NODE_ID;
payload-sensorType=0x01;
payload-msgType=0x03;
payload-msgValue= sendVal;
busy = TRUE;
printf(Payload of %u packed into message buffer at %p\n, sendVal,
msgBuf);
printfflush();
retVal = call AMSend.send(AM_BROADCAST_ADDR, msgBuf,
sizeof(SensorMessage_t));
printf(AMSend.send() returned %u\n, retVal);
printfflush();
while(retVal != SUCCESS)
{
if(retVal == EBUSY)
{
call Leds.led1On();
}
if(retVal == FAIL)
{
call Leds.led1On();
}
printf(AMSend.send() returned %u\n, retVal);
printfflush();
retVal = call AMSend.send(AM_BROADCAST_ADDR, msgBuf,
sizeof(SensorMessage_t));
}
printf(AMSend.send() returned SUCCESS\n);
printfflush();
call Leds.led2On();
}
}
else
{
printf(AMSend.send() restarted!\n);
printfflush();
call AMControl.start();
}
}
event void RadioResource.granted(){
error_t retVal;
retVal = call AMControl.start();
while(!(retVal == SUCCESS || retVal == EALREADY ))
{
retVal = call AMControl.start();
}
}
event void AMControl.stopDone(error_t error){
call RadioResource.release();
signal ByteSend.sendDone();
}
command error_t ByteSend.doSend(uint8_t toSend){
error_t ret;
if(!busy)
{
printf(Attempting to send %u\n, toSend);
printfflush();
sendVal = toSend;
ret = call RadioResource.request(); //immediateRequest();
while(ret != SUCCESS)
{
printf(RadioResource.request() failed with status %u\n, ret);
printfflush();
ret = call RadioResource.request(); //immediateRequest();
}
printf(RadioResource.request() returned SUCCESS\n);
printfflush();
call Leds.led0On();
}
else
{
ret = FALSE;
}
return ret;
}
}
--- Code Above
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] AMSend.send() returns SUCCESS, but AMSend.sendDone() is never signaled.
That's an excellent idea I never thought to look for.
However, I know it's not that specific infinite loop, since the printf()
usually prints the same thing (except for the occasional bad packet?), and
that's:
Thread[Thread-1,5,main]serial@/dev/mote_ultrasound:115200: resynchronising
Attempting to send 101
RadioResource.request() returned SUCCESS
AMControl.startDone started. Parameter: 0. SendVal:101
Payload of 101 packed into message buffer at 0x38b6
AMSend.send() returned 0
AMSend.send() returned SUCCESS
Based on my code, that seems to imply it makes a success on it's first try.
Is there any profiling tool I can use on the msp430 found in the telosB,
rather than trying to tease out the error by hand?
Thanks again for your help and rapid response,
On Thu, May 5, 2011 at 12:39 PM, Michael Schippling sc...@santafe.eduwrote:
One should get a sendDone() with a failed ACK, although
you probably need to look at the message.ack field rather
then the error argument to figure it out.
If you are not getting the sendDone() call ever-at-all,
I would suspect that you have something hogging the processor
-- like that possibly infinite-loop of error checking after
your send() call (I'm too lazy to run it in my head) -- or
that calling send() from the startDone() is too early in
the cycle. If that's the case you could try calling send()
from a Timer.fired(), or posting a Task to do it a little
later on.
MS
David Lee wrote:
Hey everyone -
I'm working on some radio code for the telosB motes. Specifically, my code
calls AMSend.send(), and via the printf library, I've proved that it returns
SUCCESS.
Unfortunately, the event for sendDone never gets called.
I've heard that this can be caused due to ack issues, so for now, I've
tossed a
#define CC2420_NO_ACKNOWLEDGEMENTS
right after my include statements.
Anyone have any other ideas of what can cause this?
--- Code Below ---
#include SensorMsg.h
#include printf.h
#define CC2420_NO_ACKNOWLEDGEMENTS
module Uint8_tSenderC{
provides {
interface ByteSend;
}
uses{
interface Leds;
interface AMSend;
interface SplitControl as AMControl;
interface Packet;
interface AMPacket;
interface Resource as RadioResource;
}
}
implementation{
bool busy = FALSE;
uint8_t sendVal;
event void AMSend.sendDone(message_t *msg, error_t error){
error_t retVal;
printf(AMSend.sendDone(%p, %u), msg, error);
printfflush();
call Leds.led1On();
if(error == SUCCESS)
{ call Leds.led2Toggle();
retVal = call AMControl.stop();
while(!(retVal == SUCCESS || retVal == EALREADY ))
{
retVal = call AMControl.stop();
}
}
else
{
call AMSend.send(AM_BROADCAST_ADDR, msg, sizeof(SensorMessage_t));
}
}
event void AMControl.startDone(error_t error){
error_t retVal;
message_t msgBuf;
printf(AMControl.startDone started. Parameter: %u. SendVal:%u\n,error,
sendVal);
printfflush();
if(error == SUCCESS)
{
if(!busy)
{
SensorMessage_t * payload;
payload = (SensorMessage_t *) call Packet.getPayload(msgBuf,
sizeof(SensorMessage_t));
payload-nodeId=TOS_NODE_ID;
payload-sensorType=0x01;
payload-msgType=0x03;
payload-msgValue= sendVal;
busy = TRUE;
printf(Payload of %u packed into message buffer at %p\n, sendVal,
msgBuf);
printfflush();
retVal = call AMSend.send(AM_BROADCAST_ADDR, msgBuf,
sizeof(SensorMessage_t));
printf(AMSend.send() returned %u\n, retVal);
printfflush();
while(retVal != SUCCESS)
{
if(retVal == EBUSY)
{
call Leds.led1On();
}
if(retVal == FAIL)
{
call Leds.led1On();
}
printf(AMSend.send() returned %u\n, retVal);
printfflush();
retVal = call AMSend.send(AM_BROADCAST_ADDR, msgBuf,
sizeof(SensorMessage_t));
}
printf(AMSend.send() returned SUCCESS\n);
printfflush();
call Leds.led2On();
}
}
else {
printf(AMSend.send() restarted!\n);
printfflush();
call AMControl.start();
}
}
event void RadioResource.granted(){
error_t retVal;
retVal = call AMControl.start();
while(!(retVal == SUCCESS || retVal == EALREADY ))
{
retVal = call AMControl.start();
}
}
event void AMControl.stopDone(error_t error){
call RadioResource.release();
signal ByteSend.sendDone();
}
command error_t ByteSend.doSend(uint8_t toSend){
error_t ret;
if(!busy)
{
printf(Attempting to send %u\n, toSend);
printfflush();
sendVal = toSend;
ret = call RadioResource.request(); //immediateRequest();
while(ret != SUCCESS)
{
printf(RadioResource.request() failed with status %u\n, ret);
printfflush();
ret = call RadioResource.request(); //immediateRequest();
}
printf(RadioResource.request() returned SUCCESS\n);
printfflush();
call Leds.led0On();
}
else
{
ret = FALSE;
}
return ret;
}
}
--- Code Above
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] AMSend.send() returns SUCCESS, but AMSend.sendDone() is never signaled.
So, I've broken a test bit out that just handles the sending of a single
byte.
I've stuck more printfs in there to check for loops (not enough leds to use
those)
I'm not seeing any loops in my code's output. For references, here's the
output:
Thread[Thread-1,5,main]serial@/dev/mote_ultrasound:115200: resynchronising
RadioTestC Booted!
Attempting to send 50
RadioResource.request() - outside loop - returned SUCCESS
doSend returned 0
RadioResource.granted() - before loop - retVal: 0
RadioResource.granted() - after loop - retVal: 0
AMControl.startDone started. Parameter: 0. SendVal:50
Payload of 50 packed into message buffer at 0x38b6
AMSend.send() - before loop - returned 0
AMSend.send() - after loop - returned SUCCESS
AMSend.send() about to return
The code puts the email above the moderation limit, so I've posted it
herehttp://pastebin.com/9sqN6Bv1
On Thu, May 5, 2011 at 1:37 PM, Michael Schippling sc...@santafe.eduwrote:
I don't know of any telos profiling tools. It does have
pads for a JTAG connector which you could use to trace
code, but I've never used it. Toggling LEDs is the best
debugging tool available, since it's easy (if you keep
the on/off patterns logical somehow) and doesn't interfere
with timing -- of course I always debug with printf's
on real computers too --
I think simplifying your program a bit and putting the
send() in it's own task might be the best start.
The issue with processor-hogging, and the reason
programs need to be broken up into small execution
units, is that TOS is not pre-emptive. So if you have
something that gets stuck in a loop and doesn't return
to the scheduler, no other tasks get executed. Since
everything pretty much relies on being able to fire
off a new task, even the Timer code, the system drags
to a halt.
MS
David Lee wrote:
That's an excellent idea I never thought to look for.
However, I know it's not that specific infinite loop, since the printf()
usually prints the same thing (except for the occasional bad packet?), and
that's:
Thread[Thread-1,5,main]serial@/dev/mote_ultrasound:115200:
resynchronising
Attempting to send 101
RadioResource.request() returned SUCCESS
AMControl.startDone started. Parameter: 0. SendVal:101
Payload of 101 packed into message buffer at 0x38b6
AMSend.send() returned 0
AMSend.send() returned SUCCESS
Based on my code, that seems to imply it makes a success on it's first
try.
Is there any profiling tool I can use on the msp430 found in the telosB,
rather than trying to tease out the error by hand?
Thanks again for your help and rapid response,
On Thu, May 5, 2011 at 12:39 PM, Michael Schippling
sc...@santafe.edumailto:
sc...@santafe.edu wrote:
One should get a sendDone() with a failed ACK, although
you probably need to look at the message.ack field rather
then the error argument to figure it out.
If you are not getting the sendDone() call ever-at-all,
I would suspect that you have something hogging the processor
-- like that possibly infinite-loop of error checking after
your send() call (I'm too lazy to run it in my head) -- or
that calling send() from the startDone() is too early in
the cycle. If that's the case you could try calling send()
from a Timer.fired(), or posting a Task to do it a little
later on.
MS
David Lee wrote:
Hey everyone -
I'm working on some radio code for the telosB motes.
Specifically, my code calls AMSend.send(), and via the printf
library, I've proved that it returns SUCCESS.
Unfortunately, the event for sendDone never gets called.
I've heard that this can be caused due to ack issues, so for
now, I've tossed a
#define CC2420_NO_ACKNOWLEDGEMENTS
right after my include statements.
Anyone have any other ideas of what can cause this?
--- Code Below ---
#include SensorMsg.h
#include printf.h
#define CC2420_NO_ACKNOWLEDGEMENTS
module Uint8_tSenderC{
provides {
interface ByteSend;
}
uses{
interface Leds;
interface AMSend;
interface SplitControl as AMControl;
interface Packet;
interface AMPacket;
interface Resource as RadioResource;
}
}
implementation{
bool busy = FALSE;
uint8_t sendVal;
event void AMSend.sendDone(message_t *msg, error_t error){
error_t retVal;
printf(AMSend.sendDone(%p, %u), msg, error);
printfflush();
call Leds.led1On();
if(error == SUCCESS)
{ call Leds.led2Toggle();
retVal = call AMControl.stop();
while(!(retVal == SUCCESS || retVal == EALREADY ))
{
retVal = call AMControl.stop();
}
}
else
{
call AMSend.send(AM_BROADCAST_ADDR, msg, sizeof(SensorMessage_t
Re: [Tinyos-help] AMSend.send() returns SUCCESS, but AMSend.sendDone() is never signaled.
Sorry for the double-email, but I may have found some interesting
information.
I tried using MSPSim, which I know isn't 100% accurate, but it at least has
a Profile command.
It seems I'm spending a LOT of time in McuSleepC__getPowerState.
Does that indicate anything?
On Thu, May 5, 2011 at 3:34 PM, David Lee d...@gray101.com wrote:
So, I've broken a test bit out that just handles the sending of a single
byte.
I've stuck more printfs in there to check for loops (not enough leds to use
those)
I'm not seeing any loops in my code's output. For references, here's the
output:
Thread[Thread-1,5,main]serial@/dev/mote_ultrasound:115200:
resynchronising
RadioTestC Booted!
Attempting to send 50
RadioResource.request() - outside loop - returned SUCCESS
doSend returned 0
RadioResource.granted() - before loop - retVal: 0
RadioResource.granted() - after loop - retVal: 0
AMControl.startDone started. Parameter: 0. SendVal:50
Payload of 50 packed into message buffer at 0x38b6
AMSend.send() - before loop - returned 0
AMSend.send() - after loop - returned SUCCESS
AMSend.send() about to return
The code puts the email above the moderation limit, so I've posted it
herehttp://pastebin.com/9sqN6Bv1
On Thu, May 5, 2011 at 1:37 PM, Michael Schippling sc...@santafe.eduwrote:
I don't know of any telos profiling tools. It does have
pads for a JTAG connector which you could use to trace
code, but I've never used it. Toggling LEDs is the best
debugging tool available, since it's easy (if you keep
the on/off patterns logical somehow) and doesn't interfere
with timing -- of course I always debug with printf's
on real computers too --
I think simplifying your program a bit and putting the
send() in it's own task might be the best start.
The issue with processor-hogging, and the reason
programs need to be broken up into small execution
units, is that TOS is not pre-emptive. So if you have
something that gets stuck in a loop and doesn't return
to the scheduler, no other tasks get executed. Since
everything pretty much relies on being able to fire
off a new task, even the Timer code, the system drags
to a halt.
MS
David Lee wrote:
That's an excellent idea I never thought to look for.
However, I know it's not that specific infinite loop, since the printf()
usually prints the same thing (except for the occasional bad packet?), and
that's:
Thread[Thread-1,5,main]serial@/dev/mote_ultrasound:115200:
resynchronising
Attempting to send 101
RadioResource.request() returned SUCCESS
AMControl.startDone started. Parameter: 0. SendVal:101
Payload of 101 packed into message buffer at 0x38b6
AMSend.send() returned 0
AMSend.send() returned SUCCESS
Based on my code, that seems to imply it makes a success on it's first
try.
Is there any profiling tool I can use on the msp430 found in the telosB,
rather than trying to tease out the error by hand?
Thanks again for your help and rapid response,
On Thu, May 5, 2011 at 12:39 PM, Michael Schippling
sc...@santafe.edumailto:
sc...@santafe.edu wrote:
One should get a sendDone() with a failed ACK, although
you probably need to look at the message.ack field rather
then the error argument to figure it out.
If you are not getting the sendDone() call ever-at-all,
I would suspect that you have something hogging the processor
-- like that possibly infinite-loop of error checking after
your send() call (I'm too lazy to run it in my head) -- or
that calling send() from the startDone() is too early in
the cycle. If that's the case you could try calling send()
from a Timer.fired(), or posting a Task to do it a little
later on.
MS
David Lee wrote:
Hey everyone -
I'm working on some radio code for the telosB motes.
Specifically, my code calls AMSend.send(), and via the printf
library, I've proved that it returns SUCCESS.
Unfortunately, the event for sendDone never gets called.
I've heard that this can be caused due to ack issues, so for
now, I've tossed a
#define CC2420_NO_ACKNOWLEDGEMENTS
right after my include statements.
Anyone have any other ideas of what can cause this?
--- Code Below ---
#include SensorMsg.h
#include printf.h
#define CC2420_NO_ACKNOWLEDGEMENTS
module Uint8_tSenderC{
provides {
interface ByteSend;
}
uses{
interface Leds;
interface AMSend;
interface SplitControl as AMControl;
interface Packet;
interface AMPacket;
interface Resource as RadioResource;
}
}
implementation{
bool busy = FALSE;
uint8_t sendVal;
event void AMSend.sendDone(message_t *msg, error_t error){
error_t retVal;
printf(AMSend.sendDone(%p, %u), msg, error);
printfflush();
call
[Tinyos-help] Contribution to TinyOS - MSPSim build extra
Hey all, I'm using TinyOS for a university project, and specifically am working with the TelosB motes. I'm also using the YETI plugin for Eclipse, so running any sort of simulation was a bit of a pain. In order to be able to simulate my stuff via the standard build system, I made a custom .extra file for the build system. The changeset consists of the following things: 1. A new file mspsim.extras that lives in the /support/make/msp folder 2. A new folder, /tools/mspsim that contains mspsim.jar and its lib folder 3. A utility script that I wrote called open-terminal, that handles opening a terminal for the simulator (the eclipse one tends not to work reliably) regardless of platform. Once it's properly installed, enabling the mspsim extra automatically builds the project and then starts the simulator. Currently, since I don't believe MSPSim is part of TinyOS, my build extra doesn't download or compile that dependency. I'm unsure of what the next step is, though. Apparently, it isn't the tinyos-devel mailing list, because they rejected this. Should I just attach the files to a followup? Thanks for your input ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] Contribution to TinyOS - MSPSim build extra
Hey all, I'm using TinyOS for a university project, and specifically am working with the TelosB motes. I'm also using the YETI plugin for Eclipse, so running any sort of simulation was a bit of a pain. In order to be able to simulate my stuff via the standard build system, I made a custom .extra file for the build system. The changeset consists of the following things: 1. A new file mspsim.extras that lives in the /support/make/msp folder 2. A new folder, /tools/mspsim that contains mspsim.jar and its lib folder 3. A utility script that I wrote called open-terminal, that handles opening a terminal for the simulator (the eclipse one tends not to work reliably) regardless of platform. Once it's properly installed, enabling the mspsim extra automatically builds the project and then starts the simulator. Currently, since I don't believe MSPSim is part of TinyOS, my build extra doesn't download or compile that dependency. I'm unsure of what the next step is, though. Apparently, it isn't the tinyos-devel mailing list, because they rejected this. Should I just attach the files to a followup? Thanks for your input David A. Lee Co-Social Chair - Tau Kappa Epsilon Xi Chapter Projects Manager - IEEE@Wash U ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
