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.
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.
