• 状态
  • 已锁定 已锁定
  • 回复 9 回复
  • 订户 0 订户
  • 视图 290 视图
  • 用户 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.

[参考译文] CCS/CC2650：OAD 后 OSAL_SNV_WRITE 问题

admin
Guru**** 2593480 points
Other Parts Discussed in Thread: CC2650, BLE-STACK

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

https://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/601427/ccs-cc2650-issue-with-osal_snv_write-after-an-oad

器件型号：CC2650
Thread 中讨论的其他器件： BLE-STACK

工具/软件：Code Composer Studio

早上好、

我们使用 CC2650生产了1000个 PCB、并使用以下器件开发了固件：

  • 编译器版本 TI v5.2.6
  • TI-RTOS 2.13.0.06
  • BLE 堆栈 v2.1.1
  • 在我们的 FW 中、我们具有：
    • OSAL_SNV=1
    • GAP_BUK_Mgr
    • 图元_OAD

我们使用  BLE_NVID_CUST_START 0x80中的内部闪存页0x1D000-0x1F000、使用 osal_SNV_write/read API 将我们需要的一些值存储在非易失性存储器中。

我们发现在 OAD 之后、 osal_SNV_write API 返回成功   、但在下电上电后、osal_SNV_read 不返回成功。

相反、如果在 OAD 之后我们执行另一个循环通电、则所有操作都正常、 osal_SNV_write/read 都将返回成功、并且我们可以在非易失性存储器工作正常的情况下执行所需的所有循环通电。

在一个 OAD 之后、内部闪存看起来像是被锁定或者处于某种保护模式。 通过 JTAG 手动闪存后、我们看到了相同的行为：我们需要另一个下电上电周期才能正确使用非易失性存储器。

您能不能告诉我们我们我们是否可以对此问题采取行动？ 非常感谢您的支持。

此致、

Simone Frau

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

    OSAL_SNV=1 (单页 SNV)存在异常、在该异常中、SNV 数据页在初始软件编程后的首次器件复位后被擦除。 这在 BLE-Stack v2.2.1中得到了解决。 您是否确认在 OAD 之后保留了您的数据？ 是否在 OAD 期间更新 SNV 页面？ 我们没有使用 BLE-Stack v2.1.x 测试修复程序、但如果您观察到这种现象、您可能会从2.2.1版本中挑选 nvocop.c/h 文件。

    此外、如何启动器件复位？

    供参考、您列出了一个8kB 范围(2个闪存页)、其中包含0x1D000-0x1F000；我认为这只是一个拼写错误。

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

    首先、非常感谢您的快速回答。 我可以确认问题仅在于 OSAL_SNV=1。 我们更改为2、非易失性存储器工作正常。 遗憾的是、我们的 FW 的某些配置相当大、我们需要使用 OSAL_SNV=1来节省存储器(将来我们将使用新的 CC2640R2来增加闪存、但这对于已经投入生产的 PCB 来说不是一个选项)。

    我尝试了2.2.1版本中 nvocop.c/h 文件中的更改、但这些更改不起作用。 也许我可以将更改以私人方式发送给您、然后您可以确认更改。

    我们不需要在 OAD 期间保留数据、但在 OAD 之后、如果我们可以开始直接将数据存储在非易失性存储器中、而无需执行另一次复位、那将是很好的。 为此、我们现在使用此 API：

    SysCtrlSystemReset()；

    它工作正常、但我们希望避免它。 我们还可以尝试其他操作吗？

    非常感谢您的支持。

    此致、


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

    您能否描述使用 OSAL_SNV=1而不是2的副作用？

    您在第一次器件复位后谈到了异常、在软件指南中、您提到了压缩期间的功率损耗问题以及由于暂时禁用高速缓存而导致的性能下降。

    您是否了解其他信息？

    感谢您的支持。
    此致、

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

    我假设您已经阅读了软件开发指南(SWRU393)中 OSAL_SNV=1与2的说明、因此我不会重复。

    BLE-Stack 2.2.1中解决了唯一已知的异常 w.r.t OSAL_SNV=1、以解决首次执行程序后数据丢失的问题。

    您是否在 OAD 之后检查了 SNV 的内容？ 您应该能够使用 SmartRF Flash Programmer 2进行提取并与代码进行比较。

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

    您好、JXS、

    您能帮我从 SmartRF 闪存编程器2中提取 SNV 的内容吗？

    我假设使用 OSAL_SNV=1、我必须读取第30页(来自0x1E000)、但内容如下：

    我刚刚在 BLE_NVID_CUST_END  0x8F 位置写入了一个字节= 0xAB 、但存在某种编码。 使用此工具、我无法读取一个分配存储器的确切内容...

    此致、

    Simone Frau

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

    您好、Simone、

    要读取 NV 闪存、请首先查找 ID、后跟长度。 然后、从 id 中向后移动长度指定的字节数。 我标记了您的图像、以显示您的值被写入的位置。

    似乎写入的值是可以的。 从日志中、看起来有多个复位。 您能否在第一次复位后显示内容？

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

    感谢您的回答、现在我可以看到我的价值。 我能否请您解释一下您如何看到多个复位？

    这些复位在我们的系统中是正常的、因为为了面临丢失 SNV 存储器中保存的值的问题、我们在初始化期间进行了检查。 基本上，我们写入此0xAB 字节，然后我们第一次重新启动，在第二次初始化时，我们检查该值是否为该值，否则我们第二次重新启动(两次都使用 SysCtrlSystemReset())。 通常我们有三个初始化、我会要求您的同事 JXS 向我推荐其他解决方案。

    无论如何、一切都在正常工作、但遗憾的是、在第一次复位后很难为您提供 SNV 存储器的内容、因为正如我所解释的、 这是由软件完成的、我不知道何时在重置过程中使用 SmartRF 闪存编程器2 ...
  • 0
    TI__Guru**** 2593480 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    您好、Simone、


    我在 SmartRF 闪存编程器2的日志中看到了复位。 您是否关注我们的软件开发人员指南中的示例？ 在发生故障的情况下、osal_SNV_WRITE 函数的返回值是多少？

    您能否确认您对 nvocop.c 进行了 JXS 先前建议的更改？

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

    我可以在 SmartRF 闪存编程器2的日志中看到复位指示、但这只是不幸的巧合、在刷写之后、我读取器件的 BLE MAC 地址。 这就是日志中出现这些消息的原因。 实际上、在初始化期间看不到 FW 的内部复位、因为这对我来说有点奇怪。

    失败情况下 osal_SNV_WRITE 函数的返回值为 Success = 0、这就是我需要写入一个字节并在复位后检查该值的原因。 如果我没有执行任何复位、osal_SNV_WRITE 和 osal_SNV_read 函数看起来工作正常(返回值和读取值正确)、但事实并非如此、因为如果我移除电源、我会丢失数据。 这只是第一次发生、这意味着什么？ 这意味着、如果在一个 OAD 之后我执行另一个复位、并且从那一刻起我开始使用 SNV 存储器、那么一切都正常运行(也是在几个断电之后)。

    我尝试了 JXS 的建议、但它们不起作用。 实际上、BLE-Stack v2.2.1和 v2.1.x 中的 nvocop.c 之间的差异是最小的。 是否确定此版本中的修复程序不是其他版本中的修复程序？

    非常感谢您的支持。

    此致、


    Simone Frau