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; tinyos-help@Millennium.Berkeley.EDU 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; tinyos-help@Millennium.Berkeley.EDU 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; tinyos-help@Millennium.Berkeley.EDU 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; tinyos-help@Millennium.Berkeley.EDU 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: tinyos-help@Millennium.Berkeley.EDU 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 Tinyos-help@Millennium.Berkeley.EDU https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help _______________________________________________ Tinyos-help mailing list Tinyos-help@Millennium.Berkeley.EDU https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
