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

[Vidar Berg]

Hi Benno,

The developer who was trying to reproduce your problem here pointed out that you have to turn off the DEBUG ENABLE switch if measuring on the AUDIO DK:

To test with the diff, we have to make sure we compile the code with adding --nrf21540 in the end

$ python buildprog.py -c both -d gateway -b debug -p --pristine --nrf21540

So the build system will involve the nrf21540_ek_fwd.overlay and forwarding the GPIO control permission to network core.

Before we measure the signal on nRF5340 audio DK, we have to turn off the "DEBUG ENABLE" switch, otherwise P1.10 will be pull down to low since it is connected to J-Link chip.

The current controller won't send anything through UART pins, so we still can use those pins for controlling FEM

And would be great if customer can share the compiled DTS from nrf/applications/nrf5340_audio/build/dev_gateway/build_debug/zephyr/zephyr.dts

So the DEBUG switch should explain why PDN stayed low in your case. 

P0.30 is a bit tricky, it is exposed on TP59 here:

Are you able to provide the generated device tree file (zephyr.dts) as the developer requested?

Thanks,

Vidar

[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