• State
  • Locked Locked
  • Replies 1 reply
  • Subscribers 55 subscribers
  • Views 483 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

CC2530: Delay issues under remote control

Cherry Zhou
Mastermind 22235 points
Part Number: CC2530

Hi team,

Here's some questions from the customer may need you help:

1. DIY their own Zigbee switch, connect to HomeAssistant via zigbee2mqtt, local and remote control is good. However, after multiple remote control,  here shows control delay (typically 1-3 seconds) and sometimes even a MAC ACK Fail alarm (more than 10 seconds). The customer would like to know if the delay in MAC ACK is normal and how to resolve it?

2. The watchdog is started in the protocol stack program, the dog feeding program is added after the oval_run_system(); and the dog feeding program is also added in the program section for long-press switch reset.

However, in the test, the switch turns off about 30 minutes after it turns on. It is supposed to be due to a blocking at somewhere in the program that causes the watchdog to not feed the dog successfully. The customer would like to know if the blocking is possible in the OSAL stack and what should be noted?

3. The UART function of the protocol stack is used in the program for debugging, but once the programr (Smarf04EB) is not connected, the UART outputs (P02, P03) are not available, but when connect again,  the output is normal. What's the possible reason for that?

Could you help check this case? Thanks.

Best Regards,

Cherry

  • 0
    TI__Guru**** 217767 points

    Hi Cherry,

    1. I would like to see a sniffer log which further demonstrates this issue.  Failure to receive MAC ACKs within the timeout is typically the fault of the node being communicated with.  In these instances the best action is to retry sending the packet. 
    2. Can they show exactly where inside the code they are feeding the watchdog?  Also, how long is the watchdog delay set for?  They can try using the watchdog interrupt and debugger to further understand the state of the MCU if it becomes stuck.
    3. Check the SmartRF04EB design (it has been obsoleted by TI for several years) and check whether the P02/P03 UART pins operate through the debug connection.  This form of backchannel UART communication is quite common for evaluation boards.

    Please impress on the customer that they should consider a SIMPLELINK-CC13XX-CC26XX-SDK device for the latest Zigbee solutions available.

    Regards,
    Ryan