Skip to content

Conversation

@cvinayak
Copy link
Contributor

@cvinayak cvinayak commented Jan 15, 2021

Added nRF21540 FEM support for nRF52x and nRF53x Series.

Thanks to @bjornspock for the FEM contributions and @auroraslb for the DPPI refactoring.

image

Fixes #24142.

Contains cherry-picked commit from @auroraslb PR: #30732

@carlescufi
Copy link
Member

@cvinayak this FEM configuration needs to be in Devicetree, not in Kconfig. @KAGA164 might have some input here.

@carlescufi carlescufi requested a review from KAGA164 February 18, 2021 12:42
@KAGA164
Copy link

KAGA164 commented Feb 18, 2021

I agree with @carlescufi the FEM hardware configuration like pins should be in the device tree. We already have bindings for the nRF21540 FEM in the Zephyr. Also the FEM configuration is added to the nrf21540dk_nrf52840 dts file

and . I would like to add also a support for nrf21540EK which is currently in the PR #31523 but it seems to be blocked because we have only use case for it in the NCS not in the Zephyr. The BLE Controller should automatically enable support for FEM if its configuration is in the devicetree then we could easy build samples for nrf21540dk and also when the EK shield is used we could enable it when west build is invoked

@cvinayak
Copy link
Contributor Author

@carlescufi and @KAGA164 This PR is collection of other authors works. I do not have the knowledge or time in the near future to rework, there is already a related issue #30708, if someone wants to work on it, they can use this PR as base and add commits to port to DTS macros.

@carlescufi
Copy link
Member

@auroraslb or @KAGA164 could you please pick this up and rework it accordingly?

@mbolivar-nordic
Copy link
Contributor

@auroraslb or @KAGA164 could you please pick this up and rework it accordingly?

@carlescufi does that mean I should not work on #30708? Just clarifying.

@cvinayak
Copy link
Contributor Author

@carlescufi This PR is relatively big in terms of feature support, should be reviewed as-is and merged. The DT porting should be addressed in #30708, which can be done by @mbolivar and I can assist in its review and testing.

Hope the functional changes in this PR gets some reviews, else this is now entering the merge conflicts due to other PRs modifying the files common to this PR.

@cvinayak cvinayak closed this Mar 1, 2021
@cvinayak cvinayak deleted the github_nrf21540_support branch March 1, 2021 00:33
@cvinayak cvinayak restored the github_nrf21540_support branch March 1, 2021 00:54
@cvinayak cvinayak reopened this Mar 1, 2021
@cvinayak cvinayak marked this pull request as draft March 1, 2021 00:55
@carlescufi
Copy link
Member

@auroraslb or @KAGA164 could you please pick this up and rework it accordingly?

@carlescufi does that mean I should not work on #30708? Just clarifying.

Sorry for the delay. No, apparently no one is working on that, so you can feel free to pick that up in fact.

@cvinayak cvinayak force-pushed the github_nrf21540_support branch from 0e4563f to 66caaaf Compare March 31, 2021 09:48
@cvinayak cvinayak marked this pull request as ready for review March 31, 2021 09:48
Copy link
Contributor

Choose a reason for hiding this comment

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

The commit log says the motivation is "so that DPPI 0-4 available for application's use" -- where is that going to be documented?

More generally, PPI values seem like something that should be moved into DT, since they are boot time hardware configuration values. Another benefit would be that users could override this macro with an overlay as they desire.

Would you agree? If so, that also would solve the documentation problem if there is no existing doc, because the pages in the DT bindings index would be the docs.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The commit log says the motivation is "so that DPPI 0-4 available for application's use" -- where is that going to be documented?

I thought this would document it:

/** @brief Bitmask that defines PPI channels that are reserved for use outside of the nrfx library. */

PPI values seem like something that should be moved into DT

Agree.

(Just thinking aloud, PPI/DPPIs and other peripherals are used by controller at scheduled time periods, they can but are not currently been used outside the Zephyr controller. nRF Connect SD controller based application do use outside the controller's scheduled time periods).

Copy link
Contributor

Choose a reason for hiding this comment

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

Forgive my ignorance, but are these Kconfig options being copy/pasted from somewhere else for a different SoC?

If not, they should definitely be in DT instead, along with the polarity (since we have the GPIO_ACTIVE_LOW flag in DTS), CSN pin, etc.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I am not against use of DT, it is just that original controller contribution was before use of DT, and not all of controller has been ported to DT use.

they should definitely be in DT

Agree. As a subsequent PR, please do work on the port.

Copy link
Contributor

Choose a reason for hiding this comment

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

This looks like a copy/paste error.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

yes. Will fix it.

Copy link
Contributor

Choose a reason for hiding this comment

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

Here too?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

yes, will fix it.

@cvinayak cvinayak requested a review from mbolivar-nordic April 2, 2021 00:58
@cvinayak cvinayak force-pushed the github_nrf21540_support branch from 66caaaf to 82a5532 Compare April 3, 2021 01:47
@carlescufi
Copy link
Member

@mbolivar-nordic @anangl @rugeGerritsen @KAGA164 could you please review?

@cvinayak cvinayak added the Enhancement Changes/Updates/Additions to existing features label Apr 6, 2021
Copy link
Contributor

@mbolivar-nordic mbolivar-nordic left a comment

Choose a reason for hiding this comment

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

Looks OK to the best of my limited ability to review. I'll take on conversion of pin Kconfigs to DT as follow up PRs.

Copy link
Member

Choose a reason for hiding this comment

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

... PDN pin.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done

Copy link
Member

Choose a reason for hiding this comment

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

Perhaps it would be good to mention what's the unit of this value?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

done

Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
#define NRF_GPIO_CSN_PIN ((CONFIG_BT_CTLR_GPIO_PA_PIN) - 32)
#define NRF_GPIO_CSN_PIN ((CONFIG_BT_CTLR_GPIO_CSN_PIN) - 32)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done

Comment on lines 196 to 197
Copy link
Member

Choose a reason for hiding this comment

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

These channels should be added to HAL_USED_PPI_CHANNELS, similarly to how it is done for the PA/LNA ones: https://github.com/zephyrproject-rtos/zephyr/blob/82a55328ccc96abeff252dc63e73b3577973abf0/subsys/bluetooth/controller/ll_sw/nordic/hal/nrf5/radio/radio_nrf5_dppi.h#L582-L588

Same applies to the corresponding change in radio_nrf5_ppi.h.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

done

Comment on lines 196 to 197
Copy link
Member

Choose a reason for hiding this comment

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

It looks like it should be:

Suggested change
#define HAL_ENABLE_FEM_PPI 4
#define HAL_DISABLE_FEM_PPI HAL_ENABLE_PALNA_PPI
#define HAL_ENABLE_FEM_PPI 4
#define HAL_DISABLE_FEM_PPI HAL_ENABLE_FEM_PPI

Otherwise, the PDN and CSN pins will be toggled on NRF_TIMER_EVENT_COMPARE3 and NRF_RADIO_EVENT_DISABLED but also on NRF_TIMER_EVENT_COMPARE2 (what would be different from the PPI version) as this event is published to the same channel.

Copy link
Contributor Author

@cvinayak cvinayak Apr 20, 2021

Choose a reason for hiding this comment

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

yes, you are right, this would not work. I need to discuss with @bjornspock

The solution was simple reusing existing GPIOTEs, but an additional DPPI... The implementation for PA/LNA will be same as before, when not using FEM then will use GPIOTE OUT Task Toggle mode. With FEM, GPIOTE SET and CLR task will be used for each GPIO PIN, i.e. 1 DPPI for PA or LNA. 1 for PDN+CSN and 1 to CLR all three GPIO on Radio Disable.

@cvinayak cvinayak force-pushed the github_nrf21540_support branch from 82a5532 to 1d21721 Compare April 20, 2021 12:52
@carlescufi carlescufi requested a review from anangl April 20, 2021 15:21
@cvinayak cvinayak force-pushed the github_nrf21540_support branch from 1d21721 to cb86e59 Compare April 20, 2021 16:09
Copy link
Contributor Author

@cvinayak cvinayak left a comment

Choose a reason for hiding this comment

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

@anangl please re-review.

Copy link
Member

@anangl anangl left a comment

Choose a reason for hiding this comment

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

LGTM now.

cvinayak and others added 6 commits April 21, 2021 06:58
Adjust the PPI used by nRF53x so that DPPI 0-4 available
for application's use.

Signed-off-by: Vinayak Kariappa Chettimada <[email protected]>
Ported the GPIO PA/LNA support for nRF53x by using a DPPI
channel.

Fixes zephyrproject-rtos#24142.

Signed-off-by: Vinayak Kariappa Chettimada <[email protected]>
Added correct SOC_NRF5340_CPUNET pin range for
BT_CTLR_GPIO_PA_PIN and BT_CTLR_GPIO_LNA_PIN.

Signed-off-by: Bjørn Spockeli <[email protected]>
Signed-off-by: Vinayak Kariappa Chettimada <[email protected]>
Added Kconfig options for nRF21540 PDN and CSN pins.

Signed-off-by: Bjørn Spockeli <[email protected]>
Signed-off-by: Vinayak Kariappa Chettimada <[email protected]>
Added GPIO control for nRF21540 CSN and PDN lines.

Signed-off-by: Bjørn Spockeli <[email protected]>
Signed-off-by: Vinayak Kariappa Chettimada <[email protected]>
Added nRF21540 FEM support for nRF52x Series.

Signed-off-by: Bjørn Spockeli <[email protected]>
Signed-off-by: Vinayak Kariappa Chettimada <[email protected]>
@cvinayak cvinayak force-pushed the github_nrf21540_support branch from cb86e59 to 440fc6f Compare April 21, 2021 01:29
@carlescufi carlescufi merged commit 9c871fb into zephyrproject-rtos:master Apr 21, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area: Bluetooth Controller area: Bluetooth Enhancement Changes/Updates/Additions to existing features

Projects

None yet

Development

Successfully merging this pull request may close these issues.

NRF5340 PA/LNA support

6 participants