CUI terminal UART input stops working

Hi Alex,

Thanks for reporting this.  I have recreated the issue and furthermore found that it happens when any keyboard buttons (not just valid inputs) are held during a fresh join as well.  It appears that the delay from the Zigbee join processing is causing an issue with the UART RX, although reducing the keyboard's repeat rate does not resolve the issue so I am not convinced that it is buffer overflow.  Furthermore, increasing the UART FIFO or limiting the number of inputs processed per second did not improve behavior.  CUI_MIN_FOOTPRINT will completely disable UART input but allow for CUI information to show.  Otherwise you may consider closing/re-opening the CUI during join/rejoin procedures.

Regards,
Ryan

It's sad, because we are going to use the CUI menu for our purposes in some projects and this unexpected behavior could break our plans. Let me know, please, if you find any fix for this.

Also I found another bug in the LED driver.

Parameter "uint16_t togglePeriod" in the LED_Object structure should be uint32_t. Otherwise long blinking periods don't work, because number of ticks doesn't fit into uint16_t.

I've submitted a bug ticket so that the Software Development Team can further investigate the UART RX issue.

Regards,
Ryan

ok, thanks

Also let me show what I meant by the bug in the LED driver, maybe it was not clear.

In fact, the "togglePeriod" is not in "ms" units, it is in "tick" units.

And the msToTicks() function returns uint32_t, although the "togglePeriod" is uint16_t.

It seems like a bug.

Thanks for clarifying, a second ticket has been filed so that the responsible Team can handle this issue.  You can modify the TI Driver files by copying the LED.c module directly into your project and making changes to source/ti/drivers/apps/LED.h

Regards,
Ryan

Thanks! I added the solution. Now it is better, but still happens sometimes.

Do you know how I could stop commissioning process on the ZED device?

We have two options in our CUI to start commissioning with "Install Code" and "Default TC-LK".

Our ZC also has these options. When I start the same option on ZED and ZC they both connect fine.

But if I start "Default" on the ZC and then start "Install Code" on the ZED by mistake, I try to start it again in "Default" mode, but ZED can't connect. I have to reset the ZED.

So it looks like if ZED starts commissioning, we can't interrupt it and start a new commissioning process.

Acually the initial idea was to try commissioning with Install Code and if we keep a button for some time, the ZED should start commissioning with the Default TC-LK.

This is a code how I try to configure the Default TC-LK.

        zstack_bdbSetActiveCentralizedLinkKeyReq_t zstack_bdbSetActiveCentralizedLinkKeyReq;
        zstack_bdbSetActiveCentralizedLinkKeyReq.zstack_CentralizedLinkKeyModes = zstack_UseDefaultGlobalTrustCenterLinkKey;
        zstack_bdbSetActiveCentralizedLinkKeyReq.pKey = NULL;
        uiApplyInstallCodeLastStatus = Zstackapi_bdbSetActiveCentralizedLinkKeyReq(uiAppEntity, &zstack_bdbSetActiveCentralizedLinkKeyReq);

ZED gets stuck in cycling Joining - Joined Unsecured, then goes to Initialized. And any new commissioning process gives the same result. if I reboot ZED (even without RESET TO FN, just hardware reset), it works well again.

Have you considered changing ZDSECMGR_TC_ATTEMPT_DEFAULT_KEY to TRUE in zd_sec_mgr.h?  You could also try Zstackapi_bdbStartCommissioningReq with commissioning_mode set to zero.

Regards,
Ryan

Setting the parameter to TRUE doesn't start joining with default keys if install code fails. The commissioning mode 0 doesn't interrupt the commissioning.

It looks like it needs to refresh something after failed commissioning.