topic ZigBee Buffer Overflow (MC13234/MC13237 IEEE 802.15.4 Transceiver) in Wireless MCU

ZigBee Buffer Overflow (MC13234/MC13237 IEEE 802.15.4 Transceiver)

barakmanos — Sun, 08 Nov 2015 12:09:26 GMT

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:

Data	Meaning
28 01 0F 7E FF	SMAC stuff
5A 5A	Application payload
51 CB	Application payload
AD	Application payload
07	Application payload
04	Application payload
03	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.

Re: ZigBee Buffer Overflow (MC13234/MC13237 IEEE 802.15.4 Transceiver)

EarlOrlando — Mon, 16 Nov 2015 17:47:51 GMT

Dear Barak,

Is it possible that you share your code to recreate the problem by myself?

I will be looking forward for your response.

Best regards,

Earl.

Re: ZigBee Buffer Overflow (MC13234/MC13237 IEEE 802.15.4 Transceiver)

barakmanos — Thu, 19 Nov 2015 17:20:29 GMT

Hi Earl.

It is rather impossible to construct a self-contained, minimal, complete and verifiable example, with which you can reproduce the problem.

I would need to provide more or less the entire application (two applications as a matter of fact, for each side of the communication channel).

For now, I would be happy if you could shed some light as to why the PHY sometimes fills up the (130-byte) buffer.

To be more accurate, I have noticed that once I enable RX, data is immediately written into that buffer (even when no data has been transmitted).

Here is the stack-trace, starting from Freescale's driver routine:

- MLMERXEnableRequest

- PhyPlmeRxRequest:

// start the RX sequence

PP_PHY_CTL1 |= gRX_c;

As soon as the PP_PHY_CTL1 register is updated, I see 130 bytes of data written into the RX buffer.

Now, although there is no harm in this operation, I believe that it might give us a good lead as to when and why data is written into the RX buffer.

In any case, here is our initial PHY set up (the same on both sides):

Thank you very much for your help.

Re: ZigBee Buffer Overflow (MC13234/MC13237 IEEE 802.15.4 Transceiver)

barakmanos — Tue, 24 Nov 2015 12:45:39 GMT

Problem solved!!!

I’ve been investigating a bug where the PHY writes more than 130 bytes of data into the 130-byte long RX-buffer.

This, of course, causes memory override which in turn yields undefined behavior (in the good scenario, we get a WD-reset).

Increasing the size of the RX buffer did not seem to help.

The reason why I have chosen its size to be 130 is that we have the following definitions in the code:

#define gMaxSmacSDULenght_c (123)

#define gMaxPromiscuousSmacSDULenght_c (125)

This made me wrongly assume that the buffer size should be SMAC header (5) + gMaxPromiscuousSmacSDULenght_c (125).

Now I finally understand why we continue to receive those 130 bytes:

The MAX_FRAME_LENGTH register is set to 127
The largest amount of data that the PHY accepts is MAX_FRAME_LENGTH + 3

As soon as I reduce that MAX_FRAME_LENGTH to some N < 127, everything works perfectly.

And yes – it works perfectly even if I reduce the size of the RX buffer, just as long as it is at least MAX_FRAME_LENGTH + 3 byte long.

So the only question remaining is – why did we receive more than 130 bytes of data, with MAX_FRAME_LENGTH = 127 and RX buffer size = 130.

I suspect that the answer to that is the definition gMaxSmacSDULenght_c (123), which implies that we cannot have MAX_FRAME_LENGTH above 123 (or 120).

Re: ZigBee Buffer Overflow (MC13234/MC13237 IEEE 802.15.4 Transceiver)

barakmanos — Sun, 29 Nov 2015 20:51:41 GMT

SIDE NOTE:

I have found out that his problem can be easily reproduced through Freescale's BeeKit Wireless Connectivity Toolkit:

1. Create a connectivity test for MC13233.

2. Set up a system of two MC13233 standard evaluation boards.

3. Connect each board to your PC through serial (RS232) cable.

4. Open two terminals (e.g. TeraTerm) and connect to each COM.

5. Run each one of the MCUs.

6. Terminal #1 (RX):

- Press enter to start

- Press [1] Continuous tests

- Press [5] Continuous Reception

7. Terminal #2 (TX):

- Press enter to start

- Press [1] Continuous tests

- Press [2] Continuous PRBS Transmission

The problem should eventually occur (might take a while).

If I may add a personal opinion, then it is rather disappointing that such an outright straightforward bug has not been reported or documented anywhere.

It most likely indicates that no MCU1323x-based networks have ever been deployed, hence due to the lack of demand, the manufacturer has never bothered to fix it or to publish an errata.

Re: ZigBee Buffer Overflow (MC13234/MC13237 IEEE 802.15.4 Transceiver)

EarlOrlando — Mon, 30 Nov 2015 22:15:14 GMT

Hello Barak,

Thank you for your comments and for share your tests. I reproduced the issue and indeed it is there. I will share this with the software team so the will be able to take a look into it. However, SMAC is basically a stack used to test a MCU and it is not recommended to enable a full network, that's why issues like this can exist.

If you want to build a more robust network you should use the MAC codebase.

Best regards,

Earl.

Re: ZigBee Buffer Overflow (MC13234/MC13237 IEEE 802.15.4 Transceiver)

barakmanos — Wed, 20 Jan 2016 16:42:55 GMT

Hello Earl.

Thank you for confirming my observation.

We have not encountered any other issues when using SMAC over the IEEE 802.15.4 Transceiver on MC1323x, so we feel pretty convenient staying with the current driver.

However, under some scenarios, we are experiencing major packet-loss, which we believe to be the result of RF interference.

Switching between the 16 channels (from 2405MHz to 2480MHz), shows little improvement at times, but it doesn't go as far as resolving the problem.

So the question is whether or not using the MAC codebase (as you've suggested) could help us out here.

Would you know if there is any advantage in using this package in the context of RF interference?

For example, does it "slice" each packet into smaller segments before transmitting it (assuming that shorter bursts are less likely to be interfered)?

Thanks again for your help :smileyhappy:

Re: ZigBee Buffer Overflow (MC13234/MC13237 IEEE 802.15.4 Transceiver)

EarlOrlando — Wed, 20 Jan 2016 18:37:24 GMT

Hello Barak,

Since it depends on the PHY, MAC won't will improve the RF interference issues. However, using MAC instead of SMAC could has improvements because it has a better auto acknowledge mechanism. If you want to keep using SMAC, I recommend you to implement a Frame Check Sequence (FCS) in the application layer as an additional mechanism to re transmit the dropped packages.

Best regards,

Earl Ramírez.

Re: ZigBee Buffer Overflow (MC13234/MC13237 IEEE 802.15.4 Transceiver)

barakmanos — Thu, 01 Sep 2016 13:05:55 GMT

Hello Earl.

You have previously suggested:

SMAC is basically a stack used to test a MCU and it is not recommended to enable a full network, and that if I want to build a more robust network then I should use the MAC codebase.

Now, I would like to make use of the frame-filtering functionality that is supported in the MC1323x Transceiver.

More specifically, I would like to include the destination address in the transmitted packets, so that the received packets can be filtered (in or out) according to this address.

At present, we filter the every received packet at the application layer, i.e., we embed a 16-bit destination address within the transmitted packet payload, and check it upon reception.

This is not very efficient of course, as the application is "interrupted for nothing".

Looking into SMAC source code, I believe that the frame-filtering functionality is not supported.

So I would like to implement it myself (i.e., extend my SMAC code to support it).

However, the MC1323x data-sheet is rather obscure on how to do this?

Question 1:

Is it supported in what you have referred to as 'MAC codebase'?

Question 2:

I have posted here a more detailed description of my problems in understanding the MC1323x data-sheet with regards to the frame-filtering functionality. Would it be possible for to refer to this post?

Thanks again for your help :smileyhappy: