Hi TI Team,
Weired behaviour in one my battery powered devices where device hang up while clicking buttons while sending zigbee at the same time.
Not happening when not commissioned.
Regards,
Walter
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.
Hi TI Team,
Weired behaviour in one my battery powered devices where device hang up while clicking buttons while sending zigbee at the same time.
Not happening when not commissioned.
Regards,
Walter
Hi YK
Very difficult to reproduce. Do you have any idea if zigbee stack interrupt limitation.
Regards,
Walter
I never see similar issue in my application so I can only suggest you to try your best to reproduce it with debugger.
Hi,
Agree with YK, please attempt to find the steps which consistently reproduce this issue.
Also, if the issue is difficult to reproduce, I'm not sure we can conclude that it doesn't happen if the device is not commissioned. How many times have you seen this issue while the device is commissioned? To what extent have you attempted to trigger this issue while the device is not commissioned?
Does a reset fix the issue?
If yes, perhaps use the software reset SysCtrlSystemReset in the assert handler Main_assertHandler.
Regards,
Toby
Hi Toby,
When non commissioned, not happening at all for 2 week clicking trying to reproduce. Not happening at a
My deice function very simple my device is only click then send report. But when I click cont as fast as a I can, it will loose connection. Sometimes, link will recover link. But when you click more not allowing to recover, then it will hang & recover in power-cyle.
I want to know why connection drops so oftenly.
You mean enable RESET_ASSERT?
Regars,
Walter
When you click cont as fast as you can, it would raise interrupt continuously and device might not have time to receive MAC ack from parent node. This might cause device loses connection.
The reason YK suggested makes sense, if the device is sending too frequently.
Based on your description, it seems that the link will recover if you don't click for a while. Is this always the case?
When you detect the device is hanging, can you try debugging and see which code is executing? Also, are you using the 3.30 SDK?
Yes, defining RESERT_ASSERT would be sufficient.
It sounds like you are using a custom board.
If yes, are you able to reproduce this issue on a launchpad?
Based on your description, it seems that the link will recover if you don't click for a while. Is this always the case?
When you detect the device is hanging, can you try debugging and see which code is executing? Also, are you using the 3.30 SDK?
It sounds like you are using a custom board.
If yes, are you able to reproduce this issue on a launchpad?
If possible, please provide a log of when this happens. Perhaps we can find a hint there of what the issue could be.