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

[Benno Trutmann]

Hi Vidar.

I could not reproduce your results with the patches you provided. I applied the patches to the original LE audio sample code and measured the nRF21540 signals on the nRF5340 Audio DK, but without connecting the shield. I measured the following:

• PDN signal on P1.10 is fixed low
• MODE signal on P1.13 has 6 positive 91us pulses every 10ms
• ANT_SEL signal on pin P0.31 has a 3.84ms positive pulse every 10ms interrupted by 5 negative 15us pulses
• TX_EN signal on P0.30 I could not measure because it is only routed to RGB2_LED
• RX_EN signal on P1.12 is fixed low but with strong noise (interference from SPI CS?)

Because P1.10 could collide with a netcore UART signal I re-mapped the PDN signal to P1.14, and because I could not measure P0.30 I re-mapped the TX_EN signal to P1.00. Now I measured the following:

• PDN signal on P1.14 has 6 positive 56us pulses every 10ms
• MODE signal on P1.13 has 6 positive 91us pulses every 10ms
• ANT_SEL signal on pin P0.31 has a 3.84ms positive pulse every 10ms interrupted by 5 negative 15us pulses
• TX_EN signal on P1.00 is fixed low
• RX_EN signal on P1.12 is fixed low but with strong noise

P1.14 has now exact the waveform of the TX_EN signal of the original LE audio sample, but it is mapped to the ble_hci_vs_cp_nrf21540_pins.pdn field in ble_core.c. Equally P1.13 corresponds to the PDN signal but is mapped to the ble_hci_vs_cp_nrf21540_pins.mode field and P0.31 corresponds to the MODE signal, but is mapped to the ble_hci_vs_cp_nrf21540_pins.antsel field.

My conclusion:

• At least P1.10 (but probably P0.30 also) cannot be used as a nRF21540 signal.
• The vendor specific HCI command HCI_OPCODE_VS_CONFIG_FEM_PIN is differently interpreted on the controller side and therefore the signal mapping gets mangled.

Can you agree with my conclusions?

Is it possible to provide us with a controller image, which correctly maps the nRF21540 signals and the netcore UART and LED signals do not interfere with the nRF21540 signals?

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