[参考译文] CC1310：如何在启用跳频和睡眠模式的 TI-15.4堆栈中强制传感器节点重新加入网络？

您好、Zhiyong、

连接调试器后是否可以达到此状态？ 查看传感器卡在哪里可能会很有趣。

此致、

SID

尊敬的 Sid：

谢谢你的忏悔。

Unknown 说：

连接调试器后是否可以达到此状态？

不幸的是没有,至少还没有。 到目前为止、这种情况仅发生在现场测试设备中、在~9个月的时间内、~ 100个设备中有7个进行了测试。 这些单元已锁定调试接口。 我们试图通过反复擦除闪存并强制传感器节点重新加入网络来重现此情况、但到目前为止我们无法重现此情况。 我怀疑这与部分闪存损坏有关。 因为一旦我们通过下载新固件副本来擦除这些故障单元的闪存、它们就会再次正常工作。

鉴于我们无法重现问题、我的怀疑是、要做到这一点、需要集电极节点发出低信号和/或环境干扰的组合。 这些因素也许会以某种方式扰乱闪存擦除/写入时序。

我的问题是、是否有办法显式实现闪存擦除/写入阻止？ 据我了解、这是由 RTOS 在传感器节点示例代码中进行管理的。 另一个问题是、是否有方法可以通过擦除父节点/收集器器件信息来强制传感器节点重新加入网络？

谢谢。

ZL  

器件型号：CC1310

您好！

我们需要将一些网络参数存储到 NVS 中。 为此、我们简单地向 LLC_NETINFO_t 中添加了一个额外的成员：

// in llc.h
/*! Network Information */
typedef struct
{
    /* Address information */
    ApiMac_deviceDescriptor_t devInfo;
    /*! Channel - non FH */
    uint8_t channel;
    /*! true if network is frequency hopping */
    bool fh;
    /* the following doesn't exist in original example code */
    uint8_t params[72];
} Llc_netInfo_t;

之后、我们仅依赖示例代码附带的以下函数来管理此新增成员。

// in ssf.c

void Ssf_networkUpdate(bool rejoined,
                       ApiMac_deviceDescriptor_t *pDevInfo,
                       Llc_netInfo_t  *pParentInfo)
{
    // ommited
}

bool Ssf_getNetworkInfo(ApiMac_deviceDescriptor_t *pDevInfo,
                        Llc_netInfo_t  *pParentInfo)
{
    // ommited
}

void Ssf_clearNetworkInfo()
{
    //
}

在很大程度上、这似乎正常工作。 但我们最近发现、在特定条件下重复调用以下函数后、我们的测试单元中的一小部分将会进入可能永久的复位状态。

Ssf_clearNetworkInfo();
Ssf_networkUpdate();

当传感器节点部署到嘈杂的环境中时、某些传感器节点不可避免地会丢弃网络并进入孤立状态。 我们认为、首先重置传感器节点并让它们重新加入网络是一个好主意、如果这样做不起作用、我们随后会将 SSF_NV_NETWORK_INFO 全部擦除、并强制传感器节点从头开始加入网络。 这种策略效果很好、直到我们发现某些传感器节点将进入永久性复位状态。 唯一可行的方法是刷新固件副本、这表明 NVS 或闪存的其他部分已损坏。

因此,回到问题,我们是否需要做任何其他事情后,将一大块数据添加到现有结构? 我试图找到 NVS 在源代码中的初始化方式、但找不到有关各种 SSF_NV_ITEMENT 组织方式的任何信息。 因此、请告知我是否漏掉了任何内容。

更新：在一个闪存相关文档中提到擦除闪存之前有83次写入限制。

https://dev.ti.com/tirex/content/simplelink_cc13x0_sdk_2_30_00_20/docs/tidrivers/doxygen/html/_n_v_s_c_c26_x_x_8h.html

问题是否与此限制有关？ 当我们重复调用以下函数时、我们没有执行任何额外的页宽 NVS 擦除。

Ssf_clearNetworkInfo();
Ssf_networkUpdate();

谢谢。

ZL

您好、Zhiyong、  

不确定它是否正是您正在寻找的,但当您有解离时,传感器会执行 SSF_clearNetworkInfo()。  

我看到有 SSF_clearNetworkInfo()、 SSF_clearAllNVItems(void)。 您可以查看这些函数、并尝试擦除父数据、然后强制传感器再次加入网络。

此致、

SID

尊敬的 Sid：

再次感谢您的重播。

问题很可能与 NVS 有关：1)在擦除之前写入 NVS 的次数限制为83次、2) NVS 驱动程序只需将现有项标记为已删除、然后在 NVS 的空闲空间写入该项的新副本。 结果2)、当我们重复清除然后重置 networkInfo 时、NVS 会被填满、直到填满、此时、我假设 CC1310只是停止全部工作、并进入永久重置状态。

既然我有您、您能就两个 NVS 相关问题帮助我吗？

1)这种83次的限制意味着什么? 假设我们83次删除一个4字节的项目并将其写入 NVS、我们能达到上限吗？ 在传感器节点的示例代码中、系统将在每次系统引导时删除/重新写入复位计数和原因。

2) 2) CC1310中 NVS 的实际起始地址。 根据 CC1310_LAUNCHXL.c 中的定义、默认情况下它应从0x1A000开始

#define NVS_REGIONS_BASE 0x1A000
#define SECTORSIZE       0x1000
#define REGIONSIZE       (SECTORSIZE * 4)

但当我读取 CC1310的整个闪存时、从0x1A000开始的内容实际上都是空的、某些包含已知项目(下面屏幕截图中突出显示的通道掩码)并应进入 NVS 的数据会写入地址0x1E000。

我在这里遗漏了什么？

谢谢。

ZL

您好、Zhiyong、

我正在等待与83个闪存写入周期相关的 rnd 响应。  

但对于第二个问题、我看到链接器 cmd 文件(cc13x0.cmd)默认将 FLASH_NV_BASE 提及为0x1E000。 我假设您观察到的是预期行为、其中通道掩码等属性写入该区域。

此致、

SID   

本主题确实提到了 cc1310上不存在此限制。  

https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/959159/cc1352r-cc13x2-flash-limitations

即使 CC1310中存在此限制、我也不明白它如何适用于我们的案例。 NVS 中最小的项(frameCounter、重置计数和原因)为几个字节长、在83次限制生效之前很长一行存储器将被填满。 当我们反复复位 CC1310时、NVS 页将被填满、然后擦除并重新写入。 我们从未观察到这起作用。 因此83倍限制不太可能是我们出现问题的原因。

您好、Zhiyong、

我在这里合并了你们的两个主题。 这似乎是同一个问题。 NVS 行为规范。

此致、
SID

您好、Zhiyong、

如果您对传感器故障的调查有任何疑问、请分享任何更新。 现在、我将关闭该主题。

此致、
SID