NCP flashed via SWD — RESET_UNKNOWN_REASON loop, cannot establish ASH

[lornys]

Gateway: Lidl Silvercrest, Linux v2.1.6 running correctly, SSH/network all good.

Problem: EFR32MG1B232F256GM48 had original Tuya firmware that didn't respond to any known protocol (EZSP, CPC, SPINEL, Gecko Bootloader). universal-silabs-flasher always failed at probe stage.

What I did: Flashed via J-Link OB clone (2€ Ali) over SWD:

1. bootloader-uart-xmodem-2.4.2.gbl → verified OK
2. ncp-uart-hw-7.5.1.gbl → verified OK (208896 bytes at 0x00004000)

Result with serialgateway -f (SW flow control):
NCP responds but sends RESET_UNKNOWN_REASON in an infinite loop. Z2M never gets past ASH init.

Result with serialgateway (HW flow control):
No response at all. Z2M waits for RSTACK indefinitely and times out.

Serial port status:

$ cat /proc/tty/driver/serial
1: uart:16550A mmio:0x18002100 irq:29 tx:818 rx:3295219 RTS|CTS|DTR

RTS/CTS lines appear active. tx is non-zero but rx was 0 during HW flow control tests.

Z2M config:

serial:
  port: tcp://192.168.10.150:8888
  adapter: ember
  rtscts: false  # also tried without this

Question: Is this expected behavior after a first SWD flash? Does the NCP need any additional initialization step (e.g. token erase, specific reset sequence) before it can communicate via ASH? The RESET_UNKNOWN_REASON loop suggests the NCP is alive but stuck in a crash loop.

Thank you for this amazing project!

[jnilo1]

Thanks for the detailed write-up — the flash itself looks fine (Stage 1 BSL from the original 2-stage Tuya bootloader is intact, our Stage 2 2.4.2 landed at 0x0800, NCP 7.5.1 at 0x4000, both verified). The RESET_UNKNOWN_REASON loop is almost certainly coming from stale NVM3 data left behind by the Tuya firmware, not from a flash-integrity problem.

Why NVM3 matters here

NVM3 lives at the top of flash and survives application updates by design. When you flashed the NCP .gbl via SWD, Commander only wrote the application region (around 0x4000); the NVM3 pages at the top were not touched. EmberZNet 7.5.1 reads NVM3 on boot, finds entries written by the Tuya stack in a format/layout it doesn't recognise, and panics during stack init → reboot → RESET_UNKNOWN_REASON, in a loop.

That also explains the HW-flow-control silence: the NCP never reaches the point where it deasserts RTS to signal "ready", so nothing flows. Running serialgateway -f bypasses that and lets you see the reset banners — but you're effectively watching the crash loop from the outside, not actually communicating.

Fix: mass-erase, then re-flash

# 1. Wipe everything — clears NVM3, lock bits, the lot.
commander device masserase --device EFR32MG1B232F256GM48

# 2. Stage 1 + Stage 2 in one shot (so you don't rely on the old Tuya BSL).
commander flash 2-Zigbee-Radio-Silabs-EFR32/23-Bootloader-UART-Xmodem/firmware/bootloader-uart-xmodem-2.4.2-combined.s37 \
    --device EFR32MG1B232F256GM48

# 3. Application.
commander flash 2-Zigbee-Radio-Silabs-EFR32/24-NCP-UART-HW/firmware/ncp-uart-hw-7.5.1.s37 \
    --device EFR32MG1B232F256GM48

# 4. Sanity check — should print a valid EUI-64.
commander device info --device EFR32MG1B232F256GM48

A few notes on the above:

• Use -combined.s37, not the .gbl, for the bootloader step. A pure masserase erases the BSL region too, so you need to reinstall Stage 1 — the combined image includes both stages (the plain .gbl only carries Stage 2 and would leave 0x0000..0x07FF blank, bricking the chip until you re-flash).
• .s37 for the NCP app is equivalent to the .gbl you already flashed, minus the GBL wrapping. If you have a Commander version that accepts .gbl for SWD flashing and it worked for you before, you can keep using that — the important thing is that the mass-erase happens first.

After re-flash

Put serialgateway back to HW flow control (drop -f) and set Z2M to rtscts: true (or just leave it out — ember defaults to HW flow control). You should see the EZSP handshake complete within a second or two.

If the loop persists after a clean masserase + re-flash, check commander device info output for the Unique ID / EUI-64 — if it's all FF the DEVINFO page was clobbered, which is rare on these chips but worth ruling out before chasing anything else.

Let me know how it goes.

[lornys]

Thanks for the detailed explanation.
Update after your fix: I did the full masserase + combined.s37 bootloader + ncp s37 exactly as you described. All steps completed successfully and verified.
Result: The RESET_UNKNOWN_REASON crash loop is gone (the masserase fixed that, thanks!). But now the NCP doesn't respond at all in either mode:

serialgateway (HW flow control): waits for RSTACK indefinitely, times out
serialgateway -f (SW flow control): connects, sends RST, but gets "Closing existing connection" immediately — no RSTACK

Hardware info:

Gateway firmware: Lidl Zigbee Gateway RTL8196E v2.1.6
/proc/tty/driver/serial: ttyS1 shows RTS|CTS|DTR flags, tx non-zero, rx stays at 0
EFR32 Unique ID: 5c0272fffe4ad7b5

My suspicion is that RTS/CTS lines may not be physically connected between RTL8196E and EFR32 on this specific PCB revision. Is there a way to confirm this, or a version of the NCP firmware compiled without hardware flow control that I could test?

[jnilo1]

Good — the masserase clearing the crash loop confirms the NVM3 hypothesis, so we can put that part to bed. The new symptom is different: the NCP is no longer crashing, it's just silent in both directions (tx≠0, rx=0). Before suspecting the PCB, let's prove or rule out the UART path, because there are at least three things that produce exactly these symptoms and only one of them is hardware.

RTS/CTS is almost certainly not the issue

A few reasons your "RTS/CTS not connected" hypothesis is unlikely on this board:

• The Tuya stock firmware on this exact PCB used the same UART1 with HW flow control to talk to the SoC — if the lines weren't routed, Tuya would never have worked.
• v2.1.6 already ships the PIN_MUX_SEL fix from v1.2.1 (commit 54c9b90), so UART1 TX/RX/RTS/CTS should all be muxed to the physical pins regardless of what the bootloader left behind.
• RTS|CTS|DTR showing in /proc/tty/driver/serial only means the kernel configured those lines — not that they're electrically connected, but it does mean the driver thinks they exist.
• In SW-flow-control mode (-f) RTS/CTS is bypassed entirely, so if the lines were the only problem, -f would work. It doesn't — that points elsewhere.

So rx=0 in -f mode is the load-bearing observation. Let's chase that.

Diagnostic ladder — please run these in order

1. Confirm UART1 is muxed on the SoC side

# On the gateway, as root:
devmem 0x18000040 32

Bits 1 (0x02), 3 (0x08) and 6 (0x40) must be set — i.e. the value AND 0x4A must equal 0x4A. If those bits are clear, the kernel never ran the UART1 mux fix on this boot for some reason (very unlikely on v2.1.6, but worth ruling out in 2 seconds).

2. Force the EFR32 into a known-good UART state

This is the cleanest test — it replaces the NCP with the Gecko bootloader's own menu, which is also at 115200 baud, no flow control, and is not affected by NVM3 or stack init. If the gateway can read its menu, we've proven the entire UART path end-to-end.

Over your J-Link, erase only the application region:

commander flash --erase --range 0x4000:0x3DFFF --device EFR32MG1B232F256GM48
# (NVM3 is at 0x3E000–0x3FFFF — leaving it alone)

Reset the EFR32. With no valid application, Stage 2 sits in its menu and prints a banner. On the gateway:

serialgateway -f      # 115200, SW flow control
# Hit Enter or send a serial break — you should see the bootloader menu:
#   Gecko Bootloader v2.4.2
#   1. upload gbl
#   2. run
#   ...

• Menu appears → UART path is fine (TX, RX, mux, baud, the lot). The problem is on the EFR32: either the NCP image isn't actually running, or it's stuck before it touches the UART. Go to step 3.
• Menu does not appear → Either the SoC isn't muxed (step 1) or there's a genuine hardware fault on the RX line specifically. At that point a scope/logic analyser on the EFR32's PA1 (RX from SoC perspective is PA0/TX) is the next step, but I'd bet on something simpler first.

When you're done, re-flash NCP:

commander flash 2-Zigbee-Radio-Silabs-EFR32/24-NCP-UART-HW/firmware/ncp-uart-hw-7.5.1.s37 \
    --device EFR32MG1B232F256GM48

3. If step 2 succeeds — inspect the running NCP via SWD

You already have a J-Link attached, which is the strongest tool here. Two cheap checks:

# Halt and read the program counter — is the NCP in its main loop or in HardFault_Handler?
commander dumpasm --device EFR32MG1B232F256GM48 --address $(commander device readmem --address 0xE000ED14 --length 4 --device EFR32MG1B232F256GM48)

# Or just open a JLinkGDBServer + arm-none-eabi-gdb session and `info reg`, `bt`.

If the PC is parked in HardFault_Handler or Default_Handler, EmberZNet faulted before reaching the UART code — typically a missing manufacturing token (CTUNE / custom EUI). On a fresh masserase the manufacturing tokens should be intact (they live in the User Data / lock page, which masserase does not touch on EFR32MG1B), but it's worth dumping:

commander tokendump --device EFR32MG1B232F256GM48

MFG_CUSTOM_EUI_64 and MFG_CTUNE should both be present and not all-FF. Your earlier commander device info already showed a valid EUI-64 (5c:02:72:ff:fe:4a:d7:b5), which is reassuring — but a token dump confirms CTUNE too.

On a HW-flow-control-disabled NCP

We don't ship one in the repo, and I'd hold off on building one before we've ruled the path issue out — if RTS/CTS truly were the problem you'd at least see the boot banner with serialgateway -f, since -f ignores those lines. If after step 2 you still want to try it for completeness, the recipe lives in 2-Zigbee-Radio-Silabs-EFR32/24-NCP-UART-HW/ (the .slcp exposes EMBER_SERIAL1_RTSCTS — flip it off, regenerate with slc-cli, rebuild). But let's not go there unless step 2 forces us to.

Please post the output of step 1 (devmem) and step 2 (whether the bootloader menu shows up). That will narrow it from three possibilities down to one.

[lornys]

First of all, thank you so much for your time and patience — the level of support you provide for this project is truly exceptional. I really appreciate it!
Update — full diagnostic results:
Step 1 (UART mux): devmem 0x18000040 32 → 0x0000004A
Step 2 (Gecko Bootloader menu): After erasing the application region, the bootloader menu appears correctly via nc:
Gecko Bootloader v2.04.02

1. upload gbl
2. run
3. ebl info
   BL >

Additional test — Tuya firmware: Restored original Tuya backup via SWD. With serialgateway -f, the Tuya firmware immediately sends continuous binary data through the UART — full bidirectional UART confirmed.
After re-flashing NCP (masserase + combined.s37 + ncp s37): Bootloader jumps to NCP correctly (no menu), but NCP sends nothing on the UART. Z2M gets no RSTACK in either HW or SW flow control mode.
Question: I just noticed the v3.0/v3.1 release which replaces serialgateway with the rtl8196e-uart-bridge kernel driver. Would upgrading to v3.1.1 help diagnose or fix this? The new recover_efr32 script and kernel-level bridge seem like they could change the picture. Ready to upgrade if you think it's worth trying — just wanted to check with you first before doing anything else. Thanks again for everything!

[jnilo1]

Those three tests together (PIN_MUX_SEL = 0x4A, the Gecko Bootloader menu over nc, and the Tuya backup streaming) prove the entire UART path end-to-end. So the SoC, the mux, the wires, and the bridge are all good. The problem is squarely on the EFR32: the NCP starts (the bootloader hands over and never comes back to its menu), but never writes a byte to the UART.

On v3.1.1

It won't help here, sorry. The kernel UART bridge in v3.0+ improves the SoC side, but your Gecko Bootloader test already proved the SoC side is fine. If the EFR32 isn't transmitting, no SoC-side change will conjure data out of it. I'd hold the upgrade until after this is sorted.

The likely cause — and the one test that nails it

The NCP we ship has hardware flow control hard-wired (CTS on PA5, RTS on PA4). The EFR32 gates every TX byte on its CTS input — until PA5 reads "asserted", nothing goes out. The Gecko Bootloader and the Tuya firmware don't use HW FC, which is why those streamed for you. The NCP is the only firmware here that requires it, and it's the only one that's silent. That's a strong hint.

Quickest definitive test: rebuild the NCP without flow control and re-flash.

cd 2-Zigbee-Radio-Silabs-EFR32/24-NCP-UART-HW
# In patches/sl_iostream_usart_vcom_config.h, change:
#   SL_IOSTREAM_USART_VCOM_FLOW_CONTROL_TYPE  →  usartHwFlowControlNone
./build_ncp.sh
commander flash firmware/ncp-uart-hw-7.5.1.s37 --device EFR32MG1B232F256GM48

Then on the gateway with serialgateway -f and Z2M rtscts: false:

• EZSP handshake completes → FC was the issue. On your PCB revision PA4/PA5 likely aren't wired to the SoC's RTS/CTS the way ours are. The no-FC build is a perfectly fine permanent solution — clean bridge link, no real cost.
• Still silent → FC is innocent and the NCP is faulting before it touches the UART. We'll then halt the chip over SWD and look at the program counter / fault registers, which will tell us exactly what.

Run (a) first. Easy 10-minute test, and given everything you've already proven I'd put real money on it succeeding.

[lornys]

Hello, further update:
Built a no-FC NCP (usartHwFlowControlNone) and flashed it via SWD. Now confirmed: the NCP is transmitting. Z2M and bellows both receive RESET_UNKNOWN_REASON ERROR frames in a loop. This proves CTS was blocking TX in the HW-FC build.
However, the NCP never responds to the ASH RST frame — it just keeps sending ERROR frames and never sends RSTACK. Both Z2M and bellows time out.
nc to port 8888 receives nothing — the NCP only seems to respond to ASH RST frames, not spontaneously.
Mass-erase was done before flashing (combined.s37 bootloader + no-FC NCP s37). Token dump shows all FF except MFG_EMBER_EUI_64.
Is RESET_UNKNOWN_REASON in a loop normal for a freshly flashed NCP with no prior network? Should Z2M eventually break through this loop, or does it indicate the EmberZNet stack is faulting during init?
Thanks!!

[jnilo1]

The no-FC build streaming confirms what we suspected: on your unit PA4/PA5 aren't wired to the SoC's RTS/CTS, so the HW-FC build was permanently CTS-blocked.

You're actually the first to report a board variant where these pins differ from ours (and I find that a bit strange), so before we go further could you share as much detail as possible on your gateway? Specifically:

• The exact model name and reference printed on the box / housing label (and a photo of the label if you can).
• Photos of the PCB — both sides if possible — with any silkscreen revision markings clearly visible (typical spots: near the EFR32, near the J1 header, in a corner of the board). A close-up of any string like Vx.x, REV x, date code, or Lidl/Tuya internal SKU is exactly what I'm after.
• Where and roughly when you bought it (country + year is enough), since Lidl rotates suppliers.

This will let me document the variant properly in 0-Hardware/ and decide whether the no-FC build needs to become a maintained second firmware variant for this revision.

On the token dump

I dumped a known-good gateway here for comparison: it also has MFG_CTUNE = 0xFFFF and a similar mostly-FF token layout, and it runs the NCP just fine. So the token state on your chip doesn't actually look anomalous, and the missing tokens are not what's causing the reset loop.

The reason MFG_CTUNE = 0xFFFF is harmless: when the token is absent, sl_device_init_hfxo() falls back to the compile-time constant SL_DEVICE_INIT_HFXO_CTUNE, which our NCP build pins at 360 decimal (0x168) — see 2-Zigbee-Radio-Silabs-EFR32/24-NCP-UART-HW/build/config/sl_device_init_hfxo_config.h:53. Your chip is already using that value via the fallback path, same as my working unit, so writing MFG_CTUNE manually wouldn't change anything.

Which means we need to find what's actually triggering the reset on your chip rather than guessing at it. Since you have a J-Link attached this is straightforward.

SWD halt — read the real cause with the tools you already have

Everything below uses commander only — no extra install needed, since the fault state on Cortex-M is in memory-mapped registers that readmem reaches the same way it reads any other address.

Let the no-FC NCP run for a few seconds (so you're sure it has hit at least one of those RESET_UNKNOWN_REASON ERROR frames), then halt and dump:

commander device halt --device EFR32MG1B232F256GM48

# System Control Block fault registers
commander device readmem --address 0xE000ED04 --length 4 --device EFR32MG1B232F256GM48   # ICSR  — which exception is active
commander device readmem --address 0xE000ED28 --length 4 --device EFR32MG1B232F256GM48   # CFSR  — UsageFault / BusFault / MemManage sub-cause
commander device readmem --address 0xE000ED2C --length 4 --device EFR32MG1B232F256GM48   # HFSR  — was it a HardFault, and was it escalated
commander device readmem --address 0xE000ED34 --length 4 --device EFR32MG1B232F256GM48   # MMFAR — faulting address for MemManage faults
commander device readmem --address 0xE000ED38 --length 4 --device EFR32MG1B232F256GM48   # BFAR  — faulting address for BusFault

Just paste the five values raw — I'll decode them. What we'll learn from those alone:

• ICSR low 9 bits ≠ 0 → the chip halted inside an exception handler. The value tells us which one (3 = HardFault, 4 = MemManage, 5 = BusFault, 6 = UsageFault).
• CFSR + HFSR → the precise sub-cause (e.g. "imprecise data bus error", "undefined instruction", "stack underflow", "fault escalated to HardFault because the lower-priority handler wasn't enabled").
• MMFAR / BFAR (if their VALID bit is set in CFSR) → the exact memory address the firmware tried to touch when it faulted.

That's enough information to tell whether your chip is faulting during stack init, during radio bring-up, or during something more exotic — without us guessing.

If those values come back inconclusive (e.g. ICSR = 0, no fault active, just a soft reset loop), the next step would be a backtrace — program counter + stack walk + register dump. Quick question for that: do you already have OpenOCD set up against your J-Link OB on this chip? It's the easiest path I know of (apt install openocd, then interface/jlink.cfg + target/efm32.cfg, telnet on :4444 for halt / reg / mdw), no SEGGER pack required and no GDB session needed for what we'd want to read. If you've already wired it up once it'll take you 30 seconds; if not, no need to install it preemptively — let's see what step 1 says first.

[lornys]

First of all, I owe you a big apology and a huge thank you for all the time and effort you've dedicated to helping me — your support has been truly exceptional throughout this whole process.
Important correction: After looking more carefully at the photos and markings, I've realized this is not a Lidl Silvercrest gateway. It's a generic Tuya Zigbee gateway that I found online. I assumed it was the same hardware because it looks very similar externally and uses the same RTL8196E + EFR32MG1B combination, but it's clearly a different board. I'm really sorry for not clarifying this earlier and for making you spend so much time on what turned out to be a different hardware variant.
Hardware details from the PCB:

Board silkscreen: TYGWZ1 REV1.0.2, dated 20191016
Main SoC: RTL8196E (KC1M5G1 GL02 TAIWAN)
Zigbee module: TYZS4 (P/N: 2.22.46.00001, S/N: 100026047004FD)
Flash: GD25Q128 (Winbond W9425G6KH-5 on back)
Case label: "Zigbee Gateway, Input: DC 5V 1A"
Board label: FPE H16107DF-R 1412X

I'm attaching photos of both sides of the PCB with all the silkscreen markings visible. The back side clearly shows the test points labeled SWDIO, SWCLK, ZIGBEE_RST, UART_TX, UART_RX, UART_RTS, UART_CTS — so the signals exist on the board, but as we've discovered, the RTS/CTS lines from the TYZS4 module are apparently not connected to the RTL8196E's UART.
OpenOCD/halt results (as requested):

PC: 0x0001992c — chip running, no HardFault
LR: 0x00019b15
SP (MSP): 0x20000f50
xPSR: 0x21000000, basepri: 0x60
All fault registers (ICSR/CFSR/HFSR): 0x00000000
MMFAR/BFAR: 0xE000EDF8 (inside SCB, not a valid fault address)

Stack at MSP:
0x20000f50: 200025bc
0x20000f54: 200025bc
0x20000f58: 000362d4
0x20000f5c: 20006162
0x20000f60: 20005c0c
0x20000f64: 00019ccd
0x20000f68: 2000257c
0x20000f6c: 200025bc
Note: halt is not available in commander-cli (no GUI environment), so I used OpenOCD instead. bt and disassemble are not available in the OpenOCD telnet interface — GDB would be needed for a full backtrace.
I hope the PCB photos and hardware details are useful to document this variant. And again, I'm truly sorry for the confusion — your project and support are outstanding. 🙏

[jnilo1]

No need to apologize at all — the TYGWZ1 is externally near-identical to the Lidl Silvercrest, both use the same RTL8196E + EFR32MG1B combo, and most of what we've worked through (NVM3 wipe, Stage 1/Stage 2 flow, no-FC NCP build, OpenOCD halt) applies cleanly to your board too. Your diagnostic discipline through this thread has actually been exemplary, and we've ended up with a much clearer picture of a hardware variant I didn't know existed. Thank you for the photos and silkscreen details — TYGWZ1 REV1.0.2 + TYZS4 (P/N 2.22.46.00001) is exactly what I needed to document this as a separate variant.

What the OpenOCD dump tells us

Cross-checking your PC/LR against our NCP .map:

• PC = 0x0001992c lands inside our compressPointer() (buffer-management.c, EmberZNet's buffer manager).
• LR = 0x00019b14 is inside sli_legacy_buffer_manager_mark_buffer().
• All fault registers are zero, no exception is active, basepri = 0x60 just means we halted inside a critical section.

Your binary is the no-FC variant so addresses have shifted slightly, but the neighbourhood is unambiguous: the chip is alive and actively running EmberZNet stack code — it's not crashing, not faulting, not stuck in a default handler. The RESET_UNKNOWN_REASON loop you see is therefore not a reset loop in the literal sense; it's the ASH state machine sitting in ERROR state and re-emitting the error frame because it never receives a RST it can answer.

Re-examining the evidence

That changes the question. If the chip is alive and the only missing thing is "RST never reaches it", then we need to look at what RX path actually works on this board. And when I go back through everything you've shown me, I realise we've never actually proven that any byte from the SoC has reached the EFR32's USART0 RX pin.

Test	What it actually proves
Tuya backup streaming binary in -f mode	EFR32 → SoC TX works
Gecko Bootloader menu appearing in nc after app erase	Stage 2 enters menu mode automatically when it finds no valid application, and prints the menu unprompted. It doesn't prove SoC → EFR32 RX.
No-FC NCP sending RESET_UNKNOWN_REASON ERROR frames	EFR32 → SoC TX works (again)
Z2M / bellows RST → no RSTACK	SoC → EFR32 RX is silent

We have three independent confirmations of TX, and zero of RX. Combined with the fact that the chip is demonstrably alive, the most parsimonious explanation is that TYZS4 routes the EFR32's USART0 RX (and probably CTS/RTS) to different EFR32 GPIOs than the PA0/PA1/PA4/PA5 we assume from the Silabs reference design. Tuya defines its own module-pin → EFR32-GPIO mapping, and there's no reason that mapping has to match ours.

If RX is on a different GPIO, then in our build USART0 is listening on PA1 — a pin that's simply not connected to anything coming from the SoC on TYZS4. The bytes physically arrive at the module's UART_RX test point (which we can see on the silkscreen) and then go nowhere as far as our firmware is concerned.

Cleanest way to find out — read it from your Tuya backup

Rather than reverse-engineer the Tuya binary statically, we can let it tell us its USART0 pin mapping directly. The EFR32's USART pin routing is configured by three memory-mapped registers; once Tuya's firmware has booted and configured them, halting and reading them gives us the ground truth for how this board is actually wired:

Register	Address	Tells us
USART0_ROUTEPEN	0x40010050	Which of TX / RX / CTS / RTS are enabled
USART0_ROUTELOC0	0x40010054	TXLOC[5:0] and RXLOC[13:8]
USART0_ROUTELOC1	0x40010058	CTSLOC[5:0] and RTSLOC[13:8]

Each LOC field is a 0–31 number that maps to a specific GPIO pin via the "Alternate Functionality Overview" table of the EFR32MG1 datasheet (section 6.5).

So:

1. Restore your Tuya backup over SWD (you've already done this once for the streaming test).

2. Let it boot and run for a few seconds so it's fully past init.

3. From OpenOCD telnet:

   > halt
   > mdw 0x40010050
   > mdw 0x40010054
   > mdw 0x40010058
   

4. Paste the three values back here.

From those alone I can decode the exact LOC numbers Tuya uses for TX / RX / CTS / RTS, look up the corresponding GPIOs in the datasheet, and tell you precisely which SL_IOSTREAM_USART_VCOM_*_LOC and pin assignments to change in patches/sl_iostream_usart_vcom_config.h. After that, one rebuild and one re-flash should give you a working NCP — full HW flow control included, on the right pins this time.

This avoids guessing, avoids static disassembly, and uses only tools you already have on hand.

On the project side

Once we've nailed the pinout, I'd like to add a 0-Hardware/TYGWZ1/ entry alongside the existing Lidl docs — your photos, the silkscreen revision, the TYZS4 module reference, and the corrected pin map. That way the next person who buys what looks like a Lidl gateway and finds a TYGWZ1 inside has a clear starting point. With your permission I'll credit you for the variant identification and the diagnostic legwork. Please send the link (Aliexpress I presume) where you bought it as a reference.

[jnilo1]

Hi @lornys, quick check-in — any chance you've had time to run the three mdw reads on the Tuya backup (0x40010050 / 0x40010054 / 0x40010058)?

No rush at all, just making sure the thread didn't get lost. If you hit a snag with the OpenOCD halt / mdw flow or restoring the backup, happy to walk through it. Once I have those three values you should be one rebuild + one SWD flash away from a working NCP.

[lornys]

Hi! Sorry for the delay — I've been away from home for a few days and don't have access to the hardware right now. I'll run the three mdw reads as soon as I'm back, should be in about 3 days. Thanks for checking in and for your patience! 🙏

[lornys]

Hi! First of all, sincere apologies for the very long delay.
I've been running the OpenOCD reads on the Tuya backup. The registers you originally asked for (0x40010050–0x40010058) were always zero, so I dug a bit deeper and found that the Tuya firmware uses different USART routing registers. Here's what I found consistently across multiple halt/resume cycles:

0x40010078 (ROUTEPEN): 0x00000000 — always zero when halted (Tuya may enable/disable USART dynamically)
0x4001007c (ROUTELOC0): 0x00001f01
0x40010080 (ROUTELOC1): 0x00000002

ROUTELOC0 and ROUTELOC1 were stable across all reads. Hope this is enough to decode the pin mapping — happy to run any additional reads if needed.

[jnilo1]

First — thank you for going back to the chip and pulling the routing registers. That's exactly the kind of ground-truth read that settles a question, and it did settle it, just not in the direction either of us expected. I owe you a correction.

I cross-checked the register offsets against the EFR32MG1B device header (efr32mg1b_usart.h in the Gecko SDK), and the USART0 routing block sits one register lower than the addresses we read:

Register	Offset	Absolute (USART0 @ 0x40010000)
ROUTEPEN	0x74	0x40010074
ROUTELOC0	0x78	0x40010078
ROUTELOC1	0x7C	0x4001007C

So the three values you read map like this:

You read	Value	Actually is
0x40010078	0x00000000	ROUTELOC0
0x4001007c	0x00001f01	ROUTELOC1
0x40010080	0x00000002	one word past ROUTELOC1 — outside the routing block, ignore it

Decoding with the field layout straight from the header — ROUTELOC0: RXLOC = bits[4:0], TXLOC = bits[12:8]; ROUTELOC1: CTSLOC = bits[4:0], RTSLOC = bits[12:8] (all 5-bit fields):

• ROUTELOC0 = 0x00000000 → RXLOC 0 = PA1, TXLOC 0 = PA0
• ROUTELOC1 = 0x00001f01 → CTSLOC 1 = PA5, RTSLOC 31 = PA4

(LOC → GPIO from Table 6.6 "Alternate Functionality Overview" in the EFR32MG1 Data Sheet, Rev. 1.5.)

That's TX=PA0, RX=PA1, CTS=PA5, RTS=PA4 — bit-for-bit identical to our NCP build and the Silabs reference design. So the pin-swap hypothesis is dead: the TYZS4 routes USART0 to exactly the pins our firmware already uses. Our build is correct for your hardware, and there is nothing to change on the EFR32 side.

That's actually a useful result, because it narrows things down hard. The EFR32 is listening for RX on PA1 — the right pin. If a RST never produces an RSTACK, then the bytes aren't reaching PA1 at all. In other words the gap is on the path feeding the EFR32's RX, not in how the EFR32 itself is configured. That's where we should look next.

Before we go there, one quick step to confirm this on your own board — re-read at the corrected addresses:

> halt
> mdw 0x40010074   ; ROUTEPEN
> mdw 0x40010078   ; ROUTELOC0
> mdw 0x4001007c   ; ROUTELOC1

ROUTELOC0 / ROUTELOC1 should come back as 0x00000000 / 0x00001f01 again. ROUTEPEN (0x40010074) is the one register we never actually read — its low 4 bits tell us which of TX / RX / CTS / RTS are pin-enabled. Paste those three values back and we'll be on solid ground to chase the RX feed path.

[lornys]

Here are the corrected register reads:

0x40010074 (ROUTEPEN): 0x00000033 — TX+RX+CTS+RTS all enabled*
0x40010078 (ROUTELOC0): 0x00000000 — TX=PA0, RX=PA1*
0x4001007c (ROUTELOC1): 0x00001f01 — CTS=PA5, RTS=PA4*
(with Claude help)
Identical to your NCP build. So the EFR32 pinout is correct and the RX path on the EFR32 side is properly configured. Ready for the next step - where should we look on the path feeding PA1?

[jnilo1]

That's the confirmation we needed — and ROUTEPEN = 0x00000033 is the last piece. Decoding it against the header (RXPEN = bit 0, TXPEN = bit 1, CTSPEN = bit 4, RTSPEN = bit 5):

0x33 = 0b11_0011 → RXPEN + TXPEN + CTSPEN + RTSPEN all enabled (CS and CLK off, exactly right for async UART with hardware flow control).

So the EFR32 side is now fully cleared: correct pins (TX=PA0, RX=PA1, CTS=PA5, RTS=PA4), all four signals routed to them, receiver enabled. The chip is listening for RX on PA1 and there is nothing left to change in the firmware.

That puts the break upstream of PA1: the byte stream from the RTL8196E's UART1 TX isn't reaching the EFR32's RX pin. And on this exact SoC we have a documented failure mode for precisely that.

The RTL8196E routes UART1 TX/RX to physical pins through the PIN_MUX_SEL register (physical address 0x18000040). Bits 1, 3, 6 must all be set, or the UART works internally — THRE fires, the driver believes it's transmitting — but no electrical signal leaves the SoC. Our driver sets these at probe, but two things make it worth reading on your board specifically:

1. Your gateway is a TYGWZ1 clone, not a genuine Lidl, so the mux/wiring our firmware targets may not match it.
2. On this SoC the Ethernet driver also writes the same register's [4:3] field; in earlier revisions it could clobber the UART mux after the serial driver set it.

So the first thing to read, on the gateway shell:

devmem 0x18000040 32

Bits 1, 3, 6 together are mask 0x4A. If (value & 0x4A) == 0x4A, the mux is correct and we move on to the physical wiring (whether the clone routes UART1 TX to the same module pin the genuine Lidl does). If any of those bits is clear, that's very likely your missing RX path right there.

Paste the value and we'll take it from there.

If the mux turns out correct, the definitive follow-up is on your OpenOCD side — halt and watch the EFR32's USART0_STATUS (0x40010010, RXDATAV = bit 7) and RXDATA (0x4001001c) while the SoC transmits, to confirm whether bytes physically land on PA1. But let's read the mux first; it's one command and it's the usual culprit on this hardware.

[lornys]

Good news — we already ran that check earlier in this thread. The result was:
devmem 0x18000040 32 → 0x0000004A
(0x4A & 0x4A) == 0x4A ✅ — the mux is correct, all three bits (1, 3, 6) are set.
So the mux is fine. Ready for the next step — watching USART0_STATUS (0x40010010) and RXDATA (0x4001001c) while the SoC transmits, to confirm whether bytes physically reach PA1.