Hi Guys,
We recently encountered a strange problem when using a daughter board DA14585-01ATDB-P 1718_00182 as it crashes with a hard fault in attempt to run any BLE application from SDK 6.0.4.326 (which is currently the latest to the best of our knowledge). However, the board runs the same applications from the older SDK 6.0.2.243 without issues.
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.
你能确认我们理解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,
Dmitry
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.
Thanks MT_dialog
Thank you for the prompt response. However, two questions still remain, could you please answer them?
1. How to identify whether an IC is of a revision AB or AC right now?
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,
Dmitry
Hi dmitryp,
Thanks 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 ('Chip revision register') contains 0x41 which translates into 'A',
- CHIP_SWC_REG ('Software compatibility register') contains '0' for old chips and '1' for the most recent, looks like it is the ROM revision, 'B' and 'C' accordingly.
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,
Dmitry
Hi dmitry,
As i ve allready mentioned, i hardly believe that there will be a future version of the SoC in order for bugs to be fixed (bugs in the ROM code are dealed through new SDK releases and patches and not via newer revisions of the SoC). A valid way of telling what is the silicon version of the SoC you should read the address 0x5000320A, the high byte is always 0x20 and the low byte holds the holds the minor version 0x01 corresponds to B and 0x02 corresponds to C version.
Thanks MT_dialog