Wrong nRF21540 signals on custom board

[Benno Trutmann]

Hi.

I try to activate the nRF21540 on a custom board, based on the nRF5340 Audio sample in BIS gateway configuration. I tested the sample code on the nRF5340 Audio DK with the nRF21540 EK shield. In this configuration the sample works and the relevant nRF21540 signals look as below:

On our custom board the nRF21540 signals are on different nRF5340 pins and therefore I added the following to our board device tree (the nRF21540 SPI signals are not used by the sample code, so I put SPI_CS fix to high and SPI_SCK, SPI_MOSI, SPI_MISO fix to low):

    gpio_fwd: nrf-gpio-forwarder {

        compatible = "nordic,nrf-gpio-forwarder";

        status = "okay";

        nrf21540-gpio-if {

            gpios = <&gpio0 30 0>,  /* tx-en-gpios   TP26 */

                <&gpio1 12 0>,      /* rx-en-gpios   TP20 */

                <&gpio1 10 0>,      /* pdn-gpios     TP19 */

                <&gpio0 31 0>,      /* ant-sel-gpios TP27 */

                <&gpio1 13 0>;      /* mode-gpios    TP21 */

        };

    };

But with this configuration the nRF21540 signals look totally different and there is almost no RF signal (< -80dBm):

Without nRF21540 our board streams audio correctly.

How do I get our board working with nRF21540?

Regards,
Benno

[Vidar Berg]

Hello,

I don't see anything wrong with the overlay you posted. Can you please try to place a breakpoin at ble_hci_vsc_nrf21540_pins_set() in ble_core.c to verify that it is reached? This is the HCI command to make the controller configure the FEM control pins.

Thanks,

Vidar

[Benno Trutmann]

Hi Vidar.

Yes, ble_hci_vsc_nrf21540_pins_set() gets called.

The LE audio controller part (ble5-ctr-rpmsg_3330.hex) uses also some additional GPIO for UART and LED. I removed the corresponding nrf-gpio-forwarder sections (uart and leds) in the device tree of our board. But two of these GPIO (P0.30 and P1.10) are used on our board as nRF21540 signals and get therefore forwarded (see device tree snippet above).

Could this lead to a conflict in the controller?

Regards,
Benno

[Benno Trutmann]

Hi Vidar.

I built your test case with the following west command:

$ west build --build-dir build_src --pristine --board nrf5340_audio_dk_nrf5340_cpuapp -- -DCONFIG_AUDIO_DEV=2 -DCONFIG_TRANSPORT_BIS=y -DCONF_FILE=prj.conf -DSHIELD=nrf21540_ek_fwd

Here is the zephyr.dts file:

8764.zephyr.dts

I will look at P1.10 again with disabled "DEBUG ENABLE" and P0.30  on TP59.

Nevertheless what about the signal swap on P1.13 and P0.31? The MODE signal should be mapped to P1.13, but P1.13 shows the  PDN signal and the ANT_SEL should be mapped to P0.31, but P0.31 shows the  MODE signal.

Regards,
Benno

[Benno Trutmann]

Hi Vidar.

I measured now again with disabled "DEBUG ENABLE" and TX_EN on TP59:

Now PDN and MODE signals look correct and this time on the correct pins also (no swapping anymore???). But TX_EN still looks wrong (compare with TX_EN from the first picture of this thread)!

Regards,
Benno

[Vidar Berg]

Hi Benno,

You are right, the timing seems off on TX_EN. The developer said he was going to repeat the test and capture logic trace to see if we might be seeing the same. I will update the ticket as soon as I have more details to share.

Regards,

Vidar

[Vidar Berg]

Update: The developer seems to have found the problem, but it looks like it might require a new controller release to fix, unfortunately. Turns out the controller had LED indications enabled on P0.28-31. These should not have been enabled in the release.

He's currently investigating whether there may be a workaround for this.

[Vidar Berg]

A workaround while waiting for a new controller release is to map the LED indication to an unused pin:

Please suggest customer to modify the controller_leds_mapping() to:

static int controller_leds_mapping(void)
{
    int ret;
       ret = ble_hci_vsc_led_pin_map(PAL_LED_ID_CPU_ACTIVE,
                                     PAL_LED_MODE_DISABLE_TOGGLE,
                                    10 /*pick one unused pin from network, e.g., */);
    return 0;
}

[Benno Trutmann]

Hi Vidar.

Indeed mapping the net-cpu LED signal to an unused pin fixed the problem with TX_EN.

Thanks,
Benno