Wi-Fi and BLE coexistence settings for nRF5340DK + nRF7002EK in 2.8+

Dear DevZone,

I would appreciate your assistance in understanding how to correctly configure Wi-Fi and BLE coexistence for the nRF5340DK and nRF7002EK with SDK version 2.8 and later. I'm using the BLE provisioning sample from version 2.8 as my reference. In the prj.conf file, I see that CONFIG_NRF70_SR_COEX and CONFIG_NRF70_SR_COEX_RF_SWITCH are both set to yes. I understand that CONFIG_NRF70_SR_COEX includes the C:\ncs\v2.8.0\zephyr\drivers\wifi\nrfwifi\src\coex.c file in the build, and CONFIG_NRF70_SR_COEX_RF_SWITCH enables the use of srrf-switch-gpios. However, I am curious about the function of this pin in this hardware setup, especially since it was not present in versions prior to 2.8.

Upon examining the nRF7002 device tree and schematic, I noticed that this pin is connected to the QSPI_DATA2 pin, which doesn’t seem like it would control an RF switch.

Additionally, I am puzzled by the nrf7002ek_coex.overlay file, which was previously included in the overall 7002EK overlay. Does this overlay still apply to this particular hardware configuration? Based on your documentation, I believe this overlay is intended for the netcore of the 5340. However, the EK's nrf5340dk_nrf5340_cpuapp.overlay disables the GPIO forwarder, suggesting that the netcore cannot access any GPIOs. In earlier versions, the coexistence node was included in the device tree of the 5340's application core, which is probably something that is not needed? 

Thank you very much for your help!

Best Regards,

Ladivin

  • Hi, 

    CONFIG_NRF70_SR_COEX_RF_SWITCH would enable GPIO configuration to control SR side RF switch position in the firmware, such as this code https://github.com/nrfconnect/sdk-nrf/blob/v2.8.0/samples/wifi/thread_coex/src/main.c#L53-L61 

    EK's nrf5340dk_nrf5340_cpuapp.overlay disables the GPIO forwarder, suggesting that the netcore cannot access any GPIOs. In earlier versions, the coexistence node was included in the device tree of the 5340's application core, which is probably something that is not needed? 

    Explanation of why this was done is already documented in the overlay file you mentioned. The UART1 pins are reused by nRF70's BUCKEN and IOVDD control pins.

     

    /* This node by default forwards the UART1 pins to CPUNET, but as UART1 uses
    * same pins as bucken and iovdd-ctrl, we need these pins to be controlled by
    * the CPUAPP. Since a child node of gpio_fwd cannot be disabled, hence
    * the entire node is disabled. If the application needs to forward other pins
    * to the CPUNET, it should create a separate instance of nrf-gpio-forwarder
    * and use it instead.
    */

    Regards,
    Amanda H.

Related