BT firmware accepted over UART but controller never runs; and EdgeFast download corrupts at the 3M I have raised a related/companion support ticket with u-blox, case **CA-276115** (same hardware, module-vendor questions). My questions below are about NXPs **IW416 ROM's firmware-authentication behaviour** and an **EdgeFast download bug on NXP's own reference board**. Every figure is a measurement and full logs attached. ## 1. Summary — two DISTINCT failures, please keep them separate On a **u-blox M2-MAYA-W161** (NXP **IW416**) in a **MIMXRT1170-EVKB Rev C3**, BT HCI over LPUART2: **Failure A — the core question.** With a clean 115200-baud UART download, the BT firmware **downloads completely and is accepted** (the ROM stops requesting data and does not re-announce), and the controller then **never transmits** — no HCI response at any baud rate. **Failure B — an EdgeFast/board bug.** NXP's stock EdgeFast download flow switches to **3,000,000 baud mid-download** and the link **corrupts at the switch** on this board; the download never completes. This is separate from Failure A and reproducible with NXP software only. > These have different root points. Fixing B (the 3 Mbaud corruption) would not > address A (the post-download silence). We are asking about both, separately. Wi-Fi (SDIO) on the same card works fully — enumeration, station, micro-AP, throughput — so the card, its power, and its level shifters are healthy. --- ## 2. Configuration | Item | Value | |---|---| | Chipset / module | NXP **IW416** in u-blox M2-MAYA-W161-00C-00 | | Host board | MIMXRT1170-EVKB Rev C3, M.2 J54, LPUART2 | | SDK | MCUXpresso **v26.06.00-LTS** | | BT firmware | `uartIW416_bt.bin` **16.92.21.p155.2**, FP92, `w8978`, 131,840 B | | Also tested | **16.92.21.p142.5** (FP91, from `github.com/NXP/wifi_nb_fw@a91d9d6`, Jan 2025) — same result | | Module select | `WIFI_IW416_BOARD_MURATA_1XK_M2` (the SDK has no MAYA profile) | | Board rework | `R404` (PDn) + `R1901` (module→MCU RXD) fitted & verified; flow-control pair `R1816`/`R1902` **not** done — see §5 | --- ## 3. Failure A — the image is accepted, then the controller is silent ### The download completes and is accepted Our own clean-room V3 loader (protocol only, at 115200), instrumented: ``` bt_fw_download=ok chip_id=0x7201 loader_ver=0 start_inds=2 chunks=142 sent=131856/131840 max_off=131840 retx=1 crc_err=0 ``` All 131,840 bytes; the card requested every chunk (16-byte headers, 2048-byte payloads, including out-of-order re-requests at the tail); **one CRC error was reported by the card and recovered by retransmission** — so the ROM's own integrity checking is live. ### Then nothing — and the ROM behaves as if the image was ACCEPTED, not rejected ``` bt_post_dnld[0..3]: n=0 (four 500 ms raw-capture windows after download) bt_raw_reset[0..2]: n=0 (raw HCI_Reset 01 03 0C 00 at 115200, x3) HCI_Reset at 3000000 / 921600 / 460800 / 115200 : no response, framing=0 at all ``` The **key discriminator**: after the UART download the ROM **stops requesting and does not re-announce**. For contrast, when the combo image is downloaded over **SDIO**, the BT core **does re-announce** on the UART (`AB 01 72 00 47` reappears) — i.e. that is what "still in bootloader / not accepted" looks like on this part. So the UART download is **accepted and the loader exited**, and the failure is *between accepting a CRC-valid image and running a controller*. ### Firmware version is not the variable Two official builds — **FP92 p155.2** (2026-03) and **FP91 p142.5** (2025-01, different internal structure, load `0x00080000` vs `0x000A2010`, 178 vs 142 chunks) — both download completely, both are accepted, both leave the controller silent. So this is not a stale/wrong *version*. ### Questions for NXP (Failure A) 1. **Does the IW416 ROM authenticate the UART-downloaded BT firmware against OTP-fused keys**, and if so, **how is a rejection signalled to the host?** We observe: every block accepted, ROM stops requesting, no error frame, no re-announcement, then silence. Is that byte-pattern the documented secure-boot / signature-reject behaviour, or does an authentic image behave this way for another reason? 2. **Is stock `uartIW416_bt.bin` (16.92.21.p155.2) built for a generic / un-fused IW416**, or does it require a matching OTP/secure-boot provisioning on the part? (If the part is fused for a specific OEM key, is the stock image expected to be rejected — which would point us back to u-blox, CA-276115.) 3. **What is the expected controller behaviour in the first seconds after a successful UART download** at 115200 — should it answer `HCI_Reset` immediately, or is a vendor command / delay required first? --- ## 4. Failure B — EdgeFast download corrupts at the 3 Mbaud switch (MIMXRT1170-EVKB) Reproducible with **NXP software only**, on **NXP's own reference board**. Built `examples/edgefast_bluetooth_examples/shell` for the 1170 with `DEBUG_PRINT` enabled so NXP's `fw_loader_uart.c` narrates. From its trace: 1. 115200 header requests are clean and CRC-valid (`REQ=0xA7 Len=10 Off=0 Err=0`); 2. a type-5 UART-config block is sent and **ACKed** (so the type-5 command is accepted in-context on this board/firmware); 3. `change baud-rate req to 3000000`, `changeBaudrate() ret 0` — the switch **reports success**; 4. immediately after: `Invalid Header 0x00` / `0x71`, `REQ = 0xA7, Len = 10a7, Off = 5400, Err = 400, CRC = 0`, `CRC Mismatched`, and `file download: 0: 131840` — stuck at offset 0. The offsets are byte-concatenations (`5400` = two bytes run together): **framing loss**, not overflow. So the card switched to 3 Mbaud and is transmitting; the RT1176 LPUART2 at 3,000,000 baud on this board — DMA-fed, **no usable hardware flow control** — cannot recover the frames. With stock flow-control settings the first post-switch header times out, the loader falls back to 115200, retries, and **loops indefinitely** (>20 min observed). Root cause on the board: **LPUART2's RTS/CTS pads are the gigabit PHY's reset/interrupt lines** (`R1866` → `ETHPHY_RST_B`, `R1816` → `RGMII1_PHY_INTB`), so there is no clean host-RX back-pressure path even after NXP's documented five-item rework — `R1866` is not in that rework. At 3 Mbaud without flow control the host cannot keep up. ### Questions for NXP (Failure B) 4. On the **MIMXRT1170-EVKB**, is the 3 Mbaud EdgeFast BT firmware download a **known limitation without the full flow-control rework** (remove `R1816`, fit `R1902`) — and even with it, given `R1866` keeps the host RTS on the PHY reset, is 3 Mbaud actually supported on this board, or should the `fw_download_secondary_speed` be left at 115200? 5. Is the **infinite retry loop** on a failed secondary-baud switch (`fw_loader_uart.c`) intended? A hard failure after N retries would be far easier to diagnose than an endless progress-dot stream. ### Minor, low priority (same tree) 6. In `edgefast_bluetooth`'s shell, `SHELL_CMD_REGISTER(bt, ...)` registers the `bt` command with a **0-parameter range**, so `fsl_shell.c` rejects every subcommand (`bt init` → "Incorrect command parameter(s)"); the working invocation is the dotted `bt.init`. Likely an `SHELL_ADVANCE` / range-init mismatch worth a look. --- ## 5. What we have already eliminated (so these need not be suggested) All on silicon, MIMXRT1170-EVKB: | Hypothesis | Verdict | |---|---| | type-5 UART-config block missing | our standalone injection is rejected (`CRC_ERR 0x0001`); but NXP's in-flow type-5 IS accepted (§4) — so this is not the blocker for Failure A | | wrong firmware **version** | refuted — FP91 and FP92 both accepted, both silent (§3) | | combo-over-SDIO needed | it does **not** bring BT up on this module — the BT core re-announces from ROM after the SDIO combo download completes | | host download truncating | refuted — 15 s idle poll leaves `sent` unchanged | | HCI baud rate | refuted — 4 rates, `framing=0`, zero bytes | | `wakeUpControllerFromBootSleep()` GPIO pulse | implemented; the card **reacts** (extra greeting) but outcome unchanged | CPU state during the silence (SWD, console detached): `DHCSR 0x01010001` (running; `S_HALT`/`S_LOCKUP` clear), `CFSR`/`HFSR` = 0 — the host MCU is alive and blocked in `controller_init`, not crashed. Only **signature / secure-boot rejection** remains for Failure A, which is exactly Q1/Q2 — and it is the seam between this ticket and u-blox CA-276115. --- ## 6. Reproduction (Failure B, NXP software only) ``` west build -b evkbmimxrt1170 examples/edgefast_bluetooth_examples/shell \ --toolchain armgcc --config flexspi_nor_debug -- -Dcore_id=cm7 \ -DCONFIG_MCUX_COMPONENT_component.wifi_bt_module.IW416=y \ -DCONFIG_MCUX_COMPONENT_component.wifi_bt_module.board_murata_1xk_m2=y ``` Flash, reset, at the `@bt>` prompt type `bt.init`. The download prints progress dots and never completes; enabling `DEBUG_PRINT` in `fw_loader_uart.c` shows the corruption at the 3 Mbaud switch. (`edgefast_open`'s newer shell for the 1170 accepts space-separated `bt init` and hangs the same way.) For Failure A: full instrumented download + HCI evidence at 115200 is attached Re: BT firmware accepted over UART but controller never runs; and EdgeFast download corrupts at the Hi @nicnewdigate ,
Before we dig deeper into this, could you please confirm a few points?
- The MIMXRT1170EVKB_hwrework.md guide lists five required modifications: remove R183, remove R1816, populate R404, populate R1901, and populate R1902.
From your notes, it looks like R404 and R1901 have already been completed. Can you confirm the status of R183, R1816, and R1902 as well?
- Could you provide a serial log from one of the standard NXP examples running without any changes to app?
It could be the bluetooth shell.
Build the project for the Murata 1XK M2
- Send over the complete log.
- Is the board powered only through USB, or are you using an external 5 V supply? Please use external power.
Regards, Daniel. Re: BT firmware accepted over UART but controller never runs; and EdgeFast download corrupts at the Hi @DanielRuvalcaba - thank you for your quick response and your suggestions! I've completed all three items you asked for. Summary first, then the log. **1. Rework — complete.** All five items of the EdgeFast BT PAL rework for the MIMXRT1170-EVKB are done: R404 and R1901 (fitted earlier), plus **R1902 fitted** and **R1816 + R183 removed**. We confirmed the two removals did not harm the readable BT link — our own 115200-baud loader still downloads the full image cleanly (131,840 bytes, framing errors = 0, byte-identical to before the removals). **2. External power — done.** J38 → 1–2, 5 V into the J43 barrel jack, SW5 on. **3. Unmodified-shell log — captured.** We built `examples/edgefast_bluetooth_examples/shell` from MCUXpresso SDK v26.06.00-LTS, `--config flexspi_nor_debug -Dcore_id=cm7`, armgcc. The only change from stock is the module selection for our card, in the board `prj.conf`: ``` CONFIG_MCUX_COMPONENT_component.wifi_bt_module.IW61X=y → IW416=y CONFIG_MCUX_COMPONENT_component.wifi_bt_module.board_murata_2el_m2=y → board_murata_1xk_m2=y ``` (These are the two Kconfig `choice` members that select the module. Our card is a u-blox MAYA-W161 — an IW416 — so we selected the 1XK/IW416 profile you named. `CONFIG_BT_SIGNING=y` and everything else is stock.) Result at the shell prompt: ``` @bt> bt.init [FW Download] Start to download firmware from 0x301198fc: 6812 download starts(131840) ...................................................................... (141 dots) download success! [FW Download]BLE FW is downloaded: 8265 ← then nothing, for the remaining 90+ seconds. bt.init never returns. ``` **Two things changed since our earlier report, and both matter:** **A — the 3 Mbaud download now COMPLETES.** Before the flow-control rework the stock loader corrupted at the 115200 → 3,000,000-baud switch and looped indefinitely. With R1902 fitted and R1816 removed (real CTS back-pressure), it now moves all 131,840 bytes in ~1.45 s (timestamps 6812 → 8265 ms — the high-speed rate) and prints `download success!`. So the rework fixed the download-side problem, exactly as expected — thank you for insisting on it. **B — the controller is still silent after a SUCCESSFUL download.** This is the core question. After `download success!` / `BLE FW is downloaded`, the stack receives nothing from the controller — no `Bluetooth initialized`, no error — and `bt.init` hangs. The host MCU is alive and blocked, not crashed; with the console detached we read over SWD: ``` DHCSR = 0x01010001 (running: S_HALT=0, S_LOCKUP=0, S_RETIRE_ST=1) CFSR = 0x00000000 (no configurable fault) HFSR = 0x00000000 (no hard fault ever taken) ``` So the CM7 is waiting in the stack for an HCI reply that never comes. This is now a very clean data point: on NXP's **own unmodified EdgeFast stack**, with the full rework and external power, the card **accepts a complete, CRC-checked firmware image and then runs no HCI controller**. The earlier "the 3 Mbaud download is corrupt" explanation no longer applies — the download demonstrably succeeds. **Our questions (unchanged, now isolated from any download-integrity variable):** 1. Does the IW416 ROM authenticate the UART-downloaded BT firmware (e.g. against OTP-fused keys), and if so, how is a rejection signalled to the host? We see every block accepted, `download success!`, then silence — no error frame and no re-announcement. 2. Is the stock `uartIW416_bt.bin` (16.92.21.p155.2) built for a generic / un-fused IW416, or does a part fused for a specific OEM key require a matching signed image? If so, that points us back to u-blox (companion case CA-276115). 3. In the first seconds after a successful UART download, should the controller answer `HCI_Reset` immediately at the post-download rate, or is a vendor command / delay required first? I'm happy to share the full serial capture and the complete SWD register block, and we can enable `DEBUG_PRINT` in `fw_loader_uart.c` for a narrated download trace if that would help. Thanks so much for your time and effort - Its hugely appreciated!!! cheers - Nic
View full article
