NRF51_DK incorrect detection on Windows 10 x64

[andrewleech]

Hi, I'm trying to run mbed test on my windows 10 development machine against a standard NRF51_DK board. In 1.4.4 and 1.4.3 it's being detected as:

+---------------+----------------------+-------------+-------------+--------------+-----------------+
| platform_name | platform_name_unique | mount_point | serial_port | target_id    | daplink_version |
+---------------+----------------------+-------------+-------------+--------------+-----------------+
| LPC2368       | LPC2368[0]           | K:          | COM3        | 000681078661 | unknown         |
+---------------+----------------------+-------------+-------------+--------------+-----------------+

That target id is also visible in device manager under the Parent property as USB\VID_1366&PID_1015\000681078661 In code it's pulled from the volume_string in find_candidates() Where volumestring = `u'??_USBSTOR#Disk&Ven_SEGGER&Prod_MSD_Volume&Rev_1.00#8&2ee71873&0&000681078661&0#{53f56307-b6bf-11d0-94f2-00a0c91efb8b}'`

I've traced the detection to looking at the first 4 characters in target_id and mapping that in the json database to "0006": "LPC2368"

mbed_lstools/lstools_base.py:143 platform_data = self.plat_db.get(device['target_id_usb_id'][0:4], verbose_data=True)

In 1.4.2 it comes up as unknown. It's unknown all the way back to 1.3.3, 1.3.2 doesn't run due too logging import error then 1.3.1 doesn't detect any device.

1.2.16 detects my board perfectly, though the current mbed-greentea won't run against this old a version of mbedls.

+---------------+----------------------+-------------+-------------+--------------------------------------------------+-----------------+
| platform_name | platform_name_unique | mount_point | serial_port | target_id                                        | daplink_version |
+---------------+----------------------+-------------+-------------+--------------------------------------------------+-----------------+
| NRF51_DK      | NRF51_DK[0]          | K:          | COM3        | 1100021852333120343935373230322031323033AFD4DFD8 | unknown         |
+---------------+----------------------+-------------+-------------+--------------------------------------------------+-----------------+

It's pulling target_id from the htm which is the correct ID, [0:4] == 1100

[bridadan]

Hi @andrewleech, thanks for reporting the issue, we'll take a look.

Can you give us a little more information?

1. The output of mbedls --debug
2. What interface firmware is running on the board? stock? JLink? DAPLink?
3. Can you give me a list of all filenames on the device? [Mirrored to Jira]

[bridadan]

I was able to reproduce this with a JLink flashed NRF51_DK, so I'm assuming that's the configuration you have for now. [Mirrored to Jira]

[andrewleech]

It's stock configuration which is a composite interface segger host chip providing jlink, com port and mass storage. The mass storage has mbed.htm, user guide.htm and (iirc) segger.htm The user guide does have a nordic URL which could be used the same way as the nrf52 one in the jlink section of the parts db however I think my patch implementation will provide compatibility for more existing boards. [Mirrored to Jira]

[theotherjimmy]

@bridadan Could you retest with the new jlink firmware detection? [Mirrored to Jira]

[bridadan]

I can't for the life me get an nrf51 flashed with the JLink software for whatever reason. I already have a test case for the nrf52 running jlink here: https://github.com/ARMmbed/mbed-ls/tree/master/test/test_data/nrf52_dk_jlink

I think we can be reasonably confident its also working for the nrf51, considering they share the same JLink firmware. [Mirrored to Jira]

[andrewleech]

Sorry I don't have an nrf51_dk any more, moved onto different projects [Mirrored to Jira]

[theotherjimmy]

Thanks for trying guys! [Mirrored to Jira]

[bridadan]

Just tried to reproduce this at my desk, but everything seems to be working now, so closing this.