AnsweredAssumed Answered

ZigBee Buffer Overflow (MC13234/MC13237 IEEE 802.15.4 Transceiver)

Question asked by Barak Manos on Nov 8, 2015
Latest reply on Sep 1, 2016 by Barak Manos

I am using the SMAC stack over MC13234/MC13237 IEEE 802.15.4 Transceiver.

I have the following preprocessor definition in the SMAC interface file:

#define gMaxPromiscuousSmacSDULenght_c (125)

I allocate a buffer of this size + 5 (i.e., 130 bytes) dedicated for RX, and I pass this buffer when calling function MLMERXEnableRequest.

I have witnessed some rare cases where the SMAC receives more than 130 bytes of data, thus overriding memory outside the designated RX buffer.

The only lead that I have found while investigating this, is that sometimes the PHY fill up the buffer with the received data PLUS some sort of repeating sequence, like 0x99 for example.

I'm not sure what could possibly be the reason for this “wasteful” operation, but I do know that when the override occurs, the repeating sequence goes outside the boundaries of the buffer.

Here is an example:




The RX buffer starts at the highlighted cell (with a value of 28), and ends at the last red cell (with a value of 99).

In this case, the PHY has written exactly 130 bytes into the buffer.

But in rare cases it exceeds that amount, thus causing memory override.

Parsing of the actual packet:




28 01 0F 7E FF

SMAC stuff

5A 5A

Application payload

51 CB

Application payload


Application payload


Application payload


Application payload


Application payload

00 00 00

Application payload

0F C2

Some more SMAC stuff (FCS, I suppose)


As you can see, it is followed by 5s and then by 9s, and in between some other (seemingly random) data.

BTW, it’s a different “magic value” every time, but always with two identical hex digits.

For now, I will be happy to understand why the PHY writes this extra data into the RX buffer.

I tried to put a “Memory Write” watch-point after the RX buffer, in order to catch the actual violation, but it didn’t seem to help catching this event.

I suppose, that it is either because the watch-point has had a crucial impact on timing, or the write-operation was performed via some other channel/bus/etc.

Any ideas will be highly appreciated.

Thank you very much for your help.