mwifiex crashing at times when it is instantiated at boot taking out USB as well

Technical Support
1

The mwifiex appears to be crashing at times when it is instantiated at boot or when its module is unloaded and reloaded. It seems to also take out USB functionality as well. Has this been seen before?

Toradex Verdin AM62
BSP 6
TDX Wayland with XWayland 6.6.0-devel-20250822120705+build.0 (kirkstone) verdin-am62-15285136 -
Verdin-AM62_Reference-Multimedia-Image

root@verdin-am62-15415542:~# [ 1437.699784] bash (2697): drop_caches: 1
[ 1438.192485] mwifiex_sdio mmc2:0001:1: info: MWIFIEX VERSION: mwifiex 1.0 (16.92.21.p84)
[ 1438.201334] mwifiex_sdio mmc2:0001:1: info: MWIFIEX VERSION: mwifiex 1.0 (16.92.21.p84)
[ 1438.212425] mwifiex_sdio mmc2:0001:1: info: MWIFIEX VERSION: mwifiex 1.0 (16.92.21.p84)
[ 1438.220858] mwifiex_sdio mmc2:0001:1: info: MWIFIEX VERSION: mwifiex 1.0 (16.92.21.p84)
[ 1438.252428] Internal error: synchronous external abort: 0000000096000210 [#1] PREEMPT SMP
[ 1438.260624] Modules linked in: rfcomm af_alg pru_rproc irq_pruss_intc btnxpuart pvrsrvkm(O) crct10dif_ce snd_soc_simple_card snd_soc_simple_card_utils mwifiex_sdio panel_lvds mwifiex ti_k3_r5_remoteproc virtio_rpmsg_bus rtc_ti_k3 rpmsg_ns cfg80211 bluetooth ti_k3_m4_remoteproc ti_k3_common tidss ecdh_generic ecc drm_dma_helper rfkill drm_kms_helper snd_soc_davinci_mcasp syscopyarea sysfillrect snd_soc_ti_udma sysimgblt fb_sys_fops mcrc sa2ul snd_soc_ti_edma snd_soc_ti_sdma pruss lm75 m_can_platform m_can optee_rng can_dev pwm_bl spi_omap2_mcspi rng_core pwm_tiehrpwm fuse drm drm_panel_orientation_quirks ipv6
[ 1438.314537] CPU: 3 PID: 2446 Comm: grep Tainted: G           O       6.1.46+git.278a5418c2ba #1
[ 1438.323220] Hardware name: Toradex Verdin AM62 WB on Verdin Development Board (DT)
[ 1438.330774] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 1438.337723] pc : __memcpy_fromio+0x48/0xa0
[ 1438.341826] lr : ti_sci_debug_show+0x24/0x44
[ 1438.346091] sp : ffff80000bccbbb0
[ 1438.349394] x29: ffff80000bccbbb0 x28: 0000000000000001 x27: 0000000000400cc0
[ 1438.356521] x26: 000000007ffff000 x25: ffff0000016b37b8 x24: ffff0000016b37a8
[ 1438.363646] x23: 0000000000000000 x22: ffff80000bccbc50 x21: ffff80000bccbc78
[ 1438.370774] x20: ffff000000d89080 x19: ffff0000016b3780 x18: 0000000000000000
[ 1438.377899] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000
[ 1438.385024] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000
[ 1438.392149] x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000
[ 1438.399274] x8 : 0000000000000002 x7 : ffff800076bc7000 x6 : 0000000000000fe0
[ 1438.406399] x5 : ffff000001c9e000 x4 : ffff80000936d000 x3 : ffff000000d11060
[ 1438.413524] x2 : 0000000000000fe0 x1 : ffff80000936d000 x0 : ffff000000d10080
[ 1438.420652] Call trace:
[ 1438.423094]  __memcpy_fromio+0x48/0xa0
[ 1438.426836]  seq_read_iter+0x1b4/0x4b0
[ 1438.430580]  seq_read+0x88/0xc4
[ 1438.433713]  full_proxy_read+0x60/0xb4
[ 1438.437460]  vfs_read+0xc4/0x2a4
[ 1438.440683]  ksys_read+0x6c/0xfc
[ 1438.443902]  __arm64_sys_read+0x1c/0x30
[ 1438.447729]  invoke_syscall+0x48/0x114
[ 1438.451473]  el0_svc_common.constprop.0+0xd4/0xfc
[ 1438.456168]  do_el0_svc+0x20/0x30
[ 1438.459474]  el0_svc+0x28/0xa0
[ 1438.462527]  el0t_64_sync_handler+0xbc/0x140
[ 1438.466788]  el0t_64_sync+0x18c/0x190
[ 1438.470447] Code: aa0103e4 927df0c6 910020c6 8b060003 (f9400085)
[ 1438.476530] ---[ end trace 0000000000000000 ]---


Message from syslogd@verdin-am62-15415542 at Jul 10 14:50:02 ...

kernel:[ 1438.252428] Internal error: synchronous external abort: 0000000096000210 [#1] PREEMPT SMP



Message from syslogd@verdin-am62-15415542 at Jul 10 14:50:02 ...

kernel:[ 1438.470447] Code: aa0103e4 927df0c6 910020c6 8b060003 (f9400085)type or paste code here
2

Hi, I’m the Toradex AI Assistant.

I might make mistakes. Our support team will step in if needed. If I answered your question, please tick the “Solution” checkbox. For follow-up questions to me, please use @ToradexAI in your post.

Did you like my answer? :+1: :-1:

Yes, mwifiex driver crashes on Verdin AM62 have been reported before. Based on the available documentation, this is a known issue with the mwifiex_sdio driver on Toradex platforms.

Known mwifiex Driver Issues

The mwifiex_sdio driver is known to have stability issues, particularly when toggling between AP and STA roles or manipulating both interfaces concurrently, and especially on newer kernel versions (1). The driver can enter a bad state during these operations, which matches the behavior you’re experiencing (1).

Specific Verdin AM62 Considerations

Your Verdin AM62 uses the AW-CM276NF Wi-Fi module, which is a single MAC device that can only operate on one channel at a time across both AP (uap0) and STA (mlan0) modes (1). This limitation can result in conflicts if the underlying driver/firmware isn’t handling these transitions robustly (1).

Troubleshooting Steps

1. Check for Hardware Issues

The Verdin AM62 has several known errata that could be related to your issue. Check if your module is affected by manufacturing issues that might impact functionality (2):

  • V1.1A and V1.1B versions have known manufacturing issues that can affect various interfaces including JTAG, ADC, LVDS, UART2, GPIOs, PWM, CAN, and Audio (2)
  • V1.0 and V1.1 versions have issues with MAYA-W1 input voltage that can cause reduced reliability if VCC is powered with 4.2V or higher (2)

2. Driver Recovery Options

When the Wi-Fi crashes and interfaces disappear, consider implementing a hardware-level reset or module reload (1). You can create a script to unbind/rebind the SDIO device, or perform a system reboot upon detection of failure (1).

3. Minimize State Changes

Reduce the frequency of state changes and avoid frequent toggling or rapid connect/disconnect cycles, as the current driver/firmware combination is particularly fragile under these conditions (1).

Current Status

This appears to be an ongoing issue with the mwifiex driver on Toradex platforms. The documentation indicates that investigations point to driver issues most pronounced when using the SDIO-based Wi-Fi on Verdin modules (1).

If you’re experiencing issues with the interfaces mentioned in the errata and using a Toradex Carrier Board with a Toradex Quarterly Release BSP Reference Image, the recommended approach is to contact the Toradex RMA department (2).

Best regards, Toradex AI Assistant.

3

Hey @krakorar,

This is a bit odd. I see that you are on a custom OS build. Can you recreate this incident on a reference image?

Also are you on a customer carrier board?

-Eric

4

This is for a customer project which utilizes the SOM below on some carrier board.

https://www.toradex.com/computer-on-modules/verdin-arm-family/ti-am62?srsltid=AfmBOooNw7XfpQuRNhe8foP8EA_a6PLb6GyIzDBRHVYNejBkLRcZYOxS

5

The exception seems to be with the instantiation of a driver for the UBlox module on the Toradex SOM which utilizes an NXP WiFi device.

6

Hey @krakorar,

I take this to mean the customer has a customized carrier board, correct? Not working from one of our development or production carrier boards?

Are you able to flash the BSP 6 base reference image to the SoM and produce the same results on the custom carrier board?

This image would be the one you install from our feeds when using recovery mode and our Toradex easy installer.

-Eric

7

Hi @krakorar ,

Any updates here? Can we close this?

Best regards,