Regenerated RF Calibration (txpower) for USB8997 with Swapped Antennas (Murata LBEE5XV1YM)

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Regenerated RF Calibration (txpower) for USB8997 with Swapped Antennas (Murata LBEE5XV1YM)

1,088 Views
rikins
Contributor III

Hi NXP Team,

We are using the Murata Type 1YM module (LBEE5XV1YM), which integrates the NXP 88W8997 chipset, connected via USB on our custom board.

We are evaluating the possibility of swapping the antenna connections — assigning ANT_A to WLAN_RF_B and ANT_B to WLAN_RF_A — for specific design reasons. However, we are concerned that such a swap could cause functional instability or crashes in the Wi-Fi module due to mismatches in RF chain mapping, TX power calibration, or gain configuration.

We are using the following driver and firmware package from NXP:

  • mlan.ko and usb8997.ko from NXP_L_USB-USB-8997-U16-X86-W8997-W16.197.121.p1-16.26.121.p1-MXM5X16505.p7.2_V4-GPL
  • Firmware: usbusb8997_combo_v4.bin
As we understand, the firmware blob (usbusb8997_combo_v4.bin) includes pre-calibrated parameters such as RF chain ↔ antenna mapping, PA/LNA gain, and TX power limits. We believe changing the antenna mapping without corresponding changes in the firmware could negatively affect RF performance or system stability.

We are looking for help with the following:
  • Can NXP or Murata assist with regenerating the txpower configuration or firmware blob for a swapped antenna configuration?
  • Alternatively, is there any tooling that we could use under NDA to generate this ourselves?
  • Please let us know what information would be required to support this request.
We would greatly appreciate your guidance on the correct path forward. Thank you!
 
Regards,
Rikin
0 Kudos
Reply
6 Replies

935 Views
rikins
Contributor III

Hi @shaun_wu,

Any comments on these issues?

Rikin

0 Kudos
Reply

649 Views
shaun_wu
NXP TechSupport
NXP TechSupport

Hello @rikins 

 

Sorry for late reply. this case is not an antenna configuration problem. It is more likely a software issue or USB connection issue. We need different experts to support your case. Could you submit a new ticket via salesforce to us with your hardware setup and software details?  

shaun_wu_0-1751445174994.png

 

Best Regards

Shaun

0 Kudos
Reply

1,067 Views
shaun_wu
NXP TechSupport
NXP TechSupport

Hello @rikins 

 

If you just switch antenna no need any operation.

 

Best Regards

Shaun

0 Kudos
Reply

1,052 Views
rikins
Contributor III

Hi @shaun_wu ,

 

Thank you for your response.

We’d like to clarify that our observation is based on swapping the antenna connections on the Murata Type 1YM (LBEE5XV1YM) module using the USB8997 interface. Our setup uses the following components from the NXP-provided GPL package:

  • mlan.ko

  • usb8997.ko

  • Firmware: usbusb8997_combo_v4.bin
    (from NXP_L_USB-USB-8997-U16-X86-W8997-W16.197.121.p1-16.26.121.p1-MXM5X16505.p7.2_V4-GPL)

Observation:

  • When we connect the antennas in the default configuration, the module boots and operates normally.

  • However, when we physically swap the two antenna paths (i.e., antenna A connected to WLAN_RF_B and antenna B connected to WLAN_RF_A), the driver consistently fails during initialization with the following behavior:

    • get_fw_info fails (status = -1)

    • set_mac_address fails (error_code = 0x80000007)

    • A firmware dump is triggered (fw_dump_timer fired)

    • The device begins to report repeated USB disconnection errors (Card is removed: -104)

This failure occurs when the antennas are physically swapped, and it is 100% reproducible.

We are not currently modifying any driver logic or configuration. The only change is at the hardware connection level.

Based on this, we would like to understand:

  • Is this behavior expected if the firmware assumes a fixed RF chain to antenna path mapping?

  • Does the firmware (usbusb8997_combo_v4.bin) include fixed calibration or gain settings that could cause such failures when antenna paths are reversed?

  • If so, is it possible to request a version of the firmware or calibration data that reflects this swapped RF path configuration?

Please let us know if any additional information (e.g., schematic, logs) would help to move this forward.

I want to understand this behavior in the failure case. Why are we getting this issue?

Please refer to the logs below:
```
tx_cmd_urb_pending = 0
tx_data_urb_pending = 0
tx_data2_urb_pending = 0
rx_data_urb_pending = 6
Host:buildroot Timestamp:c254d914
Driver version = USB8997---16.197.121.p1-MX5X16505.p7.2-(FP197)
main_state = 4
ioctl_pending = 1
tx_pending = 0
wmm_tx_pending[0] = 0
wmm_tx_pending[1] = 0
wmm_tx_pending[2] = 0
wmm_tx_pending[3] = 0
rx_pending = 0
lock_count = 79
malloc_count = 8
mbufalloc_count = 7
hs_skip_count = 0
hs_force_count = 0
Media state = "Disconnected"
carrier off
tx queue 0: stopped
tx queue 1: stopped
tx queue 2: stopped
tx queue 3: stopped
mlan0: num_tx_timeout = 0
uap0: num_tx_timeout = 0
p2p0: num_tx_timeout = 0
fw_dump_timer fired.
Start to process hanging
IOCTL failed: c2db4000 id=0x80000, sub_id=0x80001 action=2, status_code=0x80000007
```


Below is the hostapd_2ghz.conf file we are using:
```

ctrl_interface=/var/run/hostapd
interface=uap0
driver=nl80211
ssid=testap
hw_mode=g
channel=6
max_num_sta=10
auth_algs=1
beacon_int=100
dtim_period=1
wmm_enabled=1
ignore_broadcast_ssid=0

# Enable HT (802.11n)
ieee80211n=1
ieee80211d=1
country_code=IN
ieee80211h=1
ht_capab=[HT40+][SHORT-GI-20][SHORT-GI-40][RX-STBC1][TX-STBC][DSSS_CCK-40]

ap_max_inactivity=0

wpa_key_mgmt=WPA-PSK
wpa=2
rsn_pairwise=CCMP
wpa_passphrase=1234567890
own_ip_addr=192.168.2.1


```

0 Kudos
Reply

1,037 Views
shaun_wu
NXP TechSupport
NXP TechSupport

Hello @rikins 

 

Sorry I'm not really understand your point. Did you switch ANT_A and ANT_B? If not so, could you share your hardware design? 

shaun_wu_0-1748416531234.png

 

0 Kudos
Reply

1,031 Views
rikins
Contributor III

Hi @shaun_wu ,

Thanks again for your time.

We wanted to clarify and update you on the issue. Initially, we suspected that swapping the antenna connections (ANT_A ↔ ANT_B) on the Murata LBEE5XV1YM module (USB8997) was causing the firmware crash during Wi-Fi initialization. Based on that assumption, we raised a query regarding possible RF calibration mismatch or gain mapping issues.

However, after further hardware and signal debugging, we now believe the root cause is not related to antenna swapping.

Current Issue (updated):
The USB8997-based Wi-Fi module (Murata Type 1YM) crashes during initialization. (We have seen this often, especially on immediate power off and on.) This happens regardless of whether antennas are swapped or connected normally.

Now, the issues I am facing are a bit tricky.

1. Sometimes, while loading the drivers for the wifi module, it crashes. Below are the error/crash logs
```
wfd_name=p2p
max_vir_bss=1
cal_data_cfg=none
drv_mode = 7
rx_work=0 cpu_num=1
WLAN FW is active
Register NXP 802.11 Adapter mlan0
Register NXP 802.11 Adapter uap0
[streamer_msg] msg_callback() msg_context->pszHost=asc_host, msg_context->pszCmd=ae_get
AE_OPTION_CURR_SHUTTER(0): dwCurrShutter(8808), dwCurrSensorGain(1000), dwCurrISPGain(1000), dwCurrWgtLuma(38)
1.000000
IR OFF Counter: 7
tx_cmd_urb_pending = 0
tx_data_urb_pending = 0
tx_data2_urb_pending = 0
rx_data_urb_pending = 6
Host:buildroot Timestamp:c2cdbb1c
Driver version = USB8997---16.197.121.p1-MX5X16505.p7.2-(FP197)
main_state = 4
ioctl_pending = 1
tx_pending = 0
wmm_tx_pending[0] = 0
wmm_tx_pending[1] = 0
wmm_tx_pending[2] = 0
wmm_tx_pending[3] = 0
rx_pending = 0
lock_count = 79
malloc_count = 8
mbufalloc_count = 7
hs_skip_count = 0
hs_force_count = 0
Media state = "Disconnected"
carrier on
tx queue 0: started
tx queue 1: started
tx queue 2: started
tx queue 3: started
mlan0: num_tx_timeout = 0
uap0: num_tx_timeout = 0
p2p%d: num_tx_timeout = 0
[streamer_msg] msg_callback() msg_context->pszHost=asc_host, msg_context->pszCmd=ae_get
AE_OPTION_CURR_SHUTTER(0): dwCurrShutter(8808), dwCurrSensorGain(1000), dwCurrISPGain(1000), dwCurrWgtLuma(39)
1.000000
IR OFF Counter: 8
[INFO] Wi-Fi AP init complete.
[streamer_msg] msg_callback() msg_context->pszHost=asc_host, msg_context->pszCmd=ae_get
AE_OPTION_CURR_SHUTTER(0): dwCurrShutter(8808), dwCurrSensorGain(1000), dwCurrISPGain(1000), dwCurrWgtLuma(38)
1.000000
IR OFF Counter: 9
fw_dump_timer fired.
Start to process hanging
IOCTL failed: c254b100 id=0x90000, sub_id=0x90001 action=2, status_code=0x80000007
11D: Error setting domain info in FW
11D: Error setting domain info in FW
get fw info failed! status=-1, error_code=0x0
woal_init_priv: get_fw_info failed
Register NXP 802.11 Adapter p2p0
wlan: version = USB8997---16.197.121.p1-MX5X16505.p7.2-(FP197)
[streamer_msg] msg_callback() msg_context->pszHost=asc_host, msg_context->pszCmd=ae_get
AE_OPTION_CURR_SHUTTER(0): dwCurrShutter(8808), dwCurrSensorGain(1000), dwCurrISPGain(1000), dwCurrWgtLuma(39)
Block woal_cfg80211_scan in abnormal driver state
uap0: Skip change virtual intf type on uap: from 3 to 2
```

2. Now we do a delay of 10 seconds for the power-on and power-off cycle, then the chances of getting this crash decrease. But by immediately powering on and off the device, the issue is observed more frequently.

Flow:
1. The board starts
2. Sleep 10 sec
3. insmod mlan.ko
4. insmod usb8997.ko mod_para=murata_wifi_fw/wifi_mod_para.conf fw_name=murata_wifi_fw/usbusb8997_combo_v4.bin
```
wifi_mod_para.conf:

USB8997 = {
        cfg80211_wext=0xf
        wfd_name=p2p
        max_vir_bss=1
        cal_data_cfg=none
        drv_mode=7
}


What has already been tried:
1. auto_fw_reload=1
2. Hard reset the USB8997 on boot up, before loading the driver.

P.S. This is not reproducible every time. This is very unstable. Sometimes I get the issue, and sometimes I don't.

The thing is, I want to conclude this activity and get an RC for this type of behaviour. Your guidance on this matter will be really helpful.

Thanks for your continued support.

Kind regards,
Rikin

0 Kudos
Reply