Memeory leak in 802.15.4 MAC/PHY?

[Marc]

Hi,

We're using the Freescale 802.15.4 MAC/PHY for a USB to wireless bridge. This runs on our custom PCB built with the MC9S08GT60 IC.

Sometimes we hit a case where no new message can be allocated from the MAC private pool. Ie. MSG_Alloc((sizeof(nwkToMcpsMessage_t) - 1 )+ 102) always returns NULL. Even if we call Mlme_Main repeatedly between attempts to allocate the message, the allocation still fails. This basically stalls the library completely.

We've checked and double checked that all mlme, asp and mcps message we receive are freed.

Any ideas why this is hapenning? Is there a way to manually reinitialize the entire private pool?

Thanks
Marc

[Marc]

No, we are not using the SMAC. We're using the full 802.15.4 MAC/PHY library from freescale.

Thanks
Marc

[steveh]

We are experiencing a similar problem.

We WERE using TPM2 interrupts at a high rate. We found that by not using TPM2 in interrupt mode, and just by polling TOF instead, the problem disappeared.

This was after exhaustively checking every allocation and freeing of MAC memory and not being able to fault our memory management. We made no changes to our memory management, yet the problem went away after we stopping using TPM2 interrupts.

In the 802.15.4 MAC/PHY reference manual, under Parametric Information, they say that you cannot disable interrupts for more than 10µs per 64µs. We tested the duration of our interrupt routine (during which interrupts are disabled), and it was 6µs; and the time between interrupts is about 50 ms, which is OK according to the Parametric Information.

So we are still at a loss as to what's going wrong, and any information from somebody to whom this sounds familiar would be appreciated.

[Marc]

We now tried using our own private application memory pool with enough space for one transmission buffer (134 bytes). We exclusively use this buffer when we send packets through the MAC and we only send one at a time. Still, we this private pool runs out of memory (get null on the allocation).

This would indicate that the transmitted message is not freed correctly by the MAC upon transmission!

We tried to reinitialize the private application pool when we run out using MM_init, but this does not seem to solve the problem.

Any ideas?

Thanks
Marc

[alex_spotw]

Hi:

Are you using the SMAC code?

That code has reentrant interrupts to handle the TX/RX messages, and it probable leads to corruption of your pointers to buffers when a RX packed as not completely process, before another packet arrives.

Please check your ISR's

Regards,

Alex