-
Notifications
You must be signed in to change notification settings - Fork 3k
Add Cypress PSoC 6 targets #9481
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Test suite executed on CY8CPROTO_062_4343W still reports several failures, this is investigated: mbed test -m CY8CPROTO_062_4343W -t GCC_ARM |
@ARMmbed/mbed-os-psa |
* | ||
******************************************************************************** | ||
* Copyright (c) 2017-2018 Cypress Semiconductor. All rights reserved. | ||
* You may use this file only in accordance with the license, terms, conditions, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What license for these files? It's missing in this header (it references user agreement, cant spot any in the wifi bt folder).
There were similar files already integrated, they were released under Apache 2.0
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The low-level PSoC initialization code in Cypress port is generated by ModusToolbox MCU Configurators (unlike FUTURE_SEQUANA port which used PSoC Creator tool). The configurators are being updated to generate code with Apache license header.
I will regenerate the code with latest configurators to apply the new license. No Cypress EULA included in mbed port, this is intended.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@0xc0170: this is addressed now, all BSP code in GeneratedSource is now Apache 2.0.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not convinced the way it was done, i.e. copying all the files for the basic device support is the best option. This will definitely complicate maintenance in the future.
I understand you want to use newer PDL version, but I see no reason why Sequana would not work with it, if the CY8CKIT_062_BLE does. That's basically the same chip. I'm switching between these boards for testing purposes all the time. Just update PDL and be done with it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see that you have removed the "chip" layer from the vendor->family->chip->board hierarchy that I've originally implemented. This greatly increases amount of copy-pasting when one want's to add a new board, as it can be seen even in your commit.
What's motivation behind this?
The desire is to limit the scope of this PR to only add Cypress kits support, but don't break existing SEQUANA boards. Cypress cannot test the SEQUANA targets, due to the limited board availability and different initialization sequence in CM0+ prebuilt images; also the work on _M0 and _PSA targets have not been started. |
There is a valid reason to provide separate device support files per each BSP target (PeripheralNames.h, PeripheralPins.c, PinNames.h, system_psoc6.h/.c, linker scripts, startup assembly and prebuilt CM0+ images). Different Cypress boards have different PSoC 6 MPNs with different FLASH/SRAM layouts (CY8C6XX6, CY8C6XX7, CY8C6XXA) and different hardware dies (PSoC6ABLE2, PSoC6A2M). Each memory layout requires separate set of linker scripts. Each hardware die requires separate startup assembly and prebuilt M0 image. Having this stuff maintained at the family level and selected by extra labels in targets.json would introduce very complex directory, up to the point when the Windows MAX_PATH limit is hit: targets/TARGET_Cypress/TARGET_PSOC6/TARGET_CY8CXX7/TARGET_PSOC6ABLE2/TOOLCHAIN_GCC_ARM/cy8c6xx7_cm4_dual.ld and so on. Everything that can be shared across boards (CMSIS device headers and peripheral drivers) is already in psoc6pdl directory - this is where most development/maintenance happens. |
@vmedcy Ooph, this is quite the PR! While the relevant reviews take a look at this PR, a couple of things.
|
I thought I forgot something.
|
While I'm here, it looks like GitHub noticed something else.
Note: When done correctly, the PR will not have any merge commits in the history. (Sometimes we find that people get merges and rebases confused) |
This is done, rebased against the latest master, absolutely no problem with that (force pushed the PR branch).
This is fully understood. The team still works on getting the full test suite passing.
Attached greentea test results on CY8CKIT_062_WIFI_BT with GCC_ARM 6.3.1, ARM Compiler 5.06 update 6, and IAR Compiler V8.20. Test reports for other PSoC 6 targets will be attached later. There are still several failures reported (tests-mbed_hal-sleep_manager, tests-mbed_hal-sleep, tests-mbed_drivers-lp_timeout, features-feature_ble-targets-target_cordio-tests-cordio_hci-transport): mbedgt: test case results: 3 FAIL / 1 SKIPPED / 615 OK / 1 ERROR Supporting IAR Compiler V7.8 requires extra work: WICED binary drivers were prebuilt with IAR 8, not compatible with IAR 7. Need to investigate possibility to support both IAR 7 and 8. I believe Mbed-os moves to IAR 8 soon, per ARMmbed/mbed-os-5-docs#885. Can you suggest if any IAR 7 related effort is justified at this point of time? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
TARGET_CYW43012/HCIDriver.cpp
and TARGET_CYW4343X/HCIDriver.cpp
are identical. I believe it would be better for maintenance purposes to have a single driver rather than duplicate code.
output_mode(bt_device_wake_name, 0); | ||
output_mode(bt_power_name, 1); | ||
|
||
//output_mode(bt_host_wake_name, 1); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you comment that change ? Is there any reason to keep that code commented ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Removed commented code with the latest update: 8ca1720.
Regarding duplication of HCI implementation: the idea is to design this for extensibility from the beginning.
The pin assignment for CYW43012 and CYW4343X HCI drivers just happens to match for the 4 currently supported boards. In the future, as we add more boards, it may diverge and require different config.
Since CYW43012 has embedded stack mode, as we may add this feature support in future, it may also make the HCIDriver differ from 4343W.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@pan-: the team put more thought on HCI driver design. The driver duplication is now addressed by 6a36183: there is a single driver for CYW4343W and CYW43012 in features/FEATURE_BLE/targets/TARGET_Cypress/TARGET_CYW43XXX. Differences in the implementation are to be handled by constructor argument and json parametrization.
Can you resolve this conversation?
So more work for us, because you want to avoid some, good. You are talking about the Windows path length limit elsewhere, but you are lengthening it for us. |
@vmedcy Few more questions:
|
Avoiding complex nested TARGET_ hierarchies is an explicit goal. I agree this adds a little maintenance overhead (same linker scripts appear in different BSP target folders), but makes things much easier for end users, especially when creating custom BSPs. |
Great!
Yes, CY8CKIT_062_BLE comes with KitProg2 FW, not compatible with mbedls. DAPLink firmware is under development, we flash nightly builds of KitProg3 FW during development/testing. Please suggest the convenient way for you to receive the compatible firmware (requires either special FW upload tool or Bootloader Host Tool supplied with PSoC Creator).
Yes, as well as #9509 I just submitted. To merge all 3 PRs: git fetch origin pull/9481/head:add_cypress_kits
BLE hardware is different in CY8CKIT_062_BLE (using on-chip BLESS instead of WICED connectivity module). It is not supported by the existing port. The FW implementation will be provided in consequent PRs. |
I @vmedcy, thanks for the PR! I'm in the process of reviewing it, but am having trouble viewing diffs with the commit history in its current form. Some of the problems I'm running into when reviewing:
Would it be possible to update the history of this PR to make it easier to review? I made these changes to the history in my fork of mbed-os so feel free to push that directly or with modifications if it is useful to you. The end result is identical, I just broke apart the history to make it easier to review. The updated history can be found in my mbed-os repo on the branch pr9481_history. Commits of my branch:
|
@c1728p9: thank you for reviewing.
Absolutely, I admit the PR is rather hard to review in the web interface. I mishandled the previous interactive rebase (squashed my updates with wrong base commit). Thanks a lot for you work on pr9481_history, indeed it is much easier to review this PR if all Cypress HAL fixes and GeneratedSource updates are separated. I rebased per your suggestions and provided more context in the commit messages. Now the commit history should be coherent. I also included the latest HAL updates from the PDL team. I guess you are mostly focused on this commit: 94c8081. @lrusinowicz: some Cypress HAL updates can also be applicable to FUTURE targets, kindly take a look. |
@cmonr: CapSense and WICED binary drivers were recompiled with IAR 7.8; we temporary switched our internal testing to use this old version (unfortunately there is incompatibility at C++ binary level). Whenever Mbed OS decides to switch to IAR 8, Cypress is ready to provide the new binaries. There is also a great progress on having the greentea test suite pass. Latest result is: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@vmedcy Thank you very much for your understanding! Looks good to me! |
CI started |
Test run: SUCCESSSummary: 12 of 12 test jobs passed |
Actually, I just realised. So I think we should merge this in as it is, do do a separate build of Wiced binaries from master. We still have time before 5.12 to fix that. |
@SeppoTakalo: thanks for letting us know. Since #9568 is already merged to master, is this pull request to be merged to a different branch to appear in 5.11.4, like mbed-os-5.11 or release-candidate? Is it safe to recompile libwiced_drivers.a now with the latest master and expect it to still work in 5.11.4? |
@vmedcy All PRs got to master first and then we select specific ones to get cherry picked across to the release branch. So yes this would go to master first and then across to 5.11 ready for 5.11.4. So this should be fine in that release. As @SeppoTakalo said #9568 is targeting 5.12 so would not get ported across. So this can safely be merged in and go to the release as planned. You don't need to do anything else for now. |
@adbridge: thank you for explanation of release branching, and for PR approval. |
@vmedcy Please hold before building new binaries for feature-iar8 branch (or other branches) We can synch our changes with Multihoming branch, so that we need to rebuild once before 5.12 release. We need new binaries for master for ARM,GCC & IAR. Then we need new binaries for IAR8 and ARMC6. There is now email discussion going between us & Cypress. Lets synch up off-line. |
@SeppoTakalo: this is understood, thanks. It makes sense to reduce the total number of rebuilds (to decrease dev/test effort). |
@vmedcy - feature-iar8 is rebased, can add binaries after all changes for 5.12 are in sync. |
@vmedcy @SeppoTakalo - Any updates on binaries for IAR 8.32? |
I tried to build on See internal ticket https://jira.arm.com/browse/IOTCORE-1051 |
yes all failing targets are explicitly disabled in feature branch. Please enable them in targets.json by removing below 2 lines (will pick default from inherited target)
|
Also please add this change set of targets.json to PR adding the binaries. |
Description
Initial support for Cypress boards at targets/TARGET_Cypress/TARGET_PSOC6.
Added pioneer kits:
Added prototyping boards:
Added connectivity modules:
The pull request is split into multiple commits:
Move existing FUTURE_SEQUANA port to targets/TARGET_Cypress/TARGET_PSOC6_FUTURE
Add Cypress PSoC 6 HAL, latest PDL, support for 4 board targets and 4343W connectivity module.
Add mbedtls target providing alternate implementation for PSoC 6 crypto hardware.
Add BLE HCI drivers for CYW43012 and CYW4343W.
Add WICED connectivity drivers compiled for all supported boards and toolchains.
Pull request type
Related pull requests
PSOC6.py updates: #9466 #9509
platform database update: ARMmbed/mbed-os-tools#110
Reviewers
@0xc0170 @lrusinowicz @orenc17