[Tinyos-help] AMSend.send() returns SUCCESS, but AMSend.sendDone() is never signaled.

[David Lee]

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.

[Michael Schippling]

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

[David Lee]

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

Re: [Tinyos-help] AMSend.send() returns SUCCESS, but AMSend.sendDone() is never signaled.

[Michael Schippling]

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

Re: [Tinyos-help] AMSend.send() returns SUCCESS, but AMSend.sendDone() is never signaled.

[David Lee]

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
here


On Thu, May 5, 2011 at 1:37 PM, Michael Schippling wrote:

> 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.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(!(re

Re: [Tinyos-help] AMSend.send() returns SUCCESS, but AMSend.sendDone() is never signaled.

[David Lee]

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  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 
> here
>
>
> On Thu, May 5, 2011 at 1:37 PM, Michael Schippling wrote:
>
>> 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.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;
>>>   

Re: [Tinyos-help] AMSend.send() returns SUCCESS, but AMSend.sendDone() is never signaled.

[Michael Schippling]

Sorry, I'm clueless...
I don't use T2 or all the fancy resource grant stuff you have.
There are/used-to-be simple demo apps like Blink2Radio that
sent simple messages. I would go back to one of those and see
if it works, then build on it.

MS


David Lee 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 here 
> 
> David A. Lee
> Co-Social Chair - Tau Kappa Epsilon Xi Chapter
> Projects Manager - IEEE@Wash U
> 
> 
> 
> On Thu, May 5, 2011 at 1:37 PM, Michael Schippling  > wrote:
> 
> 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
> mailto: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.
> 
>