[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
RE: [Tinyos-help] repeating tests,no free memory
Hi David, i would like to ask you a question: do you know if the way FlashBridge gets access to the flash, is controlled by SPI interface or UART1 interface (ATmega128)? because normally the external flash is controlled by UART1 interface of the ATmega128 processor (in this case there are not bus conflicts between flash and radio) and the radio in micaZ is controlled by SPI interface. thanks for your help, cheers Daniele ___ Tinyos-help mailing list Tinyos-help@Millennium.Berkeley.EDU https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
RE: [Tinyos-help] repeating tests,no free memory
I think you're right - the flash is controlled by the UART not the SPI. So I'm not sure why it crashes on the micaz sometimes. I have gotten packets to come in over the radio and write to flash, and data from flash to go over the radio just fine on micaz's. Sounds like there's some other software issue going on here. -Original Message- From: Munaretto, Daniel [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 04, 2006 3:14 AM To: David Moss Cc: tinyos-help@Millennium.Berkeley.EDU Subject: RE: [Tinyos-help] repeating tests,no free memory Hi David, i would like to ask you a question: do you know if the way FlashBridge gets access to the flash, is controlled by SPI interface or UART1 interface (ATmega128)? because normally the external flash is controlled by UART1 interface of the ATmega128 processor (in this case there are not bus conflicts between flash and radio) and the radio in micaZ is controlled by SPI interface. thanks for your help, cheers Daniele ___ Tinyos-help mailing list Tinyos-help@Millennium.Berkeley.EDU https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] repeating tests,no free memory
Isn't SPI implemented with USART1? Or was I out behind the barn when they passed out? MS David Moss wrote: I think you're right - the flash is controlled by the UART not the SPI. So I'm not sure why it crashes on the micaz sometimes. I have gotten packets to come in over the radio and write to flash, and data from flash to go over the radio just fine on micaz's. Sounds like there's some other software issue going on here. -Original Message- From: Munaretto, Daniel [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 04, 2006 3:14 AM To: David Moss Cc: tinyos-help@Millennium.Berkeley.EDU Subject: RE: [Tinyos-help] repeating tests,no free memory Hi David, i would like to ask you a question: do you know if the way FlashBridge gets access to the flash, is controlled by SPI interface or UART1 interface (ATmega128)? because normally the external flash is controlled by UART1 interface of the ATmega128 processor (in this case there are not bus conflicts between flash and radio) and the radio in micaZ is controlled by SPI interface. thanks for your help, 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
RE: [Tinyos-help] repeating tests,no free memory
I'm not sure what's going on here with the micaz schematics or how it's implemented in software. I know on the mica2 schematics, the flash is controlled by USART1 and the CC1000 is controlled by the SPI_xyz lines: http://www.tinyos.net/hardware/design/ORCAD_FILES/MICA2/6310-0306-01ACLEAN.p df I assume the micaz is the same way - using PortB's SPI lines to control the radio and PortD's USART1 to control the flash. If that's the case, then they are two different ports and there shouldn't be a conflict with using the flash and the radio at the same time. Unless, of course, there's some low level component that enjoys starting conflicts between the two. Which - this is TinyOS 1.x remember - could be a plausible excuse. -Original Message- From: Michael Schippling [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 04, 2006 9:52 AM To: David Moss Cc: 'Munaretto, Daniel'; tinyos-help@Millennium.Berkeley.EDU Subject: Re: [Tinyos-help] repeating tests,no free memory Isn't SPI implemented with USART1? Or was I out behind the barn when they passed out? MS David Moss wrote: > I think you're right - the flash is controlled by the UART not the SPI. So > I'm not sure why it crashes on the micaz sometimes. I have gotten packets > to come in over the radio and write to flash, and data from flash to go over > the radio just fine on micaz's. Sounds like there's some other software > issue going on here. > > > -Original Message- > From: Munaretto, Daniel [mailto:[EMAIL PROTECTED] > Sent: Wednesday, October 04, 2006 3:14 AM > To: David Moss > Cc: tinyos-help@Millennium.Berkeley.EDU > Subject: RE: [Tinyos-help] repeating tests,no free memory > > > Hi David, > i would like to ask you a question: do you know if the way FlashBridge > gets access to the flash, is controlled by SPI interface or UART1 interface > (ATmega128)? > because normally the external flash is controlled by UART1 interface of the > ATmega128 processor (in this case there are not bus conflicts between flash > and radio) and the radio in micaZ is controlled by SPI interface. > > thanks for your help, > 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
RE: [Tinyos-help] repeating tests,no free memory
I'll second this, no problems with just UART1 and radio. I'd still like to have some arbitration between the UART1 and Flash components (this could remedy the problem you're observing, too). I've made a Bluetooth module which communicates through UART1, and if I try to use the flash simultaneously, there's definitely a conflict. I haven't had enough time to figure out how this could be sorted. Without that, UART1 won't work with flash. Harri -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Moss Sent: Wednesday, October 04, 2006 8:02 PM To: 'Michael Schippling' Cc: tinyos-help@Millennium.Berkeley.EDU Subject: RE: [Tinyos-help] repeating tests,no free memory I'm not sure what's going on here with the micaz schematics or how it's implemented in software. I know on the mica2 schematics, the flash is controlled by USART1 and the CC1000 is controlled by the SPI_xyz lines: http://www.tinyos.net/hardware/design/ORCAD_FILES/MICA2/6310-0306-01ACLE AN.p df I assume the micaz is the same way - using PortB's SPI lines to control the radio and PortD's USART1 to control the flash. If that's the case, then they are two different ports and there shouldn't be a conflict with using the flash and the radio at the same time. Unless, of course, there's some low level component that enjoys starting conflicts between the two. Which - this is TinyOS 1.x remember - could be a plausible excuse. -Original Message- From: Michael Schippling [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 04, 2006 9:52 AM To: David Moss Cc: 'Munaretto, Daniel'; tinyos-help@Millennium.Berkeley.EDU Subject: Re: [Tinyos-help] repeating tests,no free memory Isn't SPI implemented with USART1? Or was I out behind the barn when they passed out? MS David Moss wrote: > I think you're right - the flash is controlled by the UART not the SPI. So > I'm not sure why it crashes on the micaz sometimes. I have gotten packets > to come in over the radio and write to flash, and data from flash to go over > the radio just fine on micaz's. Sounds like there's some other software > issue going on here. > > > -Original Message- > From: Munaretto, Daniel [mailto:[EMAIL PROTECTED] > Sent: Wednesday, October 04, 2006 3:14 AM > To: David Moss > Cc: tinyos-help@Millennium.Berkeley.EDU > Subject: RE: [Tinyos-help] repeating tests,no free memory > > > Hi David, > i would like to ask you a question: do you know if the way FlashBridge > gets access to the flash, is controlled by SPI interface or UART1 interface > (ATmega128)? > because normally the external flash is controlled by UART1 interface of the > ATmega128 processor (in this case there are not bus conflicts between flash > and radio) and the radio in micaZ is controlled by SPI interface. > > thanks for your help, > cheers > Daniele > > > ___ > Tinyos-help mailing list > Tinyos-help@Millennium.Berkeley.EDU > https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-hel p ___ Tinyos-help mailing list Tinyos-help@Millennium.Berkeley.EDU https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-hel p ___ Tinyos-help mailing list Tinyos-help@Millennium.Berkeley.EDU https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] repeating tests,no free memory
You need to return the same pointer that you get in receive(TOS_MsgPtr m), the system will recycle it. There isn't any way for you to free it yourself. Perhaps you can run your program under TOSSIM or something so your can trace memory usage to see if you've really got a leak. Otherwise you could have a runaway pointer or something that wouldn't crash immediately... MS Munaretto, Daniel wrote: 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
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 "eve
RE: [Tinyos-help] repeating tests,no free memory
And you shouldn't have to free anything in TinyOS. The message you received was not dynamically allocated. Just use its pointer in the receive event, return it, and forget it. -David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Moss Sent: Monday, September 11, 2006 10:56 AM To: 'Munaretto, Daniel'; tinyos-help@Millennium.Berkeley.EDU 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 o
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 s
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
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
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; 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
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; tinyos-help@Millennium.Berkeley.EDU
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; 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.
RE: [Tinyos-help] repeating tests,no free memory
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; tinyos-help@Millennium.Berkeley.EDU
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; tinyos-help@Millennium.Berkeley.EDU
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; 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
RE: [Tinyos-help] repeating tests,no free memory
Are you accessing the Flash memory while using the radio? I believe I ran
into some serious issues doing this with the MicaZ. The problem, I believe,
is in the bus arbitration - because both the flash and the radio use the
same SPI bus lines, if you're actively using flash and radio together on a
micaz, the mote crashes.
This doesn't happen with telos motes.
I am about to start testing TinyOS 2.x to see if it still has this problem.
I believe it shouldn't and doesn't because it has a better bus resource
arbitration story. i.e. the radio has to request access to the bus before
using it, and the flash has to request access before using it, etc.
-David
-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 funct
Re: [Tinyos-help] repeating tests,no free memory
On Sep 19, 2006, at 3:17 PM, David Moss wrote: Are you accessing the Flash memory while using the radio? I believe I ran into some serious issues doing this with the MicaZ. The problem, I believe, is in the bus arbitration - because both the flash and the radio use the same SPI bus lines, if you're actively using flash and radio together on a micaz, the mote crashes. That's interesting; I believe that the flash and CC2420 do not share an SPI bus on the mica platforms. This doesn't happen with telos motes. I am about to start testing TinyOS 2.x to see if it still has this problem. I believe it shouldn't and doesn't because it has a better bus resource arbitration story. i.e. the radio has to request access to the bus before using it, and the flash has to request access before using it, etc. Yes, this has been a major focus for 2.x. The bus on the Telos platform is heavily overloaded (SPI to radio, SPI to flash, I2C for sensors, UART, etc.) and so requires a lot of effort to abstract properly in a way that's flexible and robust. It turns out that this actually simplifies code in a lot of other ways, though. For example, the radio stack actually has the receive and transmit paths be separate users of the bus, which individually arbitrate for it. Phil ___ Tinyos-help mailing list Tinyos-help@Millennium.Berkeley.EDU https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
RE: [Tinyos-help] repeating tests,no free memory
Well, i'm thinking about..when i tested the FlashBridge interface, i used a
mote connected to the programming board, and everything was perfect. And
without using the radio, so without send/receive interfaces. i only worked on
reading and writing some bytes in flash.Now there are problems with motes, and
i'm using batteries of 1.5 V, so 3V. So may be there is a conflict between
flash and radio.I will check by tests.
By the way, why does this kind of problem rise up only when i read from flash
and not also in the writing phase?It doesn't agree with the explanation of the
bus usage, right?
Daniele
-Original Message-
From: Philip Levis [mailto:[EMAIL PROTECTED]
Sent: Wed 9/20/2006 2:54 AM
To: David Moss
Cc: Munaretto, Daniel; tinyos-help@Millennium.Berkeley.EDU
Subject: Re: [Tinyos-help] repeating tests,no free memory
On Sep 19, 2006, at 3:17 PM, David Moss wrote:
> Are you accessing the Flash memory while using the radio? I
> believe I ran
> into some serious issues doing this with the MicaZ. The problem, I
> believe,
> is in the bus arbitration - because both the flash and the radio
> use the
> same SPI bus lines, if you're actively using flash and radio
> together on a
> micaz, the mote crashes.
>
That's interesting; I believe that the flash and CC2420 do not share
an SPI bus on the mica platforms.
> This doesn't happen with telos motes.
>
> I am about to start testing TinyOS 2.x to see if it still has this
> problem.
> I believe it shouldn't and doesn't because it has a better bus
> resource
> arbitration story. i.e. the radio has to request access to the bus
> before
> using it, and the flash has to request access before using it, etc.
Yes, this has been a major focus for 2.x. The bus on the Telos
platform is heavily overloaded (SPI to radio, SPI to flash, I2C for
sensors, UART, etc.) and so requires a lot of effort to abstract
properly in a way that's flexible and robust.
It turns out that this actually simplifies code in a lot of other
ways, though. For example, the radio stack actually has the receive
and transmit paths be separate users of the bus, which individually
arbitrate for it.
Phil
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
RE: [Tinyos-help] repeating tests,no free memory
Ya, that is interesting. I didn't look at the schematics - I just assumed
they were on the same bus. I can access the radio fine and the flash fine
seperately, but sometimes accessing both has crashed the mote for me in the
past.
And as far as reading vs. writing, I think it would depend on when the
actual read and write is performed in relation to using the radio.
I have meetings all day today, but I'd like to look into this further when I
have some time. The FlashBridge component, by the way, sits on top of
PageEEPROM for the mica platforms in TinyOS 1.x.
-David
-Original Message-
From: Munaretto, Daniel [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 20, 2006 1:38 AM
To: Philip Levis; David Moss
Cc: tinyos-help@Millennium.Berkeley.EDU
Subject: RE: [Tinyos-help] repeating tests,no free memory
Well, i'm thinking about..when i tested the FlashBridge interface, i used a
mote connected to the programming board, and everything was perfect. And
without using the radio, so without send/receive interfaces. i only worked
on reading and writing some bytes in flash.Now there are problems with
motes, and i'm using batteries of 1.5 V, so 3V. So may be there is a
conflict between flash and radio.I will check by tests.
By the way, why does this kind of problem rise up only when i read from
flash and not also in the writing phase?It doesn't agree with the
explanation of the bus usage, right?
Daniele
-Original Message-
From: Philip Levis [mailto:[EMAIL PROTECTED]
Sent: Wed 9/20/2006 2:54 AM
To: David Moss
Cc: Munaretto, Daniel; tinyos-help@Millennium.Berkeley.EDU
Subject: Re: [Tinyos-help] repeating tests,no free memory
On Sep 19, 2006, at 3:17 PM, David Moss wrote:
> Are you accessing the Flash memory while using the radio? I
> believe I ran
> into some serious issues doing this with the MicaZ. The problem, I
> believe,
> is in the bus arbitration - because both the flash and the radio
> use the
> same SPI bus lines, if you're actively using flash and radio
> together on a
> micaz, the mote crashes.
>
That's interesting; I believe that the flash and CC2420 do not share
an SPI bus on the mica platforms.
> This doesn't happen with telos motes.
>
> I am about to start testing TinyOS 2.x to see if it still has this
> problem.
> I believe it shouldn't and doesn't because it has a better bus
> resource
> arbitration story. i.e. the radio has to request access to the
bus
> before
> using it, and the flash has to request access before using it,
etc.
Yes, this has been a major focus for 2.x. The bus on the Telos
platform is heavily overloaded (SPI to radio, SPI to flash, I2C for
sensors, UART, etc.) and so requires a lot of effort to abstract
properly in a way that's flexible and robust.
It turns out that this actually simplifies code in a lot of other
ways, though. For example, the radio stack actually has the receive
and transmit paths be separate users of the bus, which individually
arbitrate for it.
Phil
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
