SIMPLELINK-CC13XX-CC26XX-SDK: DstAddrMode is zeroed in MAC_WS_ASYNC_IND packet

Guilherme Akira Alves dos Santos

Part Number: SIMPLELINK-CC13XX-CC26XX-SDK
Other Parts Discussed in Thread: LAUNCHXL-CC1352R1

Tool/software:

Hi!

I am currently implementing an application that interfaces the coprocessor in order to communicate with the sensor example (found in the SIMPLELINK-LOWPOWER-F2-SDK v8.30.01.01) with frequency hopping enabled. Both examples running on LAUNCHXL-CC1352R1 boards.

I am following this document to communicate to the coprocessor: TI-15.4-STACK-CoP Interface Guide (I know this link is outdated, but the document remains the same in the latest release of the SDK).

When the sensor starts the communication by sending a command MAC_WS_ASYNC_IND (for the Wi-Sun PAN Advertisement Solicit message). The first bytes sent are listed below.

Here you have a few examples of the messages received by the coprocessor, where DstAddrMode is in bold and italic, followed by the DstAddr in bold and underlined.

FRAME RECEIVED: FrameReady { subsystem: MAC, cmd_type: AREQ, id: 93, payload: [3, 76, 7b, a7, 1c, 0, 4b, 12, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, f4, 17, 24, 0, 7, 0, 0, 0, 0, 0, ea, 0, f4, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 16, 0, 12, a0, 8, 88, fa, 14, 0, 0, 1, 8, 0, 0, 6, 5, 46, 48, 54, 65, 73, 74, 0, f8] }

FRAME RECEIVED: FrameReady { subsystem: MAC, cmd_type: AREQ, id: 93, payload: [3, 76, 7b, a7, 1c, 0, 4b, 12, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, bc, c9, d6, 0, 2, 0, 0, 0, 0, 0, ea, 0, f4, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 16, 0, 12, a0, 8, 88, fa, 14, 0, 0, 1, 8, 0, 0, 6, 5, 46, 48, 54, 65, 73, 74, 0, f8] }

FRAME RECEIVED: FrameReady { subsystem: MAC, cmd_type: AREQ, id: 93, payload: [3, 76, 7b, a7, 1c, 0, 4b, 12, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 66, 78, cb, 0, 6, 0, 0, 0, 0, 0, ea, 0, f4, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 16, 0, 12, a0, 8, 88, fa, 14, 0, 0, 1, 8, 0, 0, 6, 5, 46, 48, 54, 65, 73, 74, 0, f8] }

I have two questions:

1. When the SrcAddrMode and SrcAddr is sent, everything works as expected: I receive SrcAddrMode as 0x03 (ADDRESS_64_BIT) followed by 8 bytes corresponding to the SrcAddr. Nonetheless, the DstAddrMode and DstAddr are filled with zeroes (seems reasonable since the sensor still doesn't know the destination address). The problem is that I couldn't find anywhere in the documentation describing 0x00 as a valid value for an AddrMode, possibly leading parsers to invalidate this field. Is the parser supposed to deal with it? So when an AddrMode is set to 0x00, should I always expect it to be followed by an 8-bytes Addr?

2. In the "Length" field, it says that both SrcAddr and DstAddr are 8-bytes long. Is it true even if the SrcAddrMode and DstAddrMode are set to ADDRESS_16_BIT? Or in this case the length of SrcAddr and DstAddr becomes 2 bytes long?

Thank you in advance,

Guilherme Akira

7 days ago

0 Marie H 4 days ago

TI__Guru* 82271 points

Hi Guilherme,

1. I believe 0x00 is the default address of the collector. (TI 15.4-Stack uses two addresses, MAC address during join process, and short address (2 byte) when joined in the network.)

2. Not sure if you could optionally use MAC addresses here. It may be a mistake in the guide.

Cheers,

Marie H

0 Daniel Guarecuco Aguiar 4 days ago in reply to Marie H

TI__Intellectual 1721 points

Hi Guilherme,

1. Yes, 0x0 is a valid value, you can see the address modes defined in api_mac.h.

/*!
 Address types - used to set addrMode field of the ApiMac_sAddr_t structure.
 */
typedef enum
{
    /*! Address not present */
    ApiMac_addrType_none = 0,
    /*! Short Address (16 bits) */
    ApiMac_addrType_short = 2,
    /*! Extended Address (64 bits) */
    ApiMac_addrType_extended = 3
} ApiMac_addrType_t;

And you can see the value being transmitted over the air with a sniffer for the PAN Advertisement Solicit.

1 and 2) In all cases, the address length is 8 bytes, the unused bytes are filled with zeros. Take a look at the address decoder in api_mac.c of the TI15.4-Stack Linux Gateway SDK.

/*!
 * @brief Decode an address from a message
 * @return void
 */
static void decode_Addr(struct mt_msg *pMsg, ApiMac_sAddr_t *pAddr)
{
    int x;
    pAddr->addrMode = MT_MSG_rdU8_DBG(pMsg, "addrMode");
    switch(pAddr->addrMode)
    {
    default:
    case ApiMac_addrType_none:
        /* read something.. */
        for(x = 0 ; x < 8 ; x++)
        {
            pAddr->addr.extAddr[x] = MT_MSG_rdU8_DBG(pMsg, "filler");
        }
        break;
    case ApiMac_addrType_short:
        pAddr->addr.shortAddr = MT_MSG_rdU16_DBG(pMsg, "shortAddr");
        for(x = 2 ; x < 8 ; x++)
        {
            /* read & toss */
            MT_MSG_rdU8_DBG(pMsg, "filler");
        }
        break;
    case ApiMac_addrType_extended:
        for(x = 0 ; x < 8 ; x++)
        {
            pAddr->addr.extAddr[x] = MT_MSG_rdU8_DBG(pMsg, "extaddr");
        }
    }
}

Best regards,

Daniel

Sub-1 GHz

Sub-1 GHz forum

SIMPLELINK-CC13XX-CC26XX-SDK: DstAddrMode is zeroed in MAC_WS_ASYNC_IND packet