Hi Guys,
当使用子板DA14585-01ATDB-P-P 1718_00182时，我们最近遇到了一个奇怪的问题，因为它崩溃了，尝试从SDK 6.0.4.326（目前是我们知识最新的最新的BLE应用程序时，它崩溃了。但是，电路板从旧的SDK 6.0.2.243运行相同的应用程序，没雷竞技安卓下载有问题。
Then we designed and made a few prototypes of our own board based on the same DA14585 in the same package (Digikey part num 1564-1047-1-ND). After being connected via JTAG to the DA14580DEVKIT it is successfully recognised as DA14585. However, our boards are failing to run BLE applications from the older SDK 6.0.2.243 yet they don’t immediately crash with applications from the latest SDK 6.0.4.326 (BLE apps with sleep enabled crash a few seconds later but it is a topic for a different discussion).
Searching for a crash reason we discovered that the hard fault is caused by arch_rom_init() by the following line of code:
// Mandatory HCI root table setup
memcpy（hci_cmd_desc_root_tab，rom_hci_cmd_desc_root_tab，48）;
…这给人一个印象,两个ICsof the same type in the same package have different revisions of ROM where the BLE stack actually resides. Besides, each ROM revision requires an appropriate SDK and there is no actual check anywhere which would help to detect discrepancy between ROM revision and SDK.
Can you confirm that our understanding on the issue is correct and if so, how to address it? In particular, how to deal with it when it comes to mass production knowing that there are ICs with the same labels in the same packages but still containing different ROM versions. Is there any way to retrieve ROM version? And why there are multiple versions of SDK compatible with a specific ROM version only, why those complexities are not hidden by one generic SDK?
Thank you,
德米特里
Hi dmitryp,
Yes, your understanding is correct, currently there are two revisions of the 585 SoC on the market (normally there should be one, the latest, but apparently there are leftovers from the previous SoC revision). So the latest chip revision is the AC which runs along with the SDK 6.0.4 and the one that your daughterboard is equiped is AB revision which runs only with the SDK 6.0.2. If you try to run a different SDK on a AB or on an AC silicon, that will result in a hardfault. So as mentioned, the latest revision is AC which will be out in the market and will run with all the current (except SDK 6.0.2) and future SDK's.
谢谢mt_dialog.
Thank you for the prompt response. However, two questions still remain, could you please answer them?
1.如何识别IC是否是Revision AB或AC立即？
2. How the issue is going to be addressed in the future? The world around us is not static and it is inevitably that sooner or later there will be revision AD and so on. How to deal with this variety in production if there is no way to distinguish them?
Thank you,
德米特里
Hi dmitryp,
谢谢mt_dialog.
Hi Guys,
Exactly right, the part number is the same and this is what causes us grief. We had to look through a microscope to read the number and even then it was barely visible. After all, visual identification is an extremely inconvenient thing when it comes to automation of a manufacturing process. Before assembled PCBAs can be flashed with firmware there should be a better way of identification, better than a visual inspection through a microscope. As for the plans of releasing a new revision of the 585, it is only true in an ideal world. In real life the content of ROM is a binary blob which represents software (or rather firmware). Every piece of software always contains bugs and it is just a matter of time when some of them will be discovered. Nobody plans for bugs, they are just found either by an accident or more thorough testing. So it is just a matter of time when a new version of ROM will be released and then we will have the same problem again.
Is there any better way to identify ROM revision, by reading it electronically? How about this one, by reading the following SoC registers:
- CHIP_ID1_REG, CHIP_ID2_REG, CHIP_ID2_REG ('Chip identification registers') which contain 0x35, 0x38 and 0x35 accordingly (which translates from ASCII code into 585),
- chip_revision_reg（'芯片修订寄存器'）包含0x41，转换为'a'，
- CHIP_SWC_REG（'软件兼容性寄存器'）包含旧芯片的“0”，最近的“1”，看起来它是ROM修订，“B”和“C”。
The registers are readable to a user app and can be read through JTAG by sending a command through JLink (SEGGER) command line interface, both ways have been already tested and confirmed.
Is our interpretation correct?
Thank you,
德米特里
Hi dmitry,
正如我已经提到的那样，我几乎不认为将有一个未来的SoC版本，以便修复错误（通过新的SDK版本和补丁处理ROM代码中的错误，而不是通过SOC的更新版本处理）。一种有效的方式，讲述SOC的SOC的硅版本应该读取的地址0x5000320A，高字节始终为0x20，低字节保持较小版本0x01对应于B，0x02对应于C版本。
谢谢mt_dialog.