2408524_en-US

はい

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

Re: BT firmware accepted over UART but controller never runs; and EdgeFast download corrupts at the

Resolved / closing update — thank you for the help, and here is the answer for
anyone who finds this thread later.

After completing the rework and moving to external power (per Daniel's three
preconditions), we ran a **module-substitution test**. Holding *everything* else
identical — same MIMXRT1170-EVKB, same rework, same external 5 V, same MCUXpresso
SDK v26.06.00-LTS, the same stock `uartIW416_bt.bin`, and the *same compiled
EdgeFast `shell` binary* — we swapped the u-blox M2-MAYA-W161 for a genuine
**Embedded Artists Murata Type 1XK M.2 (EAR00385)** (the IW416 module the
`board_murata_1xk_m2` profile targets).

With the Murata 1XK, `bt.init` runs to completion:

```
download success!
[FW Download]BLE FW is downloaded
Bluetooth initialized
Settings Loaded
```

The controller comes up cleanly. With the u-blox MAYA-W161, the *same* binary
downloads identically (`download success!`) and then the controller is silent.

**So this was not an NXP problem.** The board, the SDK, the stock
`uartIW416_bt.bin`, and the EdgeFast stack are all correct — proven by the Murata
IW416 module running to a live controller on the identical setup. The fault is
specific to the u-blox MAYA-W161 (its firmware provisioning / authentication),
and we are taking that to u-blox.

Two useful side notes for others on this board:

* **The 3 Mbaud download corruption we reported earlier was the missing
flow-control rework.** After fitting `R1902` and removing `R1816` (NXP's
five-item EdgeFast rework), the stock loader's 115200 → 3,000,000-baud switch
completes cleanly and the download succeeds. Before that rework it corrupted at
the switch and looped; the rework fixes it.
* On the MIMXRT1170-EVKB the loader must stay well-fed at 3 Mbaud, which needs
that flow-control rework in place; at 115200 it is unconditional.

Thanks again for pointing us at the rework and the external-supply requirement —
both mattered, and together they got a genuine Murata module all the way up.

Cheers @DanielRuvalcaba, I will follow up with uBlox.