[参考译文] CC2640R2L：运行时 CC2640R2L 停止执行功能

您好！

[引用 userid="333720" URL"~/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1028277/cc2640r2l-runtime-cc2640r2l-stops-executing-functionality ]1. 我们尝试将 CC2640R2L 模块从现在工作的 PCB 更换为工作的 PCB、然后工作的 PCB 也停止工作。[/QUERP]

我认为这是一个很好的指标、表明 PCB 可能不是问题。

您是否详细了解问题是如何发生的(例如、您希望器件"正常工作"的操作)？
发生需要多长时间？

您是否曾尝试在 CCS 中调试不起作用的 PCB？

您是否曾尝试在 PCB 上运行默认示例？

[引用 userid="333720" URL"~/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1028277/cc2640r2l-runtime-cc2640r2l-stops-executing-functionality ]example :Peripheral_Observer 和 Simple Central[/quot]

您在这里提到了2个示例。 您是否看到这两种情况都发生了问题？

[引用 userid="333720" URL"~/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1028277/cc2640r2l-runtime-cc2640r2l-stops-executing-functionality 我们通过闪存编程器从工作中和非工作中的器件读取映像、并对 二者进行了比较、其中显示除扇区外的所有扇区数据- 30保持不变。与 显示相同结果的其他故障样本进行了相同的比较。

所有不工作的器件的闪存内容是否匹配？

谢谢、
Toby

尊敬的 Toby：

请找到您的答案

我认为这是一个很好的指标、表明 PCB 可能不是问题。

您在这里提到了2个示例。 您是否看到这两种情况都发生了问题？

答：是的

所有不工作的器件的闪存内容是否匹配？

ANS：比较了两个不起作用的闪存数据与扇区-30完全匹配(第二个最后一个)

此致、

Bhavin P

您好！

我们尝试使用调试来调试挂起的器件而不在 IAR 中下载功能、并且知道在成功构建所有任务之后、当最后一个代码执行 BIOS_start（)函数时、它不会从该函数和代码存根中输出。

在保持代码运行时、我们会获得以下调试信息、为此我 将放置一些调试窗口。

此致、

Bhavin P

感谢您分享。 从离线讨论中、看起来 PC = 0xd324指向在 HalFlashRead 中读取的存储器。

对于4.40 SDK、团队推出了 SNV 修复程序。 修复程序位于 nvocop.c 源文件中。 为方便起见、此处复制了 ble5stack 和 blestack 版本。 您能否尝试一下这些方法、并告知我们它是否可以解决问题？

e2e.ti.com/.../ble5stack_5F00_nvocop.ce2e.ti.com/.../blestack_5F00_nvocop.c

进一步的想法：

[引用 userid="333720" URL"~/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1028277/cc2640r2l-runtime-cc2640r2l-stops-executing-functionality ]2. 从无法正常工作的设备下载映像(bin file)并使用 相同的下载 映像重新编程，然后设备重新开始工作。

作为另一个调试点(如果之前的代码无法解决问题)：

您有如下流程：

1. PCB 无法正常工作
2. 从不工作 PCB 上的器件到 BIN 读取闪存
3. 将闪存箱刷写到同一个不工作的 PCB 中
4. 不工作的 PCB 现在可以工作

第4步后、您能否读取闪存并将其与第2步的库进行比较？

如果某个东西在整个电源周期中持续存在、我的原因是这很可能与在整个电源周期中也持续存在的某个东西(例如非易失性闪存)相关。 这里唯一的区别是用于 NVS 的扇区。

如果先前共享的 nvocop.c 文件不起作用、我们首先需要研究器件达到此状态的原因。

尊敬的 Toby：

在我们现有的 SDK 4.20中使用修补程序时，挂起问题似乎已得到解决，但发现设备中的 SNV 区域(扇区-30)已损坏。

我们长期保留了12个器件、11个器件中的 SNV 区域已损坏。

此致、

Bhavin P

对延迟回复表示歉意。

[引用 userid="333720" URL"~/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1028277/cc2640r2l-runtime-cc2640r2l-stops-executing-functionality/3813505 #3813505"]我们保留了12个器件供长期运行[/quot]

器件是否在长期期间复位？

从 nvocop.c 注释：

//*****************************************************************************
// Design Overview
//*****************************************************************************
/*
This driver implements a non-volatile (NV) memory system that utilizes 1 page
of on-chip Flash memory. After initialization, this page is ACTIVE
and GPRAM, or Cache RAM, is available for "compaction" when the ACTIVE page does
not have enough empty space for data write operation. Compaction can occur 'just
in time' during a data write operation or 'on demand' by application request. The
compaction process IS NOT designed to survive a power cycle before it completes.
If power is cycled after the page is erased but before all contents have
been written back to the clean page with the active bit of the page
header set all data stored in this module will be lost. If a power cycle occurs
before in compaction before the page is erased, the process is restarted
during initialization.

Each Flash page has a "page header" which indicates its current state (ERASED,
ACTIVE, or XFER), located at the first byte of the Flash page. The remainder of
the Flash page contains NV data items which are packed together following the
page header. Each NV data item has two parts, (1) a data block which is stored
first (lower memory address), (2) immediately followed by item header (higher
memory address). The item header contains information necessary to traverse the
packed data items, as well as, current status of each data item. A
search for the newest instance of an item is sped up by starting the search at
the last entry in the page (higher memory address).
*/

您能否检查页眉指示什么？

似乎可能会发生压实、但过程会中断(例如欠压)。