CC2652R: GPP don't deliver GPDF in tunnel mode.

Hardware: three hardware board of LaunchpadCC2652

Plartform: SDK V3.10.00.53

Project:zcl_light_sink, zr_genericapp, gpd_sw

       For the project zr_genericapp, I have change the button behavior to enable/disable the commission mode(gp_SetProxyCommissioningMode) by button click.

step1: the Light Sink and another routing device are in the same network,

step2: put the Light Sink(gp_SetSinkCommissioningMode=TRUE) and Router(gp_SetProxyCommissioningMode=TRUE) in commissoning mode

step3: GPD send the On/Off GPDF to trigger the pairing prcess (packet number 76 - 85, please reffer to the attachment "gp")    

step4: disable  the GP commissioning mode on the Light Sink and the Proxy.

step5: the GPD Switch can toggle the Light Sink LED(direct mode)

I have repeat the steps sevel times, but found that the network is always be in the direct mode.

how to establish a tunnel mode link between the Sink and the GPD?

gp.zip

Hi,

According to the state machine for GP Proxy Basic, the GPPB will not enter Proxy commissioning mode until it receives GP Proxy Commissioning Mode (Action==enter).

Please see the callback that handles the GP Proxy Commissioning mode command: zclGp_GpProxyCommissioningModeCB.

Can you try UI_SetGPPCommissioningMode instead of gp_SetProxyCommissioningMode?



Regards,
Toby

Hi,Toby,

thank you for you reply.

I modify the code in the zclGenericApp_processKey() as follow:

static void zclGenericApp_processKey(uint8 keysPressed)
{
    zstack_bdbStartCommissioningReq_t zstack_bdbStartCommissioningReq;
    //Button 1
    if(keysPressed == KEY_LEFT)
    {
        if(ZG_BUILD_COORDINATOR_TYPE && ZG_DEVICE_COORDINATOR_TYPE)
        {

            zstack_bdbStartCommissioningReq.commissioning_mode = BDB_COMMISSIONING_MODE_NWK_FORMATION | BDB_COMMISSIONING_MODE_NWK_STEERING | BDB_COMMISSIONING_MODE_FINDING_BINDING;
            Zstackapi_bdbStartCommissioningReq(appServiceTaskId,&zstack_bdbStartCommissioningReq);
        }
        else if (ZG_BUILD_JOINING_TYPE && ZG_DEVICE_JOINING_TYPE)
        {
            zstack_bdbStartCommissioningReq.commissioning_mode = BDB_COMMISSIONING_MODE_NWK_STEERING | BDB_COMMISSIONING_MODE_FINDING_BINDING;
            Zstackapi_bdbStartCommissioningReq(appServiceTaskId,&zstack_bdbStartCommissioningReq);
        }





        //add
        static uint8 tmpSta = 0;

        if(zclport_isAlreadyPartOfNetwork(appServiceTaskId)){
            if(tmpSta){
                Board_Led_control(board_led_type_LED1, board_led_state_ON);

                #if defined(BOARD_DISPLAY_USE_UART_EXT)
                    genericApp_UART_write("ON\r\n", sizeof("ON\r\n"));
                #endif

                zclGpProxyCommissioningMode_t cmd;
                cmd.options = GP_COMM_OPT_ACTION_MASK;
                cmd.srcAddr = 0x0000;
                zclGp_GpProxyCommissioningModeCB(&cmd);
            }else{
                Board_Led_control(board_led_type_LED1, board_led_state_OFF);

                #if defined(BOARD_DISPLAY_USE_UART_EXT)
                    genericApp_UART_write("OFF\r\n", sizeof("OFF\r\n"));
                #endif

                zclGpProxyCommissioningMode_t cmd;
                cmd.options = 0;
                cmd.srcAddr = 0x0000;
                zclGp_GpProxyCommissioningModeCB(&cmd);
            }
        }

        tmpSta ^= 1;
    }
}

but the problem still exists.

It appears that the GPPB needs to update its proxy table in order to tunnel GPDFs. I think the issue here is that the GPPB is not updating its proxy table.

According to the state machine, after a successful GPD to GPCB pairing, the GPCB should send a GP Pairing command (gpPairingCmd_t), which will make the GPCB update its table command. This would happen regardless if GPPB is in operational or commissioning mode.

I need to further investigate to figure out why this is not happening.

thx