mbed test with dual core targets

[jeromecoutant]

Summary of changes

mbed test -m
is using mbedls result to detect the correct plugged target on host.

There is an issue with dual core chips,
because 2 different targets exist in the targets.json file for the same HW

Patch proposal:

• remove _CM4 and _CM7 before detect HW

@MarceloSalazar

Impact of changes

Migration actions required

Documentation

---

Pull request type

[x] Patch update (Bug fix / Target update / Docs update / Test update / Refactor)
[] Feature update (New feature / Functionality change / New API)
[] Major update (Breaking change E.g. Return code change / API behaviour change)

---

Test results

Tested with a beta version of STLinkFW supporting hex format

[] No Tests required for this change (E.g docs only update)
[x] Covered by existing mbed-os tests (Greentea or Unittest)
[] Tests / results supplied as part of this PR

---

Reviewers

---

[ciarmcom]

@jeromecoutant, thank you for your changes.
@ARMmbed/mbed-os-tools @ARMmbed/mbed-os-maintainers please review.

[0xc0170]

Can you amend the commit message to explain there how remove _CM4 and _CM7 before detect HW this fixes the problem?

That is also my question. Looking at the code change, I do not fully understand how removing these suffixes solves the dual core test issue (what is the actual issue there).

[jeromecoutant]

OK

Behind DISCO_H747I target, there are in fact 2 sub-targets, CM4 and CM7 targets.
Both DISCO_H747I_CM4 and DISCO_H747I_CM7 are defined in targets.json, in order to make application for 1 core or the other.

From USB connection point of view, there is only 1 cable.
Binary file drag and drop feature is flashing CM7 side. That's why, in targets.json, DISCO_H747I is an alias to DISCO_H747I_CM7.

From mbedls point of view, and then greentea tests point of view, DISCO_H747I is defined.

• so testing DISCO_H747I will work on CM7
• testing DISCO_H747I_CM7 will not work, even if it is the same
• testing DISCO_H747I_CM4 will not work, as binary file drag and drop is not implemented for CM4

Coming soon: hex format drag and drop feature
=> means that we will be able to execute greentea tests on both CM4 and CM7.
Conditions is this PR, ie to detect DISCO_H747I when user is requesting DISCO_H747I_CM4 or _CM7

[mark-edgeworth]

@jamesbeyond might have a view on this as it seems to affect test code only. I am not in favour of arbitrarily stripping parts of a device ID as this implies the ID is compound. There should be a better way of implementing boards with multiple build targets...

[jamesbeyond]

@jamesbeyond might have a view on this as it seems to affect test code only. I am not in favour of arbitrarily stripping parts of a device ID as this implies the ID is compound. There should be a better way of implementing boards with multiple build targets...

Hi @mark-edgeworth, I think this is not only related to tests. this is related to builds API as well.

If I recalled the correctly, this is the exact case like what we been discussed in the new mbed devices demo. DISCO_H747I is the board name, and DISCO_H747I_CM4 or DISCO_H747I_CM7 can be considered as build targets, which are different MCUs on the same board

The old tool couldn't handle and clarify them very well. I hope the new tool could take those use cases into consideration.

[jamesbeyond]

as for this PR, I am OK with the changes, because there is no better option to do it on the current tools.

[mark-edgeworth]

Yes, this is the same problem, and it is being considered in the new build tools.

[0xc0170]

CI started

[mbed-ci]

Test run: FAILED

Summary: 1 of 6 test jobs failed
Build number : 1
Build artifacts

Failed test jobs:

• jenkins-ci/mbed-os-ci_greentea-test

[adbridge]

Failure is unrelated so restarting CI

[mbed-ci]

Test run: FAILED

Summary: 1 of 6 test jobs failed
Build number : 2
Build artifacts

Failed test jobs:

• jenkins-ci/mbed-os-ci_greentea-test

[0xc0170]

Tests have an issue, we are investigating

[0xc0170]

test restarted