嗨,伙计们,
最近，我们在使用DA14585-01ATDB-P 1718_00182子板时遇到了一个奇怪的问题，因为它在试图从SDK 6.0.4.326(目前是我们所知的最新版本)运行任何BLE应用程序时崩溃了，出现了硬故障。然而，该板运行来自旧SDK 6.0.2.243的相同应用程序没有问雷竞技安卓下载题。
然后，我们设计并制作了一些基于DA14585的原型板(Digikey部分num 1564-1047-1-ND)。在通过JTAG连接到DA14580DEVKIT之后，它被成功识别为DA14585。然而，我们的主板无法运行来自旧SDK 6.0.2.243的BLE应用程序，但它们不会在雷竞技安卓下载最新SDK 6.0.4.326的应用程序中立即崩溃(启用睡眠功能的BLE应用程序会在几秒钟后崩溃，但这是另一个讨论的话题)。
在搜索崩溃原因时，我们发现硬错误是由arch_rom_init()引起的，代码如下:
//强制设置HCI根表
memcpy (hci_cmd_desc_root_tab rom_hci_cmd_desc_root_tab 48);
．．.这给人一种印象，即同一包中相同类型的两个ic具有不同的ROM版本，而BLE堆栈实际驻留在ROM版本中。此外，每个ROM版本都需要一个合适的SDK，并且没有任何实际的检查来帮助检测ROM版本和SDK之间的差异。
你能否证实我们对这一问题的理解是正确的?如果是，如何解决?特别是，在批量生产时，如果知道在同一封装中有相同标签的ic，但仍然包含不同的ROM版本，该如何处理。有没有办法检索ROM版本?为什么有多个版本的SDK只与特定的ROM版本兼容，为什么这些复杂性没有被一个通用的SDK隐藏?
谢谢你！
德米特里•
设备:
嗨dmitryp,
是的，你的理解是正确的，目前市场上有两个版本的585 SoC(通常应该有一个，最新的，但显然有前一个版本遗留下来的SoC)。所以最新的芯片版本是AC，它与SDK 6.0.4一起运行，而你的子板所配备的是AB版本，它只与SDK 6.0.2一起运行。如果您尝试在AB或AC硅上运行不同的SDK，将会导致硬故障。如前所述，最新的版本是AC，它将在市场上发布，并将与所有当前(除了SDK 6.0.2)和未来的SDK一起运行。
由于MT_dialog
感谢您的及时回复。但是还有两个问题，你能回答一下吗?
1.现在如何识别一个IC是AB版本还是AC版本?
2.未来这个问题将如何解决?我们周围的世界不是静止的，不可避免的是迟早会有修正等等。如果在生产中没有办法区分，该如何处理这个品种呢?
谢谢你！
德米特里•
嗨dmitryp,
由于MT_dialog
嗨,伙计们,
完全正确，零件号是一样的，这就是导致我们悲伤的原因。我们必须通过显微镜才能看清这些数字，但即使在显微镜下也几乎看不见。毕竟，当涉及到制造过程的自动化时，视觉识别是一件极其不方便的事情。在组装好的PCBAs可以与固件一起闪烁之前，应该有一个更好的识别方法，比通过显微镜的视觉检查更好。至于发布新版585的计划，这只是在一个理想的世界里。在现实生活中，ROM的内容是一个表示软件(或者说是固件)的二进制blob。每个软件都有漏洞，发现其中一些漏洞只是时间问题。没有人会计划漏洞，它们只是在意外或更彻底的测试中发现的。所以这只是一个时间问题，当一个新的ROM版本将被发布，然后我们将再次遇到同样的问题。
有什么更好的方法来识别ROM修订，通过电子阅读它?这个怎么样，通过读取以下SoC寄存器:
- CHIP_ID1_REG, CHIP_ID2_REG, CHIP_ID2_REG('芯片标识寄存器')相应包含0x35, 0x38和0x35(从ASCII码转换为585)，
- CHIP_REVISION_REG ('Chip revision register')包含0x41，转换为'A'，
- CHIP_SWC_REG('软件兼容性寄存器')包含'0'用于旧芯片，'1'用于最近的芯片，看起来它是ROM版本，相应的'B'和'C'。
这些寄存器对于用户应用程序来说是可读的，并且可以通过JLink (SEGGER)命令行接口发送命令来读取JTAG，这两种方式都已经经过测试和确认。
我们的解释正确吗?
谢谢你！
德米特里•
嗨德米特里,
正如我已经提到的，我几乎不相信会有SoC的未来版本来修复bug (ROM代码中的bug是通过新的SDK发行版和补丁来处理的，而不是通过SoC的更新版本)。一个有效的方法告诉什么是SoC的硅版本，你应该读地址0x5000320A，高字节总是0x20和低字节保持保持小版本0x01对应于B和0x02对应于C版本。
由于MT_dialog