Prevent detect_targets.py tool script from crashing on known targets

[daid]

As mut['mcu'] can be "None" on unknown targets, the detect_targets script crashes when one of these boards is connected.

This happens when "mbed-cli detect -vv" is ran when a STEVAL-3DP001V1 board is connected. Which does not provide a html file with a target_id, and thus cannot be looked up in the mbedls platform database.
http://www.st.com/en/evaluation-tools/steval-3dp001v1.html

Notes:

• Pull requests will not be accepted until the submitter has agreed to the contributer agreement.
• This is just a template, so feel free to use/remove the unnecessary things

Description

A few sentences describing the overall goals of the pull request's commits.

Status

READY/IN DEVELOPMENT/HOLD

Migrations

If this PR changes any APIs or behaviors, give a short description of what API users should do when this PR is merged.

YES | NO

Related PRs

List related PRs against other branches:

branch	PR
other_pr_production	link
other_pr_master	link

Todos

• Tests
• Documentation

Deploy notes

Notes regarding the deployment of this PR. These should note any required changes in the build environment, tools, compilers and so on.

Steps to test or reproduce

Outline the steps to test or reproduce the PR here.

[mbed-ci]

User not whitelisted, CI not run.

[cmonr]

@daid I'm not sure I like that solution, since my impression is that all mbed-enabled board should have some sort of html or info on the MSD interface used to identify it.

@c1728p9 I'm wondering if this is because the interface is STLINKV2. Is it possible that ST didn't include the files for this particular board in the firmware?

As a side note, looks like a fun board!

[daid]

Indeed, there is only a txt file, not the htm file on this board, which includes an STLINKV2 on the board itself.

mbedls is also giving this warning because of it:
WARNING:mbedls.lstools_base:Could not read htm on from usb id 0670FF545250777267104334. Falling back to usb id

Else I would have contributed the proper id to the board database, but I don't think usb ids are proper stable identifiers for boards (I haven't look if this id changes between the 3 STEVAL-3DP001V1 boards we have)

I'm also not entirely sure if this is the correct fix, but this at least prevented the code from crashing, and list the board as incompatible with all default targets.
A different fix would be to detect this case earlier in the code, drop the board from the list and emit a warning that a mock needs to be setup with mbedls

[daid]

Just dropping by to say that our other STEVAL-3DP001V1 boards indeed have other identifiers, and thus adding it to the mbedls list is not an option.

The question here remains, should mbedls prevent giving None as ['mcu'] or should mbed-os be able to handle this None (as I did in this pull request)

[theotherjimmy]

@daid I think this is an acceptable solution. The Mbed LS API does not have an "mcu" key, so I think this is the correct factoring.

[cmonr]

/morph build

[cmonr]

Odd.

/morph build

[0xc0170]

/morph build

[mbed-ci]

Build : SUCCESS

Build number : 1147
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/6000/

Triggering tests

/morph test
/morph uvisor-test
/morph export-build

[mbed-ci]

Exporter Build : SUCCESS

Build number : 822
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/exporter/6000/

[mbed-ci]

Test : SUCCESS

Build number : 953
Test logs :http://mbed-os-logs.s3-website-us-west-1.amazonaws.com/?prefix=logs/6000/953