Skip to content

Remove ITM from NRF52_DK and DELTA_DFBM_NQ620 targets #9767

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

Merged
merged 1 commit into from
Feb 21, 2019
Merged

Remove ITM from NRF52_DK and DELTA_DFBM_NQ620 targets #9767

merged 1 commit into from
Feb 21, 2019

Conversation

TacoGrandeTX
Copy link
Contributor

The NRF52_DK and DELTA_DFBM_NQ620 have the SWO pin (p0_18) mapped to LED2. This means that on startup LED2 turns on after the ITM is initialized which is confusing. Since most users want LED2 usage
instead of SWO we remove the ITM for these targets.

The nRF52 readme is updated to instruct users how to get SWO support if they need it.

This addresses #9695

Description

By default LED2 is now off on startup and ITM/SWO functionality can be regained by bringing in ITM through mbed_app.json as documented in updated nRF52 readme:

    "target_overrides": {
        "*": {
            "target.device_has_add": ["ITM"]
        }
    }

Tested that LED2 is now off on entry to main() and SWO capability can be brought back in through mbed_app.json.

Pull request type

[ ] Fix
[ ] Refactor
[x] Target update
[ ] Functionality change
[ ] Docs update
[ ] Test update
[ ] Breaking change

Reviewers

@dlfryar @pan-

The NRF52_DK and DELTA_DFBM_NQ620 have the SWO pin (p0_18) mapped to
LED2. This means that on startup LED2 turns on after the ITM is
initialized which is confusing. Since most users want LED2 usage
instead of SWO we remove the ITM for these targets.

The nRF52 readme is updated to instruct users how to get SWO support
if they need it.
@ciarmcom ciarmcom requested review from dlfryar-zz, pan- and a team February 19, 2019 22:01
@ciarmcom
Copy link
Member

@TacoGrandeTX, thank you for your changes.
@dlfryar @pan- @ARMmbed/mbed-os-maintainers please review.

Copy link
Member

@pan- pan- left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you know if NRF52840_DK is impacted ?

@0xc0170
Copy link
Contributor

0xc0170 commented Feb 20, 2019

CI started

@TacoGrandeTX
Copy link
Contributor Author

@pan- On the nRF52840 SWO is mapped to pin P1.00 and it can also be a GPIO. Luckily on the DK board this pin isn't tied to anything and it just goes to header P24.

@mbed-ci
Copy link

mbed-ci commented Feb 20, 2019

Test run: SUCCESS

Summary: 12 of 12 test jobs passed
Build number : 1
Build artifacts

Copy link
Contributor

@dlfryar-zz dlfryar-zz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1 looks good

@cmonr
Copy link
Contributor

cmonr commented Feb 20, 2019

#9767 (comment)

@pan- All good?

@pan-
Copy link
Member

pan- commented Feb 21, 2019

@TacoGrandeTX If I look at the pin mapping of the nRF52840_DK; it appears that BUTTON3 is also mapped on P0.24. Is there any side effect we should consider ?

@TacoGrandeTX
Copy link
Contributor Author

@pan- We don't have any contention for the buttons and LEDs on the nRF52840_DK, so we're good with those pins. If we were concerned about external ETM trace then they would lose Button 1 and Button 2 on P0.11 and P0.12 but that's all I see in the nRF52840 Product Spec.

@cmonr
Copy link
Contributor

cmonr commented Feb 21, 2019

@pan- I think we're good to merge. Let us know if that isn't the case.

@cmonr cmonr merged commit 01aeb48 into ARMmbed:master Feb 21, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants