Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs

Using a nRF21540 with a nRF54l15

Hi,

We currently have a custom board with a nRF54L15 (final production silicon) paired up with a nRF21540 RF front-end module (FEM). This board is running Zephyr with v2.9.0 of the Nordic SDK. We have gotten bluetooth advertising to work with both the Nordic softdevice link layer as well as with the Zephyr link layer (without the FEM). However, we are struggling now to get the nRF21540 FEM to work. We have tried to both use the GPIO only and SPI + GPIO configuration without success. We are able to get both configurations to build, but they both end up in hard faults during the mpsl_init. For the former configuration we get:

[00:00:08.380,040] <err> os: ***** HARD FAULT *****
[00:00:08.380,044] <err> os:   Fault escalation (see below)
[00:00:08.380,049] <err> os: ARCH_EXCEPT with reason 3

[00:00:08.380,057] <err> os: r0/a1:  0x00000003  r1/a2:  0x00000000  r2/a3:  0x00000001
[00:00:08.380,063] <err> os: r3/a4:  0x00000003 r12/ip:  0x00000000 r14/lr:  0x0002055d
[00:00:08.380,067] <err> os:  xpsr:  0x09000000
[00:00:08.380,071] <err> os: Faulting instruction address (r15/pc): 0x00038994
[00:00:08.380,088] <err> os: >>> ZEPHYR FATAL ERROR 3: Kernel oops on CPU 0
[00:00:08.380,103] <err> os: Current thread: 0x20009248 (main)
[00:00:08.649,432] <err> os: Halting system
[00:00:22.952,814] <err> mpsl_init: MPSL ASSERT: 120, 29


And for the latter configuration we get
[00:00:11.531,105] <err> os: >>> ZEPHYR FATAL ERROR 4: Kernel panic on CPU 0
[00:00:11.531,124] <err> os: Current thread: 0x200083d8 (main)
[00:00:12.644,767] <err> os: Halting system
ASSERTION FAIL [0] @ WEST_TOPDIR/nrf/subsys/mpsl/init/mpsl_init.c:299
	MPSL ASSERT: 121, 29

[00:00:00.000,769] <err> os: ***** HARD FAULT *****
[00:00:00.000,775] <err> os:   Fault escalation (see below)
[00:00:00.000,781] <err> os: ARCH_EXCEPT with reason 4

[00:00:00.000,793] <err> os: r0/a1:  0x00000004  r1/a2:  0x0000012b  r2/a3:  0x00000002
[00:00:00.000,800] <err> os: r3/a4:  0x00000004 r12/ip:  0x00000000 r14/lr:  0x00036027
[00:00:00.000,806] <err> os:  xpsr:  0x29000000
[00:00:00.000,812] <err> os: Faulting instruction address (r15/pc): 0x0004cd8a


Our DTS looks like this (SPI + GPIO configuration):
    nrf_radio_fem: fem {
		compatible = "nordic,nrf21540-fem";
		status = "okay";
		tx-en-gpios =  <&gpio1 11 GPIO_ACTIVE_HIGH>;
		rx-en-gpios = <&gpio1 12 GPIO_ACTIVE_HIGH>;
		pdn-gpios = <&gpio1 5 GPIO_ACTIVE_HIGH>;
		spi-if = <&nrf_radio_fem_spi>;
		supply-voltage-mv = <1800>;
	};
	
	&radio {
	    status = "okay";
	    fem = <&nrf_radio_fem>;
    };

&spi00 {
	status = "okay";
	compatible = "nordic,nrf-spim";
	cs-gpios = <&gpio0 2 GPIO_ACTIVE_LOW>, <&gpio2 5 GPIO_ACTIVE_LOW>, <&gpio2 3 GPIO_ACTIVE_LOW>;
	pinctrl-0 = <&spi00_default>;
	pinctrl-1 = <&spi00_sleep>;
	pinctrl-names = "default", "sleep";

	nrf_radio_fem_spi: nrf21540_fem_spi@0 {
		compatible = "nordic,nrf21540-fem-spi";
		status = "okay";
		reg = <0>;
		spi-max-frequency = <8000000>;
	};
	... spi node 1 ...
	... spi node 2 ...
};

&gpiote20 {
	status = "okay";
};

&gpiote30 {
	status = "okay";
};

&dppic20 {
	status = "okay";
};

&dppic30 {
	status = "okay";
};


Kconfig (SPI + GPIO configuration):
CONFIG_MPSL=y
CONFIG_MPSL_TIMESLOT_SESSION_COUNT=1
CONFIG_MPSL_FEM=y
CONFIG_NRFX_GPIOTE20=y
CONFIG_NRFX_GPIOTE30=y
CONFIG_NRFX_DPPI20=y
CONFIG_NRFX_DPPI30=y
#CONFIG_MPSL_FEM_NRF21540_GPIO=y
CONFIG_MPSL_FEM_NRF21540_GPIO_SPI=y


Our custom board is pretty configurable, so we are able to use different pins for the nRF21540 if necessary. 

Parents Reply Children
No Data
Related