- Forums
- Product Forums
- General Purpose MicrocontrollersGeneral Purpose Microcontrollers
- i.MX Forumsi.MX Forums
- QorIQ Processing PlatformsQorIQ Processing Platforms
- Identification and SecurityIdentification and Security
- Power ManagementPower Management
- Wireless ConnectivityWireless Connectivity
- RFID / NFCRFID / NFC
- Advanced AnalogAdvanced Analog
- Neural Processing UnitsNeural Processing Units
- MCX Microcontrollers
- S32G
- S32K
- S32V
- MPC5xxx
- Other NXP Products
- S12 / MagniV Microcontrollers
- Powertrain and Electrification Analog Drivers
- Sensors
- Vybrid Processors
- Digital Signal Controllers
- 8-bit Microcontrollers
- ColdFire/68K Microcontrollers and Processors
- PowerQUICC Processors
- OSBDM and TBDML
- S32M
- S32Z/E
-
- Solution Forums
- Software Forums
- MCUXpresso Software and ToolsMCUXpresso Software and Tools
- CodeWarriorCodeWarrior
- MQX Software SolutionsMQX Software Solutions
- Model-Based Design Toolbox (MBDT)Model-Based Design Toolbox (MBDT)
- FreeMASTER
- eIQ Machine Learning Software
- Embedded Software and Tools Clinic
- S32 SDK
- S32 Design Studio
- GUI Guider
- Zephyr Project
- Voice Technology
- Application Software Packs
- Secure Provisioning SDK (SPSDK)
- Processor Expert Software
- Generative AI & LLMs
-
- Topics
- Mobile Robotics - Drones and RoversMobile Robotics - Drones and Rovers
- NXP Training ContentNXP Training Content
- University ProgramsUniversity Programs
- Rapid IoT
- NXP Designs
- SafeAssure-Community
- OSS Security & Maintenance
- Using Our Community
-
- Cloud Lab Forums
-
- Knowledge Bases
- ARM Microcontrollers
- i.MX Processors
- Identification and Security
- Model-Based Design Toolbox (MBDT)
- QorIQ Processing Platforms
- S32 Automotive Processing Platform
- Wireless Connectivity
- CodeWarrior
- MCUXpresso Suite of Software and Tools
- MQX Software Solutions
- RFID / NFC
- Advanced Analog
- Neural Processing Units
-
- NXP Tech Blogs
- Home
- :
- Translated Content
- :
- Multi Source Translation Content
- :
- 2413121_en-US
2413121_en-US
- Subscribe to RSS Feed
- Mark as New
- Mark as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
2413121_en-US
2413121_en-US
Hi,
We're integrating an IW610G module (Murata TYPE2LL) on a custom embedded Linux board and need help getting 802.15.4/Thread working over SPI. WiFi and BLE work perfectly on the same hardware/firmware only the 802.15.4 RCP is an issue. Posting with as much detail as possible to save round-trips.
Hardware/software setup
- Host: QCA9531 SoC (MIPS 24Kc), OpenWrt-based Linux 6.12, ath79 target
- IW610G (Murata TYPE2LL) connected via USB for WLAN and BLE, and SPI for 802.15.4 matching the standard IW610 host interface architecture
- Firmware: usbusbspi_iw610.bin.se, pulled from the public nxp-imx/imx-firmware repo
- otbr-agent/ot-daemon built with -DOT_POSIX_RCP_SPI_BUS=ON and related options, using its built-in spinel+spi:// transport (spidev-based, no custom kernel SPI driver we understand this matches NXP's intended architecture, since NXP doesn't ship an in-kernel driver for the SPI/802.15.4 side)
What works
- WiFi: full association, throughput and stability tests over USB, 5 GHz, confirmed with real traffic under sustained load
- BLE: advertising, scanning, and coexistence with WiFi all confirmed working over USB with real nearby devices detected
What doesn't work
- 802.15.4 over SPI: the host correctly asserts CS, clocks out well-formed Spinel RESET frames, and the RCP never replies anything always a zero-filled header. This is consistent:
- Across every SPI clock speed from the controller's hardware floor up to 20 MHz
- With or without a GPIO reset pulse on IND_RST_WL/IND_RST_NB (chip-select/reset lines tested individually and combined)
- Across multiple wake/reset GPIO (WL_WAKE_IN, NB_WAKE_IN)
- On a chip confirmed freshly and cleanly power-sequenced
What we've already ruled out on our side
- Electrical signals confirmed clean and correctly timed scope-verified
- SPI mode (CPOL=0/CPHA=0) and timing verified against the IW610 datasheet's own SPI host interface timing diagram
- Firmware confirmed present, correctly loaded, and up to date (matches the latest commit on nxp-imx/imx-firmware)
The FP92/FP99 discrepancy
Our driver reports:
wlan: version = USBIW610--18.99.8.p52--MM6X18543.p18-GPL-(FP92)
We found an existing thread ("IW610 802.15.4 problems") where another user hit the exact same symptom with the exact same (FP92) tag, using sduartspi_iw610.bin.se. RN00104 documents USB-WLAN-USB-BLE-FP99-IW610 as the official validated configuration for IW610 over USB (WLAN over USB, BLE over
USB matching our exact bus topology). Digging further:
-The public nxp-imx/mwifiex repo has FPNUM="92" hardcoded in the Makefile on every branch we checked, including current HEAD
- The public nxp-imx/mwifiex-iw612 repo does have a real FPNUM="99", but it's IW612-only (no IW610 references in the source) and SDIO-only (no USB transport code at all)
Our question
Where can we obtain the actual FP99 driver + firmware + config bundle corresponding to the USB-WLAN-USB-BLE-FP99-IW610 entry documented in RN00104 doc? Is this combination available through a channel other than the public GitHub repos (direct support request, NDA, module vendor distribution)? Any
pointer to what's actually different between an FP92 and FP99 build beyond the version-string macro would also help us understand whether this is even the right lead.
Thanks in advance
Hi,
I sent you a private message.
Regards,
Daniel.