Problem with updating from ARM7 Beestack Codebase 3.0.11 to 3.1.1 on MC13224V

[teemuavellan]

Hi,

I have run into problems when I upgraded your HA coordinator's firmware to use Codebase 3.1.1. It causes the coordinator to go "deaf" for about 5 minutes in every 4 hour and 45 minutes.

It's very strange problem because it will occur exactly on clock every time. It does either not hear messages sent to it or ignores them completely during blackout. I used sniffer to see that messages are sent but there's no MAC-ACK. Ztc interface "normally" during blackout, and the chip give responses to commands, also it will send messages e.g link status.

This is not an application caused problem because I tested this also "vanilla" build, creating a sample coordinator with HA combined interface -template from Beekit.

This problem does not occur with older 3.0.11 codebase.

-Teemu

[AngelC]

Dear Teemu,

Please provide further details about the application itself and how to trigger the problem. In other words:

• How many devices are on the network?
• How often are messages sent to coordinator?
• Is coordinator sending any response back?
• Also, if you modify the transmission’s period, is the problem appearing at a different time or exactly the same?

This will help us to have a better context of the problem and find a possible root cause. I will be looking forward to your reply.

Regards,

AngelC

[teemuavellan]

Hi, any progress on this case?

Br,

Teemu

[AlanCollins]

I was able to reproduce the problem that teemuavellan found. I sent results to SW team including memory dumps, sniffer LOGs, source code, and other deeper analysis.

I will report the outcome as soon as I get a resolution from SW team. Thank you in advance for your patience.

[teemuavellan]

Hi Alan,

any news on this? I know these things are hard to estimate, but could I get some kind of time frame when this could be solved?

Thanks,

Teemu

[AlanCollins]

Hello teemuavellan, As you know MC1322x is on "end of life", so all support related to this part is very limited today. Please be patience about a resolution.

In the meantime, if you want to investigate further, I suggest to use the following tips & tricks to isolate a the root cause: MC1322x: How to get memory dumps to analyze at failure state... and other tips & tricks

[teemuavellan]

Hi Alan, thanks for nice guide for memory dumps.

I noticed that the sniffer software also suffers from the same problem. It could go unnoticed because it doesn't go "deaf" like HA coordinator sw does. But I noticed that the timestamp received with frames resets after this 4:45 time period. I was using MC1322x_Sniffer_Firmware_MC2.1_V1.0.2 firmware.
Also this showed more accurate representation that how long time this period takes. It was 4 hours 46 minutes 10-20 seconds, at least according to the sniffer timestamps.

I hope this information will be helpful for you!

Br,

Teemu

[teemuavellan]

This is great news. Thank you, Alan!

Looking forward for the resolution.

Br, Teemu

[teemuavellan]

Hi,

I tried with only one thermostat on the network and changed polling time to 1 second. No change, still the coordinator stop listening after 4:45. Here's a sniffer capture log of the situation:

Br,

Teemu

[teemuavellan]

Hi AngelCI,

thank you for the reply!

I have tried this with multiple setups. There has been from 2 to 15 devices on the network. The number of devices does not seem affect to the timing of the problem. It occurs always after running for 4 hours 45 minutes.
Device are battery powered thermostat and they are polling (sending Data requests ) the coordinator for every 2 seconds. I haven't try changing the polling time, but I doubt it will have any significance. If it would be related to the quantify of message, I would assume that also number of devices would matter, don't you think?

During this blackout coordinator does not respond any messages, though it will transmit messages if it has any. For example Link status messages and commands sent through ZTC.

Thanks again,

Teemu Avellan