CC2652R: Beacon response disappear if 16 or more indirect pending messages are present

Hi Martin,

I'm sorry to hear that your issue is still not resolved.  Have you tried to increase the number of MAC_SRCMATCH entries in <sdk_directory>\source\ti\ti154stack\low_level\cc13xx\mac_autopend.h?  Meanwhile, I will alert the TI 15.4-Stack Software Developers about this behavior and gather their suggestions.

Regards,
Ryan

Hi Ryan,

Thank you for your reply. I have now tried to increase the MAC_SRCMATCH definitions:

MAC_SRCMATCH_SHORT_ENTRY_SIZE        4 -> 24
MAC_SRCMATCH_EXT_ENTRY_SIZE          8 -> 38
MAC_SRCMATCH_SHORT_MAX_NUM_ENTRIES   5 -> 25
MAC_SRCMATCH_EXT_MAX_NUM_ENTRIES     5 -> 25

Unfortunately without success, the problem remains the same with the breakpoint at 15 units.

Looking forward to the developers' suggestions. :)

Regards,
Martin

Feedback from the Software Team:

macCfg_t macCfg =
{
MAC_CFG_TX_DATA_MAX,
MAC_CFG_TX_MAX,
MAC_CFG_RX_MAX,
MAC_CFG_DATA_IND_OFFSET,
MAX_DEVICE_TABLE_ENTRIES,
MAX_KEY_DEVICE_TABLE_ENTRIES,
MAX_KEY_TABLE_ENTRIES,
MAX_NODE_KEY_ENTRIES,
MAX_KEY_ID_LOOKUP_ENTRIES,
MAC_CFG_APP_PENDING_QUEUE,
MAC_MAX_FRAME_SIZE
};
the MAC_CFG_TX_MAX controls how many packets in TX queue (both direct + indirected packet).
From customer configuration, MAC_CFG_TX_MAX 15 ===> that means the maximum number of TX packets is 15.
If customer wants to increase the indirect packets in queue, they can increase the MAC_CFG_TX_MAX to large value. This will require more RAM.

It sounds like you've already attempted something similar, so I will continue pushing them for more information.

Regards,
Ryan

Thanks Ryan.

Yes, I have to increased MAC_CFG_TX_MAX 15 to 255 without success.

Looking forward to their response.

Regards,

Martin

"I don't think users can set the MAC_CFG_TX_MAX to 255.  Can you ask them to check the return status of ApiMac_mcpsDataReq API? Most of likely, they will see no-resource code (0x1A) or transaction overflow (0xF1)."

My recommendation is to alter MAC_CFG_TX_MAX to a more reasonable value, such as 63 or 127.

Regards,
Ryan

Thank you for reply Ryan,

I have tried reducing the settings:

MAC_CFG_TX_DATA_MAX=63
MAC_CFG_TX_MAX=127
MAC_CFG_RX_MAX=128

Also down to

MAC_CFG_TX_DATA_MAX=16
MAC_CFG_TX_MAX=32
MAC_CFG_RX_MAX=4

The problem remains the same and the limit is still 15.

ApiMac_mcpsDataReq() returns 0x00 (ApiMac_status_success) every time I post to the indirect queue, even for the 16th packet.

Any more suggestions? Given that increasing the MAC_CFG settings require more RAM is there a memory allocation I need to increase to accommodate a larger queue?

Regards,

Martin

Hi Martin,

Thanks for the update.

I'm Ryan's colleague and will maintain his threads while he is out of office.

I'm now checking with the development team and will update you after I receive a response (or within 4 business days as a check-in).

Thanks,
Toby

Thanks Toby,

Looking forward to the response.

Regards,

Martin

Hi Toby,

I'm Martin's colleague and will take over while he's out of office.

Awaiting your reply.

Best regards,

Christian

Hi again,

We got some new input regarding this issue. We we're going to open up another issue, but Martin realized that they are probably connected.

Firstly, a correction regarding the premise of this thread. The beacon response do get sent, but it is corrupted, which leads us to believe it is connected to this other bug that we see.

There are 12 devices associated with the coordinator and one indirect pending message queued to each device. 
Under certain circumstances, currently unknown, and another device is sending out a beacon request, the beacon response is corrupted. 

Correct beacon response:

Corrupt beacon response:

The (correct) beacon payload is created in the application:

typedef struct Beacon_
{
    uint8_t pairing_and_version;
    uint32_t channel_mask;
    uint8_t security_mode;
} Beacon;
 
Beacon beacon =
{
    .pairing_and_version = 0,
    .channel_mask = 0,
    .security_mode = 0
};
 
static void updateBeacon( bool is_pairing_enabled )
{
    uint8_t pairing_enabled = 0;
    if ( is_pairing_enabled )
    {
        pairing_enabled = 0x80;
    }
    RadioParParameterUnion value;
    RadioParSecurityMode securityMode;
    RadioParRssiThreshold rssiThreshold;
    paramGet( VERSION, &value );
    beacon.pairing_and_version = pairing_enabled | ( 0x7fu & value.version );
    paramGet( CHANNELMASK, &value );
    beacon.channel_mask = hton32( value.chMask );
    paramGet( SECURITY_MODE, &value );
    securityMode = value.securityMode;
    paramGet( RSSI_THRESHOLD, (RadioParParameterUnion *)&rssiThreshold );
    if ( securityMode > SECMODE_RESERVED2 )
    {
        securityMode = SECMODE_UNDEFINED1;
    }
    beacon.security_mode = ( securityMode << 4 ) & 0xf0;
    print(Diags_INFO,
            "beacon: pairing: %d, version: %d, secmode: 0x%x, chmask 0x%x(nb) rssiThreshold %d",
            is_pairing_enabled,
            0x7fu & beacon.pairing_and_version,
            beacon.security_mode,
            beacon.channel_mask,
            rssiThreshold);
    ApiMac_mlmeSetReqUint8( ApiMac_attribute_beaconPayloadLength, sizeof( beacon ) );
    ApiMac_mlmeSetReqArray( ApiMac_attribute_beaconPayload, (uint8_t*) &beacon );
    ApiMac_mlmeSetReqBool( ApiMac_attribute_associatePermit, true );
    ApiMac_mlmeSetReqUint8( ApiMac_attribute_rssiThreshold, (uint8_t)rssiThreshold);
}

Somehow all the associated devices' short addresses (0x1000 - 0x100B) end up in the beacon response, in front of the application's payload. 
What is causing this and, more importantly, how to keep the short addresses out of the beacon response payload?

Please forward this update to the team, since this probably limits the scope of the issue.

Best regards,

Christian

Hi Christian and Martin,

I'm still waiting for response from RnD team.

Either Ryan or myself will update here again within 4 business days.

Thanks,
Toby

I had received the following feedback:

Please try:

MAC_CFG_TX_DATA_MAX=24

MAC_CFG_TX_MAX=32

Still the same behaviour sadly.

Thanks for the update Christian.  Is your application modifying the beacon payload?  This is not typical for the TI 15.4-Stack.  Have you evaluated any difference in behavior when using the default collector example?

Regards,
Ryan

Hi Christian,

The corrupted beacon response is interesting as the Pending Address Specification field is 0x0C, so Beacon attempts to include 12 Pending Addresses although the maximum allowed should be 7.  0x0C = 1100b, bits 0 through 2 are the Number of Short Addresses Pending, 100b in the corrupted beacon response image, where as bit 3 is reserved and should not be 1.

Thank you for reporting, this will be further investigated by the R&D Team.

Regards,
Ryan

We do have a custom beacon payload which we set through your API (6 and 8 bytes respectively) as seen below. Otherwise we don't do anything else to the payload, so I can't really see a reason as to why it should cause this issue.

Do you only see the erroneous behavior when using the custom beacon payload, or can it be replicated with the default TI code as well?  This will help the R&D Team determine where to locate the problem, or whether the custom code needs to be further investigated.

Regards,
Ryan

I'm currently looking into testing this.

Meanwhile I have made some more findings, although I am unsure about what settings I was using so I will dig a bit more.

But I have seen the following:

• Non-corrupt beacons with varying pending short addresses (2 & 7)
• Corrupt beacons with varying pending short addresses
• Corrupt beacons with one pending long address (which was a combination of four paired short addresses)
• Corrupt beacons with no pending addresses

It does seem like when the Pending Address Specification field is either too big or doesn't correlate to the size of the address list our data gets corrupted, which makes sense.

I will test a bit more and see if I can manage to reproduce it without our custom payload, but running default TI code might be a bit tricky for me.

Best regards,

Christian

After some further testing with the custom payload (also without) I'm wondering if the Pending Address Specification field is handled properly within, I assume, macBuildBeaconNotifyInd()?

In my tests the pending address specification field seems to always equal the amount of pending messages and gets added to the beacon length even though it's larger than 0x07. You can see this in the two captures below, 5 pending vs 13 pending gives 16 bytes.

Thanks for supplementing your observations with sniffer log screenshots.  If you've replicated these results without the custom payload, then this is the behavior which has been reported and is being investigated by TI 15.4-Stack R&D.

Regards,
Ryan

Hi Ryan, is there any link or ticket that allow us to track that issue? It's very important for us to know when this bug will be fixed.

Andrzej

Hi Andrej,

The ticket is internal and cannot be accessed externally.  The TI R&D Team have implied attempting to resolve this in Q3 2024.  Any replication steps using default TI code, or further instructions as to what specific Beacon Payload changes are required to cause the issue, would help accelerate the investigation.

Regards,
Ryan

Hi Ryan, any update ?

Hi Andrzej,

Thanks for checking in.  The 15.4-Stack R&D Team was able to identify an issue and propose a fix last week.  However, it involves changes to source code which is inaccessible in the release SDK meaning that the solution would only be available in the next SDK update which is likely v8.30 in Q3 2024.

Regards,
Ryan

Understood
Thank you Ryan