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.

TIDA-010024: 6LoWPAN Mesh, enabling SINGLE_FH_CHANNEL mode, debug_push_leaf does not connect if CONFIG_FH_CHANNEL_MASK and FH_ASYNC_CHANNEL_MASK are changed

Part Number: TIDA-010024
Other Parts Discussed in Thread: CC1312R, , TIMAC

This is example code from a couple years back but I am basing some work on it to achieve a mesh network with the CC1312R.

I am having trouble with the push_leaf configuration connecting when the channel mask is changed in single_fh_channel mode.  Attempting to change to 922.4MHz.  I have tried some other channels with the same issue, but testing was not as exhaustive as 922.4MHz.

Can the same behavior be observed (confirmed)?

This is the setup used.

macOS Catalina 10.15.6

Code Composer Studio 10.1.0.00010

SimpleLink CC13x2 26x2 2.40.0.81

TI v 18.12.6.LTS

xdctools_1_51_01_18_core

CC1312R LaunchPad Rev.D (rev E silicon)

TIDA-010024

tidcey4a.zip

6LoWPAN_Mesh_TI_15_4_Example_CC1312R_V2.0.0.0.exe

From this link

www.ti.com/.../TIDA-010024

https://www.ti.com/lit/zip/tidcey4

Please note, the link to the same file on this (other language) page is broken, perhaps someone should look into this.

https://www.tij.co.jp/tool/jp/TIDA-010024

www.tij.co.jp/.../tidcey4

Build configurations

+ debug_push_leaf

+ debug_root_push

For testing these changes were made

Application/subg/config.h

Line 37, uncomment //#define SINGLE_FH_CHANNEL

Line 172, change to the following

#define CONFIG_FH_CHANNEL_MASK        { 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, \

                                        0x00, 0x00, 0x00, 0x00, 0x00, 0x00, \

                                        0x00, 0x00, 0x00, 0x00, 0x00}

Line 192, change to the following

#define FH_ASYNC_CHANNEL_MASK         { 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, \

                                        0x00, 0x00, 0x00, 0x00, 0x00, 0x00, \

                                        0x00, 0x00, 0x00, 0x00, 0x00}

The two above change enable channel 118 (byte 14, bit 6), 925.8Mhz (if my calculations are correct).

Perform a clean and build for the three projects:

+ debug_push

+ debug_push_leaf

+ debug_root_push

debug_push connected in 2-3 minutes after being powered up.

debug_push_leaf does not connect, even after 7 hours.

Next change the values back to the following, clean and rebuild.

Notice the debug_push_leaf does connect within 2-3 minutes.

Line 172, change to the following

#define CONFIG_FH_CHANNEL_MASK        { 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, \

                                        0x00, 0x00, 0x00, 0x00, 0x00, 0x00, \

                                        0x00, 0x00, 0x00, 0x00, 0x00}

Line 192, change to the following

#define FH_ASYNC_CHANNEL_MASK         { 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, \

                                        0x00, 0x00, 0x00, 0x00, 0x00, 0x00, \

                                        0x00, 0x00, 0x00, 0x00, 0x00}

At the moment I don’t have a way to monitor packets but will try to setup something to do packet monitoring with using one of the LaunchPads.

The below following was observed as well.

After the 902.2MHz debug_root AND 902.2MHz push_leaf were powered up the 922.2 push_leaf connected for some reason, I am still investigating the circumstances to how it connected under these conditions.

At this time there were 4 LaunchPads operating

+ 902.2MHz push_leaf

+ 902.2MHz root_push

+ 922.4MHz push

+ 922.4MHz root_push

In the above situation the 922.4MHz push_leaf connected within a few minutes (green LED turns on).  This occurred only once, I have not been able to reproduce this behavior.

I will be attempting to setup a LaunchPad to monitor the packets and be able to observe more detail soon, but wanted to get this initial post up in the mean time.

Could I get a brief explanation of how channel selection and such as handled for the RX and TX?  It is not clearly apparent where in the stack the is occurring.

EDIT: it appears I have located somewhat if what I was looking for, but this is far, far deeper than I wanted to dig into the inner workings.  I am not sure I want to go much deeper, this appears not trivial to understand.

ROM/fh_rom_init.c references this struct in the following file...

simplelink_cc13x2_26x2_sdk_2_40_00_81/source/ti/ti154stack/fh/fh_ie.h  (TIMAC 2.0 FH IE API as written in the file header)  The function prototypes all appear to reference extern MAC_INTERNAL_API.

typedef struct {
    uint8_t regulatoryDomain;
    uint8_t operatingClass;
    uint32_t ch0;
    uint8_t channelSpacing; //0:200kHz, 1:400kHz, 2:600kHz
    uint16_t noOfChannels;
} FHIE_channelPlan_t;

My assumption is that this struct is used in the stack to setup the operating channel, and the CC1312R can only have one channel selected (or tuned on) at a time for transmission or reception.

I am assuming this above sets the channel band plan from which the channel numbers are derived, which then are selected as a channel number.

From this above information the frequency hopping is not a feature of the 802.15.4 MAC stack per say, but it is built into the hardware, as it is in the ROM API files.  The API provides the interface to setup the feature it seems.  I am wondering how much of the 802.15.4 MAC is implemented in hardware vs software, is this an easy question to ask?  I will try to search some documentation on this subject, maybe it is included in the CC1312R technical references.

EDIT:

I mistook the channel number, the cells in the spreadsheet didn't drag down correctly, I am using 922.4MHz (channel 101) for communications.

I was able to get the sniffer setup and am attaching the log, I think the issue is in the push_leaf since the non-leaf connects ok.

These are the updated settings I used for the channel mask.

#define CONFIG_FH_CHANNEL_MASK        { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, \
                                        0x00, 0x00, 0x00, 0x00, 0x00, 0x00, \
                                        0x20, 0x00, 0x00, 0x00, 0x00}
#define FH_ASYNC_CHANNEL_MASK         { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, \
                                        0x00, 0x00, 0x00, 0x00, 0x00, 0x00, \
                                        0x20, 0x00, 0x00, 0x00, 0x00}

The packet sniffer picks them up correctly on 922.4MHz, so I believe the channel setting is correct.

An image and the capture file is included before, all settings (encryption key, etc) are default as was downloaded.

Uploader is picky, I had to make a zip file, the packet capture is inside.

6LoWPAN_9224_202009281454.pcapng.zip

  • I have assigned an expert to comment.

  • Hi Eirik,

    Thank you very much!

    I am continuing investigation of the issue with the resources I have available in the mean time and will update this thread if I find out any new information.

  • Hi Eirik,

    I hope this thread has not been forgotten, I am sure everyone is busy.

    I think I have found the issue here, it was not straight forward and I think somewhere there should be a note about this.

    I would still appreciate an expert comment concerning if what I did is correct, will this cause any side effects to the FH logic???

    I am worried a little of the side effects of this workaround/solution.

    Are there ANY other problems with changing CONFIG_FH_CHANNEL_MASK and FH_ASYNC_CHANNEL_MASK that might cause issues?

    Do sleepy leaf nodes not participate in frequency hopping (FH)?

    Outside of this issue I am very happy with the 6LoWPAN mesh sample provided and am glad it is available.

    Apparently when FH is enabled sleepy leaf nodes are still fixed to a specific channel.

    This appears to be fixed to channel 0 in the idllc.c file, which is a frequency I excluded from the available FH channels.

    I am providing the function Jdllc_init() in idllc.c, line 242

    CONFIG_RX_ON_IDLE is set to zero for a sleepy leaf node, this drops us down to the else section of that if condition.

    If you notice there are three lines that need to be changed to a frequency that the is not masked out, please correct me if I am wrong here.

    The three zeros appear to stand for the channel number that a sleepy leaf node can use, they need to be a channel that is not masked.

    In my case I only have channel 101 unmasked, so these need to be set to 101 in my case.

    Please, please I do recommend and insist that there be a note added somewhere visible that if the CONFIG_FH_CHANNEL_MASK and FH_ASYNC_CHANNEL_MASK are changed in a way to exclude channel 0 that these three lines will need to be changed to an available channel.  This caused me a lot of frustration to track down.

                /* set PIB to enable fixed channel*/
                ApiMac_mlmeSetFhReqUint8(ApiMac_FHAttribute_unicastChannelFunction, 0);
                ApiMac_mlmeSetFhReqUint8(ApiMac_FHAttribute_broadcastChannelFunction, 0);
    
                /* set fixed channel in FH PIB */
                ApiMac_mlmeSetFhReqUint16(ApiMac_FHAttribute_unicastFixedChannel,0);

    Below is the complete function, if it helps to see it in full context.

    void Jdllc_init()
    {
    
    #if(IS_ROOT)
        uint16_t panid=CONFIG_PAN_ID;
    
        if((panid!=0x0000) && (panid!=0xFFFF))
        {
            devInfoBlock.panID=panid;
        }
    
        /* setup short address */
        /* not used for 6LoWPAN mesh stacks but requires for TI-15.4 */
        ApiMac_mlmeSetReqUint16(ApiMac_attribute_shortAddress,
                                CONFIG_SHORT_ADDR);
    
        /* Always set association permit to 1 for FH */
        //ApiMac_mlmeSetReqBool(ApiMac_attribute_associatePermit, true);
    #endif
        ApiMac_mlmeSetReqBool(ApiMac_attribute_RxOnWhenIdle, true);
    
        if(CONFIG_FH_ENABLE)
        {
            uint8_t sizeOfChannelMask, idx;
            sizeOfChannelMask = sizeof(fhChannelMask)/sizeof(uint8_t);
    
            /* PIB for FH are set when we receive the IEs*/
            /* enable frequency hopping operation */
    
            ApiMac_mlmeSetFhReqUint8(ApiMac_FHAttribute_unicastDwellInterval,
                                     CONFIG_DWELL_TIME);
            ApiMac_mlmeSetFhReqUint8(ApiMac_FHAttribute_broadcastDwellInterval,
                                     CONFIG_DWELL_TIME);
            ApiMac_mlmeSetFhReqArray(ApiMac_FHAttribute_netName,
                                     (uint8_t*)&fhNetname[0]);
            /* set up the number of NON-sleep and sleep device */
            ApiMac_mlmeSetFhReqUint16(ApiMac_FHAttribute_numNonSleepDevice,
                                     FH_NUM_NON_SLEEPY_HOPPING_NEIGHBORS);
            //ApiMac_mlmeSetFhReqUint16(ApiMac_FHAttribute_numSleepDevice,
            //                          FH_NUM_SLEEPY_HOPPING_NEIGHBORS);
    
            /* if non sleepy FH device */
            if(CONFIG_RX_ON_IDLE)
            {
                uint8_t excludeChannels[APIMAC_154G_CHANNEL_BITMAP_SIZ];
    
                /* set PIB to enable channel hopping*/
                ApiMac_mlmeSetFhReqUint8(
                                ApiMac_FHAttribute_unicastChannelFunction,
                                JDLLC_FH_CHANNEL_HOPPPING);
                ApiMac_mlmeSetFhReqUint8(
                                ApiMac_FHAttribute_broadcastChannelFunction,
                                JDLLC_FH_CHANNEL_HOPPPING);
    
                /* set of Exclude Channels */
                if(sizeOfChannelMask > APIMAC_154G_CHANNEL_BITMAP_SIZ)
                {
                    sizeOfChannelMask = APIMAC_154G_CHANNEL_BITMAP_SIZ;
                }
                memset(excludeChannels, 0, APIMAC_154G_CHANNEL_BITMAP_SIZ);
                for(idx = 0; idx < sizeOfChannelMask; idx++)
                {
                    excludeChannels[idx] = ~fhChannelMask[idx];
                }
                ApiMac_mlmeSetFhReqArray(ApiMac_FHAttribute_unicastExcludedChannels,
                                         excludeChannels);
                ApiMac_mlmeSetFhReqArray(ApiMac_FHAttribute_broadcastExcludedChannels,
                                         excludeChannels);
            }
            else
            {
                /* set PIB to enable fixed channel*/
                ApiMac_mlmeSetFhReqUint8(ApiMac_FHAttribute_unicastChannelFunction, 0);
                ApiMac_mlmeSetFhReqUint8(ApiMac_FHAttribute_broadcastChannelFunction, 0);
    
                /* set fixed channel in FH PIB */
                ApiMac_mlmeSetFhReqUint16(ApiMac_FHAttribute_unicastFixedChannel,0);
            }
    
    #if(!IS_ROOT)
            /* Start FH */
            ApiMac_startFH();
    #endif
        }
    }

    EDIT: After knowing to search for the keyword "ApiMac_FHAttribute_unicastChannelFunction" I was able to find this similar question.

  • It appears that only one line needs to be changed, the other two is not the channel, but perhaps the algorithm used for FH mode.

    This appears to fix the issue with the push_leaf configuration not able to connect.

    This one line needs to be changed to reflect a channel on the white list it seems, please confirm.

    /* set fixed channel in FH PIB */
    ApiMac_mlmeSetFhReqUint16(ApiMac_FHAttribute_unicastFixedChannel,0);

    Change this zero to, say, 102 for 922.6MHz.

  • Hi Eirik,

    Has anyone been been able to find time to review this thread?

    While the issue has been somewhat resolved I would like some confirmation about the solution here and if it there are any concerns about this method.

    While this does not need to answered immediately it would be nice to have an expert comment as confirmation.

  • Hello Allan,

    I am sorry for the delay. I am still searching for a subject matter expert.