This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC2652R: DMM with Ble Peripheral + Ti15.4 Coordinator - transmit on top of transmit assert triggered

Part Number: CC2652R

Tool/software:

Hello!

I encountered an unexpected TI15.4 stack error while working on a project that requires simultaneous operation of Bluetooth peripheral and Ti15.4 Coordinator. When running the program for a longer periods of time with Bluetooth simply advertising (interval of 1s) and some traffic on TI15.4 network an assert from TI15.4 stack is triggered. Dumping LR value on assert I found out that the error is triggered in macTxFrame function located in the mac_tx.c file - "transmit on top of transmit"

MAC_INTERNAL_API void macTxFrame(uint8 txType)
{
  MAC_ASSERT(!macTxActive);            /* transmit on top of transmit */
  MAC_ASSERT(pMacDataTx != NULL);      /* must have data to transmit */

  /* mark transmit as active */
  macTxActive = MAC_TX_ACTIVE_INITIALIZE;

There is no particular way in which I can triggered this assert, it seems to happen randomly.

The very first time I was faced with this issue was in SDK version: simplelink_cc13xx_cc26xx_sdk_7_10_01_24
I then decided to upgrade to the latest available SDK version (simplelink_cc13xx_cc26xx_sdk_7_41_00_17) but the issue seems to still be there with the MCU asserting randomly on that "transmit on top of transmit" assert. Given that this is a rather low level MAC function and DMM running on top of it I would assume such synchronization is already in place.

Questions:

  1. What could be the reason for MAC layer to trigger such assert?
  2. What can be done to prevent such asserts? (what conditions should be met in order to minimize the possibility of such error)
  • Hello Michal, 

    I will look further into your questions and back to you soon, sorry for the delay here!

    Thanks,
    Alex F

  • Hello Michal,

    If you can trigger MAC_ASSERT(!macTxActive); then we should add debug code to break here if macTxActive is anything other than MAC_TX_ACTIVE_NO_ACTIVITY.

    Can you confirm that this can be replicated with an out-of-box DMM example and whether 15.4-Stack end nodes need to be connected and communicating (and how many)?

    Thanks,
    Alex F

  • Hello! Thank you for your swift response and sorry for my late follow up. I had to gather more information from my QA Team.

    To provide you with more information:

    • There is only one end device communicating over TI15.4 network with the coordinator. However, the coordinator device (which is the victim of an assert) is constantly sending out a special broadcast message (every 250ms) – the mechanism for sending this “broadcast” message is the same as for any other standard message
    • I have not yet tried to replicate it on a DMM sample as I believe the TI15.4 network operations in the sample code don’t really replicate the application code in our product

    The issue seems to be hard to reproduce. There is no known way in which I can trigger this to happen – seems rather random. The main reason for this thread is my hope of you providing me with some insight when such assert could be triggered (like a scenario in which DMM and/or ti15.4 stack may fail to properly schedule messages). Then I might be able to produce a reliable way of reproducing that.

    One thing that comes to mind that could help us get to the bottom of it:
    The device I am working on uses the broadcast message to assess if currently selected channel is busy or not (think of it as an active CCA that constantly monitors channel availability). Whenever a predefined number of broadcast messages fails to be sent a channel change procedure starts and so the central device performs a scan of type ApiMac_scantype_energyDetect.

    Could there be any bad interaction between changing channels, Bluetooth advertising and sending TI15.4 messages?