[参考译文] CC1312R：收集器示例在删除 nv-simulation.bin 后似乎无法恢复

我可以看到 cllc.c 中的 processState 仅被调用为  

$ grep processState collector_log.txt
0.155：进程状态 1
0.804：进程状态 2.
1.498：进程状态 3.

已经向该功能添加了额外的日志记录

 控制器

$ grep Cllc_process collector_log.txt  
  0.118：Cllc_Process 0008
  0.773：Cllc_Process 0008
  1.478：Cllc_Process 0008

因此、我假设我实际上没有完成初始扫描并启动网络？

尊敬的 Andy：

删除  nv-simulation.bin 应该就足够了。 您认为收藏家被卡住了是什么意思？ 您在运行./host_cCollector 的终端上看到了什么？

是否在 collector_log.txt 中看到报告的任何错误？

在传感器侧、您还应清除 LaunchPad 上的 NV：通过同时按住 RST 和 BTN2 按钮来执行此操作、并先释放 RST、同时仍按 BTN2。

由于这些是自定义日志、您能否详细说明它们是什么？  Cllc_coord_stats_t 是数字吗？

$ grep processState collector_log.txt
0.155：进程状态 1
0.804：进程状态 2.
1.498：处理器状态 3

这些是什么？

$ grep Cllc_process collector_log.txt  
  0.118：Cllc_Process 0008
  0.773：Cllc_Process 0008
  1.478：Cllc_Process 0008

此致、

Daniel

是的、它们只是传递到这些值的变量的打印

我是一个很长的路使用你的评估板现在顺便说一句,这样做东西与他们是不是一个选项  

我做的和按钮按压操作一样

我的意思是、Stuck 只是不是从现在开始

如果我禁用了 NO_HEADless 模式、这会再次显示

但这就是全部

这是当前正在运行的完整收集器日志文件

e2e.ti.com/.../2727.collector_5F00_log.txt

它一直工作,直到我停止它运行,删除 nv-simulation.bin 并重新启动

我有大约 23 个传感器配对,现在孤立地在办公室在这里与运行收集器代码等的 2 个基站

尊敬的 Andy：

1.帮助我了解您的设置,您运行的是 host_cCollector 还是 run_demo.sh ? 因为我在您的日志中看到以下内容：

0.380: socket(server:5000) new cid: 2, h: 11
0.380: socket(server:5000) peer: 127.0.0.1, port 37856

您能否检查 直接运行 HOST_COLLERER 是否可以正常工作？ 如果您可以共享 collector.cfg、也会有所帮助

2.我正在将您的日志与我的日志进行比较（运行 host_collector）,并注意到您缺少 mlmeStartReq

mlmeStartReq: wr_u32:            startTime: 0, 0x0
1.455: mlmeStartReq: wr_u16:                panId: 52430, 0xccce
1.455: mlmeStartReq: wr_u8:       logicalChannel: 0, 0x0
1.455: mlmeStartReq: wr_u8:          channelPage: 9, 0x9
1.455: mlmeStartReq: wr_u8:                phyID: 1, 0x1
1.455: mlmeStartReq: wr_u8:          beaconOrder: 15, 0xf
1.455: mlmeStartReq: wr_u8:      superframeOrder: 15, 0xf
1.455: mlmeStartReq: wr_u8:       panCoordinator: 1, 0x1
1.455: mlmeStartReq: wr_u8:       batteryLifeExt: 0, 0x0
1.455: mlmeStartReq: wr_u8:     coordRealignment: 0, 0x0
1.455: mlmeStartReq: wrBuf:            keySource, len: 8
1.455: mlmeStartReq: wr_u8:        securityLevel: 0, 0x0
1.455: mlmeStartReq: wr_u8:            keyIdMode: 0, 0x0
1.455: mlmeStartReq: wr_u8:             keyIndex: 0, 0x0
1.455: mlmeStartReq: wrBuf:            keySource, len: 8
1.455: mlmeStartReq: wr_u8:        securityLevel: 0, 0x0
1.455: mlmeStartReq: wr_u8:            keyIdMode: 0, 0x0
1.455: mlmeStartReq: wr_u8:             keyIndex: 0, 0x0
1.455: mlmeStartReq: wr_u8:              startFH: 0, 0x0
1.455: mlmeStartReq: wr_u8:         eBeaconOrder: 15, 0xf
1.455: mlmeStartReq: wr_u8:       offsetTimeSlot: 0, 0x0
1.455: mlmeStartReq: wr_u16:    NBPANEBeaconOrder: 16383, 0x3fff
1.455: mlmeStartReq: wr_u8:               numIEs: 0, 0x0
1.455: collector-thread: MUTEX_lock(mi-tx-lock) success (recursion=1)
1.455: uart: TX Msg (start) [mlmeStartReq]
1.455: mlmeStartReq msg(0038) nbytes=47 len=42 [ 0xfe 0x2a 0x22 0x03 0x00 0x00 0x00 0x00]
1.455: uart: TX 47 bytes

3.不确定它是否会有所帮助、因为您可能已经修改了源代码、但最新版本的 TI 15.4 Linux SDK 网关是昨天发布的：

TI-15-4-SDK 软件开发套件 (STACK-GATEWAY-LINUX-SDK)|德州仪器 TI.com

尊敬的 Andy：

您仍然面临这个问题吗？

此致、

Daniel

是的、它再次出现问题

据我所知、我没有更改任何软件、固件或硬件、但现在又陷入圈子里、什么都不做  

e2e.ti.com/.../7484.collector_5F00_log.txt

尊敬的 Andy：

当你说它“陷入圈子里什么都不做“时,你意味着什么。 协处理器是否未与 Linux 主机通信？ 这是否与以前的行为相同？ 也就是说、您删除 nv-simulation.bin 并重新启动网络、或者它以后是否崩溃？  

为了重现此问题并帮助您找到解决方案、您能否分享以下信息：

1. F2 SDK 版本（用于构建协处理器项目的 SDK）

2. TI 15.4-Stack 网关 Linux SDK 版本

3.您的 collector.cfg

4.您正在运行什么脚本来启动网络? run_demo.sh 或 HOST_COLLER

此致、

Daniel

F2 SDK 只意味着全部固件都是在 7 月构建的、但我想您问的是 simplelink_cc13xx_cc26xx_sdk_8_30_01_01？

我也没有更新 15.4 Linux 工作、所以也没有更新您在上一篇文章 ti154stack_linux_x64_4_40_00_03 中提到的较新版本

e2e.ti.com/.../3487.collector.cfge2e.ti.com/.../EPour_5F00_syscfg.txt

没有脚本可启动它、只需运行可执行文件并将其指向配置文件即可

已包含 syscfg 文件（已重命名以便能够上载它）

我不明白为什么它只是简单地是不拿起自己再次. 我已经删除了“传感器“端的网络信息,并重新启动设备【如果我看不到任何明显的方式来让堆栈重新启动】

但从理论上讲,我的知识没有任何变化与任何这一点,它只是不工作,甚至留下了很长一段时间运行,甚至试图撤消孤立的超时等

我可以看到有一些  

2243.212：UART：Rx：孤立
2243.212：孤立的 msg (11d9) nbytes=24 len=19 [ 0xFE 0x13 0x42 0x8a 0x11 0x58 0xad 0x34]
2243.212：孤儿：rdBuf：        ext-addr、len：8
2243.212：孤儿：11:58:AD:34:00:4b:12:00
2243.212：孤儿：rdBuf：       密钥来源、长度：8.
2243.212：orphan-ind：rd_u8：securityLevel：   0、0x00
2243.212：孤立：rd_u8：  keyIdMode：   0、0x00
2243.212：孤立：rd_u8：   keyIndex：   0、0x00

消息

这是合理的、因为某些设备仍在运行、显然正在与此收集器通信、但收集器已重置、这必须意味着对讲机配置侧必须仍然正常、因为可能有 5 个设备定期发布这些消息

这将需要一个合适的团队电话来解决我认为可能有太多事情要不断张贴回来

尊敬的 Andy：

感谢文件。  
我想您现在描述的是不同的问题？
1.当您停止协处理器时,它会崩溃,删除 nv-simulation.bin 并重新启动它? （原员额）
2.有些传感器在删除其端的网络信息后不能加入网络? （最近发布）
还是同样的问题？ 您能否确认是否存在这些问题、并清楚地解释这两者。

从日志中、我看到“NVRAM：Loaded：nv-simulation.bin“、因此它未被删除、您现在是否正在恢复收集器网络信息？  
当您重新启动收集器时、它将启动网络、但不会打开新连接（以前加入的设备仍然可以重新加入）。 如果您已删除传感器端的网络信息、则需要通过发送“o"命令“命令重新打开收集器端的网络。 你在做这件事吗？

此致、

Daniel

这似乎是我打破了一些东西在传感器结束的事情作为恢复到旧的 1312 固件“固定“的东西和其他一切作为再次拿起自己和使用新的 ti Linux 的东西没有任何赔率,所以肯定与固件相关

请不要侮辱我的东西,如打开网络的方式,我想我已经有点过去的阶段

你能解释和确认对传感器代码中使用的非易失性存储器系统的限制是什么,因为我将它用于 A:和额外的 8 字节的数据,可以“大量“更新 — 每天多次,然后 B:额外的 80 字节的数据,这可能是不经常使用,一旦所有的值都设置

但两人都将通过记忆,那么当他们走到尽头时会发生什么?

尊敬的 Andy：

这不是我的意图,我只是看不到日志中的打开命令。

TI 15.4-Stack 用户指南的这一部分介绍了非易失性存储器的一些注意事项。 但在您的应用方面、我会询问团队一些具体的限制。

应用概述—SimpleLink CC13XX/CC26XX SDK TI 15.4-Stack 用户指南 7.31.00.00 文档

您是否使用为 OAD 应用程序声明的相同 NVS 实例、或者您是否创建了单独的 NVS 实例？  

此致、

Daniel

尊敬的 Andy：

我得到的额外信息是、最好的方法是使用现有的 NVS 以 TLV 方式对数据进行编码。 如果 NVS 已满、则需要执行紧凑操作以释放 NVS 中的无效条目。

此致、

Daniel

TLV 应该是什么意思？  
这其中的其余部分也意味着什么？ 我假设如果 NVS 写入失败、则表示它已满？ 我如何知道或关心事情是否已失效？ NVS 的大多数闪存区域在那一点必须标记为无效,所以你的 NVS 驱动程序肯定做垃圾收集/压缩的 NVS 区域?

尊敬的 Andy：

1.表示数据的存储格式为:类型、长度和值。 例如、在 SSF.c 和 SSF_networkUpdate() 中  、您可以看到使用 nvintf.h 驱动程序以这种 TLV 格式写入网络信息。

t = id、L =  sizeof (nvDeviceInfo_t)、 V = &nvItem

void Ssf_networkUpdate(bool rejoined,
                       ApiMac_deviceDescriptor_t *pDevInfo,
                       Llc_netInfo_t  *pParentInfo)
{
    /* check for valid structure pointers, ignore if not */
    if((pDevInfo != NULL) && (pParentInfo != NULL))
    {
        if((pNV != NULL) && (pNV->writeItem != NULL))
        {
            NVINTF_itemID_t id;
            nvDeviceInfo_t nvItem;

            /* Setup NV ID */
            id.systemID = NVINTF_SYSID_APP;
            id.itemID = SSF_NV_NETWORK_INFO_ID;
            id.subID = 0;

            memcpy(&nvItem.device, pDevInfo, sizeof(ApiMac_deviceDescriptor_t));
            memcpy(&nvItem.parent, pParentInfo, sizeof(Llc_netInfo_t));

            /* Write the NV item */
            pNV->writeItem(id, sizeof(nvDeviceInfo_t), &nvItem);
        }