Ok, but there should be 2x 1.5V AA batteries in series, which is 3V, so you
should have enough voltage there for the flash operations.

Did you, in fact, double check that your batteries can source 75+ mA?  I
know some batteries can't - like the coin cell batteries with the
mica2dot's.  

Try using some regular AA batteries, not the rechargable kind, to see if
that makes any difference.

-David

-----Original Message-----
From: Munaretto, Daniel [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, September 19, 2006 1:57 AM
To: David Moss; [email protected]
Subject: RE: [Tinyos-help] repeating tests,no free memory


Uhm..on my micaz motes, in the bottom side, it is written 1.5 V batteries.
So i think more than 3V is not possible..May be do i need any special kind
of battery or something else to source on my micaz?
i have not knowledge on the batteries to use on motes..
However thanks very much for your help, it is really important for my group,
cheers
Daniele 

        -----Original Message----- 
        From: David Moss [mailto:[EMAIL PROTECTED] 
        Sent: Tue 9/19/2006 1:07 AM 
        To: Munaretto, Daniel; [email protected] 
        Cc: 
        Subject: RE: [Tinyos-help] repeating tests,no free memory
        
        

        Ah, yes - 1.3V is a definit problem.  You need to be able to source
2.7 
        volts minimum, with 75+ mA.  I recommend going above 2.7 volts to
about 
        3.3-3.6 volts just to allow for some voltage sag.  The crash happens
so fast 
        (1 ms) that you can't even detect what's going on. 




        -----Original Message----- 
        From: Munaretto, Daniel [mailto:[EMAIL PROTECTED] 
        Sent: Monday, September 18, 2006 8:52 AM 
        To: David Moss; [email protected] 
        Subject: RE: [Tinyos-help] repeating tests,no free memory 


        I'm using not so much RAM, at compile time is around 1700 bytes (it
depends 
        on the different versions of my program). 
        But now, after other tests, i see that when the motes enter in the 
        reading-from-flash phase, something happens and some of them break
down. 
        They are not more able to work.And only after a reading phase. 
        May be the batteries? i know about the 70mA of current, but if i use

        rechangeable batteries, so 1.3 V, are there problems?i can measure
only 
        voltage by a voltmetre. 
        I really don't know how to understand what's going on in the reading
phase 
        to let some motes to break down in this way. 
        One problem may be is about the parameters i need when the reading
phase is 
        done: i need the same parameters i use when i posted the task.So the
global 
        parameters buf_flash,State,mess,flashAddr, 
        flashLen,flashBuffer are probably different when the readDone event
fires up 
        from the ones used posting the task.But only when the reading is
done i can 
        use that buffer and so i can execute my program..so for example
sending 
        packets,math operations,etc.. 
        Buffer *flashBuffer,*buffer,*ibuf,*ibuff; 

        Buf_flash *Head,*buf_flash; 

        Datagram *mess,*datagram; 

        uint8_t State; 

        

        task void readFlash(){ 

        if (!call FlashBridge.read(flashAddr,flashBuffer,flashLen)){ 

                  post readFlash();} 

        return; 

        } 

        void readInToFlash(uint8_t s,Buf_flash *buf,Datagram *message,Buffer

        *buffer_r,uint32_t addr, uint32_t len){ 

                           buf_flash=buf; 

                           State=s; 

                          mess=message; 

                         flashAddr=addr; 

                        flashLen=len; 

                       flashBuffer=buffer_r; 

                       post readFlash(); 

        return; 

        } 

        event void FlashBridge.readDone(uint32_t addr, void *buf, uint32_t
len, 
        result_t result){ 

                            if (result){ 

        //operations where i need to use the same global variables declared
in the 
        task!for now i'm using normally mess,State,etc..but i think are
different 
        from the same one before posting the task. 

        //for example if i use 

        //if(mess->data==...)..... 

        //i think it is not the same "mess" written before "post
readFlash()"... 

                       else 

                               post readFlash(); 

                     return; 

        } 

                -----Original Message----- 
                From: David Moss [mailto:[EMAIL PROTECTED] 
                Sent: Fri 9/15/2006 6:27 PM 
                To: Munaretto, Daniel; [email protected] 
                Cc: 
                Subject: RE: [Tinyos-help] repeating tests,no free memory 
                
                

                How much RAM is your program consuming at compile time?  The
MicaZ 
        is 
                notorious for running out of RAM just when you need it
because it 
        only has 
                4kB. If your global memory usage is already quite a bit (3kB
maybe? 
        maybe 
                more? maybe less?) and you throw a bunch of stuff on the
stack, your 
        mote 
                will crash in a seemingly random fashion, depending on
what's going 
        on. 

                I've had apps before that used around 3kB of RAM when the
program is 

                compiled, and then crashed awhile later because the stack 
        overflowed.  

                If the task queue is full (and it's in global memory btw, so
simply 
        posting 
                tasks shouldn't cause a stack overflow) then when you post a
task, 
        the post 
                will return FAIL. It could also be that your app is posting
a task 
        and 
                expecting it to run before continuing on, and that task
never 
        actually got 
                posted.  I've personally never had that problem before, even
with 
        running a 
                full file system on top of flash bridge with the radio
transmitting 
        and 
                receiving. 






                -----Original Message----- 
                From: Munaretto, Daniel
[mailto:[EMAIL PROTECTED] 
                Sent: Friday, September 15, 2006 9:02 AM 
                To: David Moss; [email protected] 
                Subject: RE: [Tinyos-help] repeating tests,no free memory 


                Dear all, 
                    i tried to use TinyAlloc interface but the results are
really 
        similar. 
                So this is not a problem of the calloc function. 
                But i start thinking the problem is in the stack. If i post
too many 
        tasks, 
                can the mote crash? 
                The problem is that i have to use tasks to handle the
FlashBridge 
        interface 
                in order to use properly the reading and writing phase on
Flash-RAM. 
        And i'm 
                also using a task for the sending interface (own mote
messages) and 
        for the 
                forwarding one (messages from other motes), all synchronized
by 
        timers. 
                So if i use micaz motes, tinyos-1.x, can it be a problem? 
                  
                Because i'm freeing all the times the memory i allocate, but
if i 
        repeat the 
                experiments with the motes on, in the second round or in the
third 
        one, one 
                (or more)of these breaks down. It seems quite randomly. 
                  
                Hoping in any kind of help, 
                cheers 
                Daniele 
                  
                  

                        -----Original Message----- 
                        From: David Moss [mailto:[EMAIL PROTECTED] 
                        Sent: Mon 9/11/2006 7:56 PM 
                        To: Munaretto, Daniel;
[email protected] 
                        Cc: 
                        Subject: RE: [Tinyos-help] repeating tests,no free
memory 
                        
                        

                        Daniele, 

                        This was one thing I noticed about the code I looked
at but 
        failed 
                to warn 
                        against, because I didn't know any better until I
read up on 
        it 
                afterwards. 

                        Below are a few emails from this list that may point
you in 
        the 
                right 
                        direction. 

                        -David 

                        
                
        
https://mail.millennium.berkeley.edu/pipermail/tinyos-help/2005-February/007



                        712.html : 

                        "The TinyOS programming methodology frowns on
malloc, for 
        several 
                        reasons: 

                        1) No memory protection so you can smash your stack 
                        2) Unforeseen rate mismatches can cause you to do 1
(you 
        start 
                        receiving packets faster than you can forward them) 
                        3) Event-driven execution models can make free()ing
a hard 
        thing to 
                do 
                        right (hence pool allocations, etc.) 

                        If you want dynamic allocation, look at TinyAlloc
(which Joe 

                        mentioned). It allows you to allocate a static chunk
of RAM 
        which 
                you 
                        then parcel out dynamically. But using it in the
presence of 

                        conflicting components is a recipe for disaster.
Systems 
        such as 
                TinyDB 
                        get away with it because all their parts are
designed to 
        work 
                together. 

                        Phil" 



                        "Hi all, 

                              Refer to the paper "The NesC Language: A
Holistic 
        Approach to 
                        Networked Embedded Systems", dynamic memory
allocation and 
        function 
                        pointers are prohibited in NesC language. For
dynamic memory 

                        allocation, it's quite clear to me why we can't use
it in 
        TinyOS as 
                        refered to 
                        
                
        
https://mail.millennium.berkeley.edu/pipermail/tinyos-help/2005-February/007



                        712.html 
                        . We can use TinyAlloc or MemAlloc instead of
directly 
        calling 
                        malloc() and so on. But for function pointers, it's
not 
        clear to me 
                        that we can or can't use it in TinyOS. What would be
the 
        problems if 
                I 
                        use that?" 




                        "Short answer: it leads to more reliable code. 

                        Long answer: 

                        Here's a pointer (haha!): 

                        
                
        
http://mail.millennium.berkeley.edu/pipermail/tinyos-help/2005-February/0077



                        12.html 

                        There's a difference between malloc() and dynamic 
        allocation. nesC  
                        does not forbid dynamic memory allocation: there's
nothing 
        stopping 

                        you from writing a component that allocates a pool
of memory 
        and has 

                        dynamic allocation interfaces. Take a look at
TinyAlloc, for 

                example. 

                        nesC does, however, frown on malloc, for the reasons

        described in 
                the  
                        above mail. Modern coding styles generally assume
unbounded 
        memory, 

                        in as much that you have swap space so will see
tremendous  
                        performance degradation before the system crashes.
General  
                        application behavior on allocation failure is to
exit(2) and 

                        therefore deallocate everything. With a processes, 
        multitasking, and 

                        automatic page reclamation, this works fine. But on
an 
        embedded  
                        system with no memory protection, well, it's not so
clean. 

                        Part of the issue is that while dynamic allocation
among a 
        set of  
                        cooperating components can work fine (e.g., TinyDB,
Ben 
        Greenstein  
                        @UCLA's work on signal processing), dynamic
allocation 
        between  
                        arbitrary components (a single shared pool) is a
recipe for 
                disaster.  
                        One bad component can bring the entire system down,
as the 
        shared  
                        resource breaks inter-component isolation. 

                        The reason why nesC frowns on function pointers is
because 
        they are 

                        dangerous and except for a few edge cases (e.g.,
dynamically 
        linking 

                        new binary modules), unnecessary. You know the call
graph at 

                compile- 
                        time. Instead of storing a function pointer in
memory, which 
        could 
                be  
                        corrupted and lead you to jump to certain doom, you
can just 
        use a  
                        parameterized interface and call based on a function
ID. 
        This also  
                        gives you type checking for the functions It is more
robust, 
        just as 

                        easy (once you get used to it), and generally uses
less RAM 
        (no need 

                        to store the pointer). Function pointers are a basic
result 
        of C's  
                        linking model. nesC's linking model does not have
the same  
                        complications (interfaces are bidirectional), so you
can 
        avoid them. 


                        Phil" 

                        -----Original Message----- 
                        From: [EMAIL PROTECTED] 
                        [mailto:[EMAIL PROTECTED]
On 
        Behalf Of 
                Munaretto, 
                        Daniel 
                        Sent: Monday, September 11, 2006 1:51 AM 
                        To: [email protected] 
                        Subject: [Tinyos-help] repeating tests,no free
memory 


                        Dear all, 
                               i discover a really strange behavior in my 
        application. 
                        I repeat more times my code, and after some
experiments the 
        motes 
                break 
                        down. 
                        So there is a memory problem. 
                        But i'm sure i free all the memory i allocate during
the 
        code. I'm 
                using 
                        only a buffer and i re-use it all the times, instead
i 
        allocate 
                memory with 
                        "calloc()" only for creating a chain which i delete
at the 
        end of 
                each 
                        simulation with the "free" command and then i give
"NULL" to 
        the 
                pointers. 
                        So i don't understand where i lose memory each time
i re-run 
        the 
                program 
                        (without re-booting the motes). i'm in tinyos
1.1.15,micaz 
        motes. 
                        I'm using the FlashBridge interface because i'm
working on 
        the 
                flash. 
                        I'm supposing that, may be, the problem is in the
way Tinyos 
        handles 
                the 
                        packets received. For example, in the function
"event 
        TOS_MsgPtr 
                        Receive.receive(TOS_MsgPtr m)", before returning m,
do i 
        have to 
                free it?But 
                        i can see it's wrong to do.. 
                          
                        Please, if anyone knows where i have to find the
waste of 
        memory 
                (may be 
                        some interfaces)...any helps will be really
appreciated 
                        thanks very much 
                        cheers 
                        Daniele 

                        _______________________________________________ 
                        Tinyos-help mailing list 
                        [email protected] 
                        
                
        
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help 





_______________________________________________
Tinyos-help mailing list
[email protected]
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Reply via email to