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: Issue with zigbee Send Beacon

Part Number: CC2652R


Tool/software:

currently using sdk 8.30 for 2652r with example project dmm_zr_light_remote_display_oad_app, able to send the beacon only once after that zigbee stack task is busy not able to send the beacon next time this not happening when i set the primary and secondary channel to different value in zigbee configurations. 

  • Hi Pavan,

    I am able to command multiple Beacon Requests on each commissioning attempt with the dmm_zr_light_remote_display_oad_app project.  Please make sure to erase all device memory or factory reset the device, then load the BIM application hex image alongside the DMM application binary image before retrying.  Also provide more information such as sniffer logs and recreation steps so that I may further assist you.

    Regards,
    Ryan

  • Hi Ryan 
    using cc1352p2 chipset (not 2652r)
    i have cleared the memory completely 
    flashed bim off chip 
    flashed the dmm_zr_light_remote_display_oad_app
    observations: 
    put two channel on 11 and click the button continously after 3 4 times given some delay after that when i click the button it's not sending the beacon
    attached the wireshark output
    sometimes it's happening for 2 or 3rd time itself

    it's not crashing but when i stop it goes to cpu.h can see in the above image



  • tried in code compose to check the whether zigbee task state
    the above image after button click is not working after sending 2 beacons with delay

  • I've not been able to replicate the behavior, but I also do not have nearby ZC devices which have permit join disabled.  This reminds me of another E2E post, and I recommend that you try the suggested workaround or use different primary and secondary channel configurations as you previously mentioned.

    Regards,
    Ryan

  • even having different channels for the primary and secondary causing the same issue checked that one
    i have observer that giving some delay after trigger send beacon causing this issue today 
    then i check for different channels it's causing the issue

  • Try implementing the suggested solution from the other E2E post and consider adding a delay (or checking the return commission status) before allowing another commissioning sequence to commence.

    Regards,
    Ryan

  • i tried the changes suggest above 
    still it's keep getting stuck in the zigbee task 

    the event 67 is keep on getting not stopping i checked like 5 to 10 minutes but it's still comming




    wireshark output
    i have cordinator with sdk version 6.10.00.29 
    using example of version 8.30 dmm zr light one

  • Please provide the exact steps and environment necessary in order for me to recreate the issue.

    Regards,
    Ryan

  • Hi Ryan , 

    just done some debugging to identify some issue 
    first the environment i have here is there are two to three co-ordinator which using znp from sdk 6.10.00.29 
    and each of them on different channel 17, 26 , 11
    and routers are around 200 - 250 
    only device one i'm testing is on sdk 8.30 using dmm zr light oad one

    the debug obsevations:
    i have added some logs for better understanding and explanation in the sdk file


    this is where it's getting stuck as previous conversation we have seen 
    i just wanna know whare are the request going and how it's working 
    so i have added logs in zstack process event and osal to know what are the message it's getting from whom



    in the whole logs there are three values  are coming when we trigger the pair request which are relavant to this bug
    zstackmsg_CmdIDs_BDB_START_COMMISSIONING_REQ(b0/176)
    zstackmsg_CmdIDs_BDB_FILTER_NWK_DESCRIPTOR_IND(cb/203)
    zstackmsg_CmdIDs_BDB_FILTER_NWK_DESC_COMPLETE_REQ(cd/205)
    ZDO_STATE_CHANGE(d1/209)



    374 17.09344482 FORMATTED_TEXT N/A LogMod_Log send msg 176 from 8 Args: 176,8,0,0
    375 17.09347534 FORMATTED_TEXT N/A LogMod_Log osal msg 176 8 Args: 176,8,0,0
    376 17.09350586 FORMATTED_TEXT N/A LogMod_Log zstack received 176 received from 8 Args: 176,8,0,0
    377 17.09350586 FORMATTED_TEXT N/A LogMod_Log osal msg 176 0 Args: 176,0,0,0
    378 17.34442139 FORMATTED_TEXT N/A LogMod_Log osal msg 10 0 Args: 10,0,0,0
    379 17.34448242 FORMATTED_TEXT N/A LogMod_Log osal msg 197 0 Args: 197,0,0,0
    380 17.34494019 FORMATTED_TEXT N/A LogMod_Log send msg2 176 from 8 Args: 176,8,0,0
    381 17.34497070 FORMATTED_TEXT N/A LogMod_Log received msg 176 from 8 Args: 176,8,0,0
    382 17.34497070 FORMATTED_TEXT N/A LogMod_Log app got msg 197 Args: 197,8,0,0
    383 17.34506226 FORMATTED_TEXT N/A LogMod_Log osal msg 8 8 Args: 8,8,0,0
    384 17.34509277 FORMATTED_TEXT N/A LogMod_Log zstack received 8 received from 8 Args: 8,8,0,0
    385 17.34509277 FORMATTED_TEXT N/A LogMod_Log osal msg 8 0 Args: 8,0,0,0
    386 17.34518433 FORMATTED_TEXT N/A LogMod_Log osal msg 184 8 Args: 184,8,0,0
    387 17.34521484 FORMATTED_TEXT N/A LogMod_Log zstack received 184 received from 8 Args: 184,8,0,0
    388 17.34524536 FORMATTED_TEXT N/A LogMod_Log osal msg 184 0 Args: 184,0,0,0
    389 17.37197876 FORMATTED_TEXT N/A LogMod_Log osal msg 8 8 Args: 8,8,0,0
    390 17.37200928 FORMATTED_TEXT N/A LogMod_Log zstack received 8 received from 8 Args: 8,8,0,0
    391 17.37203979 FORMATTED_TEXT N/A LogMod_Log osal msg 8 0 Args: 8,0,0,0
    392 17.37234497 FORMATTED_TEXT N/A LogMod_Log osal msg 8 8 Args: 8,8,0,0
    393 17.37237549 FORMATTED_TEXT N/A LogMod_Log zstack received 8 received from 8 Args: 8,8,0,0
    394 17.37240601 FORMATTED_TEXT N/A LogMod_Log osal msg 8 0 Args: 8,0,0,0
    395 17.37921143 FORMATTED_TEXT N/A LogMod_Log osal msg 183 8 Args: 183,8,0,0
    396 17.37924194 FORMATTED_TEXT N/A LogMod_Log zstack received 183 received from 8 Args: 183,8,0,0
    397 17.37924194 FORMATTED_TEXT N/A LogMod_Log osal msg 183 0 Args: 183,0,0,0
    398 17.37930298 FORMATTED_TEXT N/A LogMod_Log osal msg 8 8 Args: 8,8,0,0
    399 17.37933350 FORMATTED_TEXT N/A LogMod_Log zstack received 8 received from 8 Args: 8,8,0,0
    400 17.37936401 FORMATTED_TEXT N/A LogMod_Log osal msg 8 0 Args: 8,0,0,0
    401 17.37945557 FORMATTED_TEXT N/A LogMod_Log osal msg 184 8 Args: 184,8,0,0
    402 17.37948608 FORMATTED_TEXT N/A LogMod_Log zstack received 184 received from 8 Args: 184,8,0,0
    403 17.37948608 FORMATTED_TEXT N/A LogMod_Log osal msg 184 0 Args: 184,0,0,0
    404 17.62252808 FORMATTED_TEXT N/A LogMod_Log osal msg 7 0 Args: 7,0,0,0
    405 17.62368774 FORMATTED_TEXT N/A LogMod_Log osal msg 209 0 Args: 209,0,0,0
    406 17.62371826 FORMATTED_TEXT N/A LogMod_Log zstack received 209 received from 8 Args: 209,8,0,0
    407 17.62377930 FORMATTED_TEXT N/A LogMod_Log osal msg 148 0 Args: 148,0,0,0
    408 17.62384033 FORMATTED_TEXT N/A LogMod_Log app got msg 148 Args: 148,8,0,0
    409 17.62475586 FORMATTED_TEXT N/A LogMod_Log osal msg 29 9 Args: 29,9,0,0
    410 17.62796021 FORMATTED_TEXT N/A LogMod_Log osal msg 5 0 Args: 5,0,0,0
    411 17.62957764 FORMATTED_TEXT N/A LogMod_Log osal msg 5 0 Args: 5,0,0,0
    412 17.64099121 FORMATTED_TEXT N/A LogMod_Log osal msg 5 0 Args: 5,0,0,0
    413 17.64263916 FORMATTED_TEXT N/A LogMod_Log osal msg 5 0 Args: 5,0,0,0
    414 17.65051270 FORMATTED_TEXT N/A LogMod_Log osal msg 5 0 Args: 5,0,0,0
    415 17.88629150 FORMATTED_TEXT N/A LogMod_Log osal msg 7 0 Args: 7,0,0,0
    416 17.88638306 FORMATTED_TEXT N/A LogMod_Log osal msg 1 0 Args: 1,0,0,0
    417 17.88659668 FORMATTED_TEXT N/A LogMod_Log osal msg 3 0 Args: 3,0,0,0
    418 17.88671875 FORMATTED_TEXT N/A LogMod_Log osal msg 203 0 Args: 203,0,0,0
    419 17.88674927 FORMATTED_TEXT N/A LogMod_Log app got msg 203 Args: 203,0,0,0
    420 17.88681030 FORMATTED_TEXT N/A LogMod_Log send msg 205 from 8 Args: 205,8,0,0
    421 17.88681030 FORMATTED_TEXT N/A LogMod_Log osal msg 205 8 Args: 205,8,0,0
    422 17.88684082 FORMATTED_TEXT N/A LogMod_Log zstack received 205 received from 8 Args: 205,8,0,0
    423 17.88687134 FORMATTED_TEXT N/A LogMod_Log osal msg 3 0 Args: 3,0,0,0
    424 17.88690186 FORMATTED_TEXT N/A LogMod_Log osal msg 205 0 Args: 205,0,0,0
    425 17.88824463 FORMATTED_TEXT N/A LogMod_Log send msg2 205 from 8 Args: 205,8,0,0
    426 17.88827515 FORMATTED_TEXT N/A LogMod_Log received msg 205 from 8 Args: 205,8,0,0
    427 17.93838501 FORMATTED_TEXT N/A LogMod_Log osal msg 7 0 Args: 7,0,0,0
    428 17.93954468 FORMATTED_TEXT N/A LogMod_Log osal msg 209 0 Args: 209,0,0,0
    429 17.93957520 FORMATTED_TEXT N/A LogMod_Log zstack received 209 received from 0 Args: 209,0,0,0
    430 17.94125366 FORMATTED_TEXT N/A LogMod_Log osal msg 29 9 Args: 29,9,0,0
    431 17.94512939 FORMATTED_TEXT N/A LogMod_Log osal msg 5 0 Args: 5,0,0,0
    432 17.95623779 FORMATTED_TEXT N/A LogMod_Log osal msg 5 0 Args: 5,0,0,0
    433 17.96087646 FORMATTED_TEXT N/A LogMod_Log osal msg 5 0 Args: 5,0,0,0
    434 18.20281982 FORMATTED_TEXT N/A LogMod_Log osal msg 7 0 Args: 7,0,0,0
    435 18.20288086 FORMATTED_TEXT N/A LogMod_Log osal msg 1 0 Args: 1,0,0,0
    436 18.20309448 FORMATTED_TEXT N/A LogMod_Log osal msg 3 0 Args: 3,0,0,0
    437 18.20321655 FORMATTED_TEXT N/A LogMod_Log osal msg 203 0 Args: 203,0,0,0
    438 18.20324707 FORMATTED_TEXT N/A LogMod_Log app got msg 203 Args: 203,8,0,0
    439 18.20330811 FORMATTED_TEXT N/A LogMod_Log send msg 205 from 8 Args: 205,8,0,0
    440 18.20330811 FORMATTED_TEXT N/A LogMod_Log osal msg 205 8 Args: 205,8,0,0
    441 18.20333862 FORMATTED_TEXT N/A LogMod_Log zstack received 205 received from 8 Args: 205,8,0,0
    442 18.20336914 FORMATTED_TEXT N/A LogMod_Log osal msg 3 0 Args: 3,0,0,0
    443 18.20339966 FORMATTED_TEXT N/A LogMod_Log osal msg 205 0 Args: 205,0,0,0
    444 18.20773315 FORMATTED_TEXT N/A LogMod_Log osal msg 10 0 Args: 10,0,0,0
    445 18.20779419 FORMATTED_TEXT N/A LogMod_Log osal msg 197 0 Args: 197,0,0,0
    446 18.20785522 FORMATTED_TEXT N/A LogMod_Log osal msg 209 0 Args: 209,0,0,0
    447 18.20788574 FORMATTED_TEXT N/A LogMod_Log zstack received 209 received from 2 Args: 209,2,0,0
    448 18.20794678 FORMATTED_TEXT N/A LogMod_Log osal msg 148 0 Args: 148,0,0,0
    449 18.20797729 FORMATTED_TEXT N/A LogMod_Log send msg2 209 from 2 Args: 209,2,0,0
    450 18.25375366 FORMATTED_TEXT N/A LogMod_Log osal msg 10 0 Args: 10,0,0,0
    451 18.25381470 FORMATTED_TEXT N/A LogMod_Log osal msg 197 0 Args: 197,0,0,0

    the above is the log i have taken from sinkbuf 
    so what happening is when the device send commision req (176) i got response from zstack layer for 176 , and also app receive the descriptor indication(203) for that app send the descriptor complete req(205) to the z stack and z stack send the reponse for this 
    this is the success case but at bottom you can see the failure case
    so when app send the 205 to zstack from there the control from app send to the zstack (because priority) so i kept two logs before senidng message and after sending message send msg and send msg2 
    so when app send the message to zstack , zstack process the message and send the response in osal layer can see from osal log
    but before receiving to the app layer it receive messgae 209 from some source , 
    it's saying source 2 which is aps in my code i have disabled the green power
    but after processing complete in the zstack layer control comes to app layer 
    here the send msg2 can be seen as 209 

    438 18.20324707 FORMATTED_TEXT N/A LogMod_Log app got msg 203 Args: 203,8,0,0
    439 18.20330811 FORMATTED_TEXT N/A LogMod_Log send msg 205 from 8 Args: 205,8,0,0
    440 18.20330811 FORMATTED_TEXT N/A LogMod_Log osal msg 205 8 Args: 205,8,0,0
    441 18.20333862 FORMATTED_TEXT N/A LogMod_Log zstack received 205 received from 8 Args: 205,8,0,0
    442 18.20336914 FORMATTED_TEXT N/A LogMod_Log osal msg 3 0 Args: 3,0,0,0
    443 18.20339966 FORMATTED_TEXT N/A LogMod_Log osal msg 205 0 Args: 205,0,0,0
    444 18.20773315 FORMATTED_TEXT N/A LogMod_Log osal msg 10 0 Args: 10,0,0,0
    445 18.20779419 FORMATTED_TEXT N/A LogMod_Log osal msg 197 0 Args: 197,0,0,0
    446 18.20785522 FORMATTED_TEXT N/A LogMod_Log osal msg 209 0 Args: 209,0,0,0
    447 18.20788574 FORMATTED_TEXT N/A LogMod_Log zstack received 209 received from 2 Args: 209,2,0,0
    448 18.20794678 FORMATTED_TEXT N/A LogMod_Log osal msg 148 0 Args: 148,0,0,0
    449 18.20797729 FORMATTED_TEXT N/A LogMod_Log send msg2 209 from 2 Args: 209,2,0,0
    450 18.25375366 FORMATTED_TEXT N/A LogMod_Log osal msg 10 0 Args: 10,0,0,0
    451 18.25381470 FORMATTED_TEXT N/A LogMod_Log osal msg 197 0 Args: 197,0,0,0

    especially this part the message is getting modified some how in debug the both message 205 and 209 have same address 
    seems that the reason it's getting stuck in the loop and zigbee stack is not responding

  • one More thing this is only happening when the sdk 8.30 is on the channel of any mesh does 6.10.00.29 i.e same issue is not happening for me in 13 channel , 15 channel e.t.c because there is no device on those channel

  • Hi Pavan,

    Thank you for that detailed description.  I have to emphasize that this is an observed behavior which has been previously reported, was reproduced locally, has a workaround available, and is planned to be resolved in the early Q4 release of the SimpleLink F2 SDK.  Can you confirm that the behavior was not improved after modifying bdb_filterNwkDisc?

    https://e2e.ti.com/f/1/t/1484720 

    Regards,
    Ryan

  • Hi Ryan,

    I kept the bdb change still issue is happening 

    What the workaround to solve the issue...?

  • Hi Pavan,

    You are correct, I thought I had observed this workaround before but I am still seeing the problematic behavior today even with the suggested changes.  I am working internally to raise the priority of this issue and will let you know once a valid solution has been found.

    Regards,
    Ryan

  • void OsalPort_clearTaskQueues( void )
    {
    // uint8_t i;
    // uint8_t *pMsg;
    //
    // for(i = 0; i < taskCnt; i++)
    // {
    // while((pMsg = OsalPort_msgReceive(i)) != NULL)
    // {
    // OsalPort_msgDeallocate(pMsg);
    // }
    // }
    }
    removing this solve my issue
    don't know whether it's correct or not 
    found in sdk 8 not in sdk 6

  • hi ryan, 

    any update on this, 
    and also, can you tell me is the commenting out clear task queue  is ok..?

  • Thank you for reporting the change which improves behavior, I've shared your findings with the R&D Team and am waiting for their thoughts on this subject.

    Regards,
    Ryan

  • Hi Pavan,

    Your workaround has been approved and TI R&D will implement a fix by the next SimpleLink F2 SDK release.

    Regards,
    Ryan