Update Cypress targets

[morser499]

Description (required)

Update Cypress targets to be more uniform and reduce what is configured by default to allow more flexibility within mbed.

Summary of change (What the change is for and why)

Regenerated code with latest tools/PDL library
Made PinNames/PeripheralNames reuse existing defines
Remove unneeded peripheral configuration in target design files

Documentation (Details of any document updates required)

---

Pull request type (required)

[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 (required)

[] 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

CY8CKIT_062_WIFI_BT-GCC_ARM.txt
CY8CKIT_062S2_43012-GCC_ARM.txt
CY8CPROTO_063_BLE-GCC_ARM.txt
CYW943012P6EVB_01-GCC_ARM.txt
CY8CKIT_062_BLE-GCC_ARM.txt

NOTE: Failures are due to #11879 and a known incompatibility between the sleep tests and our UART driver.

---

Reviewers (optional)

---

Release Notes (required for feature/major PRs)

Summary of changes

Impact of changes

Migration actions required

[ciarmcom]

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

[0xc0170]

Merge branch 'opm_target_updates' into 'pr-dev/target-update' …

Why is this commit needed, should this just be rebased instead and this PR would contain just one commit updating targets?

[0xc0170]

Regenerated code with latest tools/PDL library
Made PinNames/PeripheralNames reuse existing defines
Remove unneeded peripheral configuration in target design files

Add this to the commit msg at least. A question is why these are not 3 commits but all in one? It's difficult to review ~330 files changed in one commit.

[bulislaw]

Ah I see why you used components, as we have two cores and code needs to be build either for M0 or M4. Can we use target for that?

Uhm I'm pretty sure I added a review before but I can't find it now... It went something like:

I don't like using components in this way, the original meaning was for external HW components (features were for SW modules). Can you use macros.

That being said macros aren't the option if you want to use the build system to exclude directories, but for the core selection you can use target.

[morser499]

Regenerated code with latest tools/PDL library
Made PinNames/PeripheralNames reuse existing defines
Remove unneeded peripheral configuration in target design files

Add this to the commit msg at least. A question is why these are not 3 commits but all in one? It's difficult to review ~330 files changed in one commit.

Cleaned up the commit history by breaking items into multiple commits.

[morser499]

Ah I see why you used components, as we have two cores and code needs to be build either for M0 or M4. Can we use target for that?

Uhm I'm pretty sure I added a review before but I can't find it now... It went something like:

I don't like using components in this way, the original meaning was for external HW components (features were for SW modules). Can you use macros.

That being said macros aren't the option if you want to use the build system to exclude directories, but for the core selection you can use target.

We don't want to promote using the CM0 core. The CM4 is intended for general development. The CM0 should only be used in very special cases. Based on that we are providing the code to allow doing it but it has most functionality disabled.

[0xc0170]

@morser499 Why was components chosen? Can we update to use targets?

[0xc0170]

Waiting for component update as asked above

[bulislaw]

Hm I still don't get why it needs to be done via COMPONENT, if you remove the cores from target.json components fields and rename your directories from COMPONENT_CM0P to TARGET_M0P and similar for M4 it should just work.

[morser499]

Our reason for choosing component is that we use this same code in our stand alone reference flow as used here. In that flow we used a number of the same concepts as are done in mbed. However, we have more restrictions on what we consider a TARGET. In our stand alone flow TARGET is used specifically to refer to the board that a user would purchase. This is what defines key parameters for the build process. We use COMPONENT_ to represent any other code that needs to be conditionally included.

[0xc0170]

I started CI meanwhile

[mbed-ci]

Test run: FAILED

Summary: 3 of 4 test jobs failed
Build number : 1
Build artifacts

Failed test jobs:

• jenkins-ci/mbed-os-ci_build-ARM
• jenkins-ci/mbed-os-ci_build-IAR
• jenkins-ci/mbed-os-ci_build-GCC_ARM

[0xc0170]

Failures look related

[Error] ESP8266Interface.cpp@62,12: use of undeclared identifier 'D1'
[Error] ESP8266Interface.cpp@62,34: use of undeclared identifier 'D0'

Please review

[bulislaw]

Hm Ok fair enough.I'm not so worried about it as this change only touches Cypress code and doesn't introduce global components, but need to highlight it's not what Mbed would consider a component. For once our build system can do something without hacking it which should be noted :)

That being said we are looking into replacing our current build system with cmake soonish, so the concepts of magic directory names will go away.

[0xc0170]

This should be in CI today (set to 5.15)

[morser499]

Failures look related

[Error] ESP8266Interface.cpp@62,12: use of undeclared identifier 'D1'
[Error] ESP8266Interface.cpp@62,34: use of undeclared identifier 'D0'

Please review

Fix incorrect tag in targets.json. The CY8CPROTO-064-SB board does not have an Arduino header. It was incorrectly put there as part of CI shield testing.

updated

[mbed-ci]

Test run: SUCCESS

Summary: 11 of 11 test jobs passed
Build number : 2
Build artifacts