Hi Harry, Thanks for your response, here are some of my further questions regarding your answers:
1. regarding "I have never seen anything close to a memory move by the code". please check function void MAC_CbackEvent(macCbackEvent_t *pData). there are lots of osal_memcpy used.
2. regarding "Correct and mandatory IEEE 802.15.4 behavior (i.e. MAC ACK) is no indication or promise whatsoever of final message delivery/processing.". that is very interesting to me at least. so the only reason for the failure of message deliver is due to memory failure(I assume they could be memory fragmentation, shortage, or this copy issue?). Or there are some other root causes of failure of message deliver.
3. regarding "An invalid memory move would very most probably always manifest the bug in the given scenario (e.g. during orphan process)". I think if the problem is in memcpy side, it could somehow behave randomly. Since each node have different memory allocation scenario. maybe for certain node. the memcpy happens to have overlap memory space. thus they will fail. and our observation shows that these bug nodes could fail in multiple times for rejoin(most cases, it will pass all orphan process, and go to rejoin, sending beacon req, sucessfully receiving beacon, but still can not join. exactly as you described in item 2). sometimes we even need to physically taking actions to those bug nodes in order to force them to rejoin. we used to believe those actions will change RF behavior and make join successfully done. but after rethinking via our discussion. I think it could be the case that those actions change the memory status and new memcpy dose not have overlap anymore.
4. we are also looking at the RF, soldering . etc. but since our log files show that coordinator alignment/beacon message has been successfully received but no rejoin action is taken. I believe should be in Zstack side issue. (please see attachment for example).(Please visit the site to view this file)
Thanks
Rui
