MC13213 (HCS08) Memory leaks: some doubts about 802.15.4 library

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

MC13213 (HCS08) Memory leaks: some doubts about 802.15.4 library

1,396 Views
UC3MZigbeeGroup
Contributor I

Hi,

we are developing an application based on MyWirelessApplication and we employ the 802.15.4 Freescale library. We have some questions about this library and we are, unfortunately, stuck. Thus, we would appreciate much help.

Our main problem is that we have memory “leaks”. Messages accumulate in the MAC layer “big data messages” buffer. We believe that, sometimes, those messages are not removed from the buffer, thus this buffer is completely filled up and the device is no longer able to allocate a message is this buffer to send it. We stress that, each time our application receives a message from this buffer, it releases it.

Some specific doubts:

1) Firstly, do the following statements hold true?

-The maximum “big data messages” in the MAC layer buffer is  the value of "gTotalBigMsgs_d" macro. This value includes, when the device is a FFD, the messages in the MAC “private” buffer.

-The same MAC “big data messages” buffer is used both for incoming and outgoing messages.


2) Sometimes we send a message from the application layer to the MAC layer and the MAC layer can not send it after the maximum tries (CsmaBackoffs) because the transmission channel was always busy. What happens with this message? Is it removed from the data-message buffer or does it remain in this buffer?

Sometimes, the message is successfully sent but the ACK is not received. In this case is it removed from the data-message buffer or does it remain in this buffer?


3) When we receive (via the radio interface) a message, this message is stored in the MAC layer data-message buffer. Then, by calling MSG_Queue() –inside MCPS_NWK_SapHandler() -, this messages is queued in an application layer queue. ¿is a copy of the message handled to the application level or just a pointer to the message stored in the MAC layer data-message buffer?


4) Another question we have is what happens if the MAC layer receives two messages at the same time:
they are queued in application layer queue ( MCPS_NWK_SapHandler() )
and a evtMessageFromMCPS event is sent twice.
The evtMessageFromMCPS events are considered as one event or as two?
The evtMessageFromMCPS event is “coded” 1000  (in binary). When we “OR” it twice to the events mask, this mask does not change the second time we do the OR operation. So we think the two evtMessageFromMCPS  events are “assimilated” to just one.

 
5) We did implement a function, following your suggestions, to calculate the
number of packets in the MAC layer data-message buffer. As Freescale support suggested us, we try to fill this buffer until reaching its maximum capacity. Since we know the maximum buffer size (4 in our case), doing so we can deduce the number of packets allocated in the buffer
. There is, however, an awkward result: Just at the beginning of our application, we send a message. Then, we calculate the number of messages in the MAC layer following the above method. The result we have is two (instead of 1).  For the rest of messages sent, the result we have is correct. We don´t know the reason of this.

 Thanks in advance for your help.

 

 

Labels (1)
0 Kudos
Reply
1 Reply

393 Views
todorstz
Contributor I

 

Hi, we have the same problem with our router. We increase Big msg from 5 to 7 buffers but that not resolve our problem. We observe the  MM_DebugNumFreeBigBuffers and when its equal to 0 our device just hang. After 10 seconds some of the buffers are discharged  but device stop communication in the network. We allow MsgTracking module and in debug mode we saw that the msg buffers (big ones) are used by some MAC lib function where we doesn't have permission. We mainly use Beestack version 1.0.5. We upgrade our application to ver. 2.0.0 but there isn't some debug functions and modules like MsgTracking?! We are so confused??? Let's resolve this problem together or make some suggestions :smileyhappy:    

 

 

 

 

0 Kudos
Reply