• 状态
  • 已锁定 已锁定
  • 回复 8 回复
  • 订户 0 订户
  • 视图 675 视图
  • 用户 0 会员在此处
选项
选项
相关

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：ZNP 滞留在 osalTimerUpdate 内部- ZStack 3.0.2

admin
Guru**** 2563960 points
Other Parts Discussed in Thread: CC2530

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/958514/cc2530-znp-stuck-inside-osaltimerupdate---zstack-3-0-2

器件型号：CC2530

ZNP 的串行接口没有响应、由于 IAR 在调试过程中打开、我有更多信息。


我对 TimerHead LinkedIn 列表的解释是它已损坏。 干净的链接列表在 EVENT_FLAGS 中只有一位。
屏幕截图应有助于理解这一点。 我还使用 Debug > Memory > Save 保存了内存。 我不知道重新加载它需要什么。


我加入日志。 ZNP 的最后一次通信如下所示： 

[2020-11-22 17：11：58.996636]>[AF/AREQ]** DATA_CONFIRST** ZSuccessess EP：01：6 (SYS：4/TYPE：40/CMD：80)(8)：
：19603 44 80 00 01 06 c0 [2020-11-22 17：11：58.987306] 18 0x0000 SEQ→：Zfe CL7：Zfe 属性：Zfe 3：Zfe Cl 0x51 6
[2020-11-22 17：11：58.993800] 19621→IEEE 802.15.4 5 Ack
****不确定这是来自 ZNP 的有效通信，但仅在以下情况下：
[2020-11-22 17：12：04.972770] 19638→0xec5c IEEE 802.15.4 52保留，dst: 0xec5c，BAD FCS

将来、我将类型转换为"next "、这样我就不需要将其转换到调试器中。 

typedef struct osalTimerRec_s
｛
struct osalTimerRec_s * next；
osalTime_t timeout；
uint16 event_FLAG；
uint8 task_id；
uint32 reloadTimeout；
｝ osalTimerRec_t；

这是一个正常的链接列表：

我还通过更改 MT.c 中一个大变量的存储类来节省了一点 RAM： 

之前：
239 887字节代码存储器
32字节数据存储器(+ 70绝对值)
7935字节 XDATA 存储器
192字节 iDATA 存储器
8位存储器
426字节常量存储器

之后： 

239 887字节代码存储器
32字节数据存储器(+ 70绝对值)
7 891字节 XDATA 存储器
192字节 iDATA 存储
器8位存储
器470字节 const 存储器

这是串行日志和网关日志以及监听器日志。  希望这些设置能够识别导致此问题的原因  、我可以向项目发送下载链接(包括日志等)-由于它包含源代码、我可以通过专用网格来执行此操作。

e2e.ti.com/.../ZNP_5F00_StuckInosalTimerUpdate.zip

  • 0
    TI__Guru**** 2563960 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    作为参考、如果主机应用无法连续从串行接口获取 MT 命令响应、我将重置 CC2530。

  • 0
    TI__Guru**** 2563960 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    你是对的。  在我的情况下、这应该在网关中完成。

    问题还在于 CC2530的看门狗最长为1秒左右。  如果 ZNP 是控制器或路由器、则可以设置它并每秒触发一次、并且还可以在 ZNP 中添加"软件"看门狗。

    当然、导致这种情况的错误会得到更好的解决...

  • 0
    TI__Guru**** 2563960 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    嗨、Mario、

    您在这段时间内是否捕捉到调用堆栈？  很明显、您遇到了 CC2530的 RAM 限制、 SWRA635中对此进行了说明。  根据影响 RAM 可用性的 MT UART/网络流量、可能需要进行 CC2530 ZNP 复位。

    此致、
    Ryan

  • 0
    TI__Guru**** 2563960 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    我没有在正确的位置查找调用堆栈。 调用堆栈没有太多的影响。
    我不知道我们是否可以采取任何形式。

    网络中的设备不超过6个。

    日志显示流量不大。

      #define MAXMEMHEAP 3017  //*不够？ *

    在常规选项中：

    通常、编译器应检查它需要多少堆栈、我不知道它是否这样做。

    OSAL_mem_alloc 检查是否有足够的内存。

    那么、您确认我没有足够的内存？！

  • 0
    TI__Guru**** 2563960 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    尊敬的 Ryan

    很明显、粘贴的图像在站点上不可见、它显示 XDATA 堆栈大小为4D0。

    我们可以比较屏幕截图并读取 XDATA 内存的十六进制文件转储。

    在十六进制转储中、我们可以找到 Timerhead 值、因此这是正确的转储：

    该值无效、因为它位于栈内、栈内的末尾为0x4D0。  遗憾的是、它未初始化、因此目视检查不允许知道是否缺少栈->我在代码中添加了初始化、以便我们下次可以看到这一点。
    此时堆栈指针没有低于0x03F0。

    局部变量大部分映射到寄存器、因此我们无法找到它们用于所使用的函数。

    我检查了 Timerhead 附近的变量、并从 XDATA dum 中提取了它们的值： 

    osalMemStat 25 ->只能为0或1、因此已损坏。
pgOff 01012502012504012506012509
pgLost 0801250A01250C01250E012510
pgRes 01
hotPg 251201
hotOff 250002180402
pwrmgr_attribute 1B000330010322 ->在我的案例中、这些都是0。
TimerHead 0203 -> 0x0302
OsalSystemClock 26030318
taskEvents 040318060318070342080342AB

    看起来 pwrmgr_attribute 也已损坏、我们位于地址0x1800附近。

    但是堆的末尾不会太远： 

    XDATA_Z
相对段、地址：XDATA 00000C19 - 000017E0 (bbbc8字节)、对齐：0
段第7部分。 内部模块引用：OSAL_mem_alloc
OSAL_mem_free
OSAL_mem_init
本地 地址
=== =====
堆 00000C19

    可以在堆中找到最后一个 DATA_CONFIRM (或较早的一个)的副本、该存储器可用于预留、因为它应该被释放。

    :1006A000000000FE034480000106C0C7FE0E0100EA

    从 XDATA 转储中的地址0x17Db 开始、似乎存在某种模式。  这可能会提供导致数据覆盖的原因的线索： 

    起始地址为0x17DB
000025
010025
000125 # osalMemStat 是第一个固定变量、在此行
中为0x25 010125
020125
040125
060125
080125
0a0125 0125 0c0125

0e0125
100125
120125
000218
04021b
000330
010342
020326

040318
06070318 0322 0318
03322 80318

    这对我来说似乎太规律了。

    应该可以了解这是什么。

  • 0
    TI__Guru**** 2563960 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    我明白了、这是在失败后通过通信实现的： 

    [2020-11-22 18：51：56.768371] 20822 0xfect7→0x0000 ZigBee HA 124 ZCL：发现属性响应、序列：5^M
[2020-11-22 18：51：56.768433] 20823 →μ A IEEE 802.15.4 5 Ack^M
[2020-11-22 18：51：56.783757] 20824 0x0000→0xfect7 ZigBee 45 APS：ACK、DST 端点：14、src 端点：1^M
[2020-11-22 18：51：56.784238] 20825 →μ A IEEE 802.15.4 5 Ack^M
[2020-11-22 18：51：56.790531]> (48)：：Fe 63 44 81 00 02 07 C7 Fe 0e 01 00 17 00 d6 AD 25 00 00 4F 18 05 0d 01 00 25 01 25 01 25 01 25 01 25 02 25 04 01 25 06 01 25 08 01 [2020-11-22
18：51：56.797722]> (56)：：25 0A 01 25 0c 01 25 0e 01 25 10 01 25 01 25 00 02 18 04 1b 00 03 30 01 03 22 03 03 03 18 04 03 18 03 18 06 18 03 18 07 03 42 08 03 42 00 04 2a 0E 04 2a C7 Fe 1D AC

    这是在最近一次通信发生时收到的： 

    $ grep "Discover Attributes" ZNP_StuckInosalTimerUpdate.log
[2020-11-22 17：11：58.266573] 19606 0x0000→0xfect7 ZigBee HA 51 ZCL：发现属性、序列：3
[2020-11-22 17：11：58.308222][gateway/HNDL] MUSC1：处理发现属性响应
[2020-11-22 17：11：58.599316] 19612 0x0000→0xfect7 ZigBee HA 51 ZCL：发现属性、序列：5
[2020-11-22 17：11：58.653239][gateway/HNDL] MUSC1：处理发现属性响应
[2020-11-22 17：11：58.987306] 19618 0x0000→0xfect7 ZigBee HA 51 ZCL：发现属性、序列：6
[2020-11-22 17：12：05.017988] 19640 0xfect7→0x0000 ZigBee HA 124 ZCL：发现属性响应、序列：6

    下一步是分析 Discover Attributes 中的内存保留。

    Ryan、我相信您可以深入了解这部分内容。

  • 0
    TI__Guru**** 2563960 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    除非您的 UART TX/RX 缓冲区不够大、无法处理消息大小、否则对 AF_INGINVING_MSG Discover Attributes 响应没有什么特别的影响。  AF_INVING_MSG 和 XDATA 变量之间的0x0125重复表示与堆重叠。  可以假设已超过 MAXMEMHEAP、您能否澄清监听器日志中的 Discover Attributes Response 中应存在哪些信息？

    此致、
    Ryan

  • 0
    TI__Guru**** 2563960 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    如果  超过 MAXMEMHEAP、则内存分配应返回 NULL、系统应继续运行。

    因此、如果实际上可以超过 MAXMEMHEAP、那么 osal_malloc 不能正确验证可用存储器存在问题。

    我建议您查看 我在 Z-STACK3.0.2上的最新研发工作 -通过检测代码、可以及早检测到内存问题。  我不能对它做太多、因为它位于库代码 AFAICS 中。

    此问题可能有不同的原因、但通过修改 OSAL_Memory.c、我们可以很容易地知道这一点。