请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
器件型号：CC1352P 主题中讨论的其他器件： UNIFLASH
项目状态：
我们在 UBEACON 定位产品中采用 CC1352P 芯片方案作为核心 MCU。 该产品稳定并分批发货。 前期、已经稳定生产了1万多种产品。 约2000次再生产发现三分之一的 Sub1G 15.4问题,具体表现为:
该器件可以正常发送数据、但无法接收其他器件发出的 ACK 信号。 协议堆栈已报告至0xe9 (即无法接收确认信号)。 我们已通过第三方无线封装工具确认 ACK 已发送。
该器件可以正常发送数据、但无法接收其他器件发出的 ACK 信号。 协议堆栈已报告至0xe9 (即无法接收确认信号)。 我们已通过第三方无线封装工具确认 ACK 已发送。
检查过程：
- SKD：simplelink_cc13x2_26x2_SDK_5_20_00_52
- 有问题的芯片、15.4 Sub1G 广播的数据正常
- 对于有问题的芯片、直接通过 RF 接口配置接收模式、可以接收到 SUB1G 的广播数据
- 对于有问题的芯片、把它切换到2.4G 模式、15.4就可以正常工作
- 与之前10,000个产品芯片硬件版本(Chipinfo_gethwrevision)相比、发现早期芯片硬件为2.1、后期芯片硬件版本为2.2
- 存在芯片重复出现问题时出现问题稳定
通过上述调查、确认了低于1G 硬件接收链路和15.4协议栈的功能。 可疑的 CC1352P V2.2硬件版本存在一致的问题。
通过上述检查可以得出结论：15.4 SUB1G 单独的交付链路和单独的接收链路正常，15.4 SUB1G 接收链路可能存在时间-订单问题。 并检查所提供的15.4协议栈部分的15.4协议栈配置(仅具有2.4G 相关时间顺序配置)、但不要找到所有 SUB1G 计时配置(由于未找到15.4 SUB1G 计时配置、因此此处执行了相应的15.4 2.4G 测试)。 :将 ACK 超时修改为原始值的三分之一, 2.4G 也会有同样的问题,即无法接收确认信号)
由于无法配置 SUB1G 的时序、因此此处减小了 CPU、以获得较大的时间阶序。 具体方法为：
- 不要降低 CPU 的主频率
- 关闭 CPU 缓存的缓存机制
通过上述操作、这相当于降低 CPU 的执行速度(CPU 测试减少了50%)、然后进行15.4 SUB1G 通信测试。 发现此时 SUB1G 通信已恢复正常。 版本中存在一致性问题。 这种一致性问题会影响到 SUB1G 的收发器的通信和切换(怀疑低于1G 计时有问题)。
解决方案：
- 为什么 CC1352P 的 V2.2版本中存在 SUB1G 通信问题以及此版本的硬件芯片中可能存在的其他问题？
- 如果15.4 SUB1G 的时序可以恢复正常、如何修改15.4Sub1g 的时序？
附录：
