Wrong nRF21540 signals on custom board

RE: Wrong nRF21540 signals on custom board

Benno Trutmann — Wed, 03 May 2023 13:59:23 GMT

Hi Vidar.

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

Thanks,
Benno

RE: Wrong nRF21540 signals on custom board

Vidar Berg — Tue, 02 May 2023 07:08:50 GMT

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;
}

RE: Wrong nRF21540 signals on custom board

Vidar Berg — Fri, 28 Apr 2023 15:08:08 GMT

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.

RE: Wrong nRF21540 signals on custom board

Vidar Berg — Fri, 28 Apr 2023 14:05:35 GMT

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

RE: Wrong nRF21540 signals on custom board

Benno Trutmann — Fri, 28 Apr 2023 13:12:34 GMT

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

RE: Wrong nRF21540 signals on custom board

Benno Trutmann — Fri, 28 Apr 2023 12:16:39 GMT

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:

devzone.nordicsemi.com/.../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

RE: Wrong nRF21540 signals on custom board

Vidar Berg — Fri, 28 Apr 2023 09:45:58 GMT

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

RE: Wrong nRF21540 signals on custom board

Benno Trutmann — Thu, 27 Apr 2023 13:19:31 GMT

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

RE: Wrong nRF21540 signals on custom board

Vidar Berg — Wed, 26 Apr 2023 07:18:27 GMT

Hi Benno,

[quote user=""]so I put SPI_CS fix to high and SPI_SCK, SPI_MOSI, SPI_MISO fix to low):[/quote]

There might be some conflict here as the MODE pin (P1.13) is the same pin that is being assigned to the SPI MISO by default. Though I am not sure where the conflict could be considering the BT controller is only using the GPIO control interface.

We tried to reproduce this by applying the patch below, but the control signals were correct in our case. Could you try please try with the same changes on your side?

devzone.nordicsemi.com/.../fem_5F00_test.diff

Thanks,

Vidar

RE: Wrong nRF21540 signals on custom board

Benno Trutmann — Tue, 25 Apr 2023 12:38:52 GMT

Hi Vidar.

I could see a conflict on P0.30 and P1.10. But why is the MODE signal on P1.13 affected also?

Yes, I use SDK v2.3.0.

At the moment the code in ble_core.c you mentioned, is already commented out (rgb2_green and rgb2_red do not exist on our board). What if I map PAL_LED_ID_CPU_ACTIVE and PAL_LED_ID_ERROR to unused GPIO, could that change the behavior?

Anyway, if there is a conflict of GPIO configurations between our board and ble5-ctr-rpmsg_3330.hex, how can we solve that (beside changing our board of course)?

Regards,
Benno

RE: Wrong nRF21540 signals on custom board

Vidar Berg — Tue, 25 Apr 2023 12:16:17 GMT

Hi Benno,

I think you are onto something. One of our developers also pointed out that that there was someoverlap in your pin assignments. Are you using SDK v2.3.0 or another version with ble5-ctr-rpmsg_3330.hex?

Thanks,

Vidar

Edit: could you please try to comment the controller_leds_mapping() line at

https://github.com/nrfconnect/sdk-nrf/blob/a948046c0a7797fac9ea572be5ca46f4b78dbda1/applications/nrf5340_audio/src/bluetooth/ble_core.c#L167 as a test?

RE: Wrong nRF21540 signals on custom board

Benno Trutmann — Mon, 24 Apr 2023 13:58:20 GMT

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

RE: Wrong nRF21540 signals on custom board

Vidar Berg — Mon, 24 Apr 2023 12:13:27 GMT

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