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<http://pastebin.com/9sqN6Bv1>


On Thu, May 5, 2011 at 1:37 PM, Michael Schippling <sc...@santafe.edu>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<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.
>>
>>        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
>>        <mailto: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

Reply via email to