4108ES Halow WiFi module driver fails during CMD53 initialization (SPI, Linux 4.9)

[Rjie930]

Hello,

I am working on integrating a 4108ES Halow WiFi module via SPI (using a CH347 USB-SPI bridge) on Linux kernel 4.9.170 (aarch64).
During the driver probe sequence, the initialization process fails at the CMD53 read stage.

Below are the kernel logs:

uname -a

Linux buildroot 4.9.170 #110 SMP PREEMPT Thu Apr 3 16:12:20 CST 2025 aarch64 GNU/Linux

dmesg -c

[ 2798.540040] usb 3-1.2: USB disconnect, device number 8
[ 2798.540951] mphsi-ch34x 3-1.2:1.4: ch34x_usb_disconnect: ch34x adapter now disconnected
[ 2799.308040] usb 3-1.4: USB disconnect, device number 7
[ 2799.555853] usb 3-1.4: new high-speed USB device number 9 using sunxi-ehci
[ 2799.739211] usb 3-1.4: reset high-speed USB device number 9 using sunxi-ehci
[ 2799.894292] r8152 3-1.4:1.0 eth1: v1.08.9
[ 2799.909195] usb 3-1.2: new high-speed USB device number 10 using sunxi-ehci
[ 2800.008805] mphsi-ch34x 3-1.2:1.4: ch34x_cfg_probe: output SPI slave with CS0
[ 2800.008815] mphsi-ch34x 3-1.2:1.4: ch34x_cfg_probe: output SPI slave with CS1
[ 2800.009358] mphsi-ch34x 3-1.2:1.4: ch34x_spi_probe: SPI master connected to SPI bus 3
[ 2800.009818] mphsi-ch34x 3-1.2:1.4: ch34x_mphsi_i2c_probe: I2C master connected to I2C bus 4
[ 2800.010378] mphsi-ch34x 3-1.2:1.4: ch34x_mphsi_gpio_probe: registered GPIOs from 504 to 511
[ 2800.027547] morse_spi_probe: gpio_base = 504
[ 2800.032780] spi_setup: mode=0, speed=50000000, bits_per_word=8, chip_select=0
[ 2800.040837] morse_spi_initsequence
[ 2800.045046] ch347_spi_native TX: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[ 2800.045273] ch347_spi_native RX: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[ 2800.045775] SD_IO_MORSE_INIT
[ 2800.049026] ch347_spi_native TX: ff 7f 00 00 00 00 33 ff ff ff ff ff ff ff ff ff ff ff ff ff
[ 2800.049169] ch347_spi_native RX: ff ff ff ff ff ff ff ff 00 ff ff ff ff ff ff ff ff ff ff ff
[ 2800.049251] morse_reg32_read chip_id
[ 2800.053301] ch347_spi_native TX: ff 74 92 00 00 05 d1 ff ff ff ff ff ff ff ff ff ff ff ff ff
[ 2800.053524] ch347_spi_native RX: ff ff ff ff ff ff ff ff ff 00 05 ff ff ff ff ff ff ff ff ff
[ 2800.053610] ch347_spi_native TX: ff 74 92 00 02 10 95 ff ff ff ff ff ff ff ff ff ff ff ff ff
[ 2800.053777] ch347_spi_native RX: ff ff ff ff ff ff ff ff ff 00 10 ff ff ff ff ff ff ff ff ff
[ 2800.053866] ch347_spi_native TX: ff 74 92 00 04 02 f7 ff ff ff ff ff ff ff ff ff ff ff ff ff
[ 2800.054026] ch347_spi_native RX: ff ff ff ff ff ff ff ff ff 00 02 ff ff ff ff ff ff ff ff ff
[ 2800.054118] ch347_spi_native TX: ff 75 14 9a 40 04 0f ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[ 2800.054277] ch347_spi_native RX: ff ff ff ff ff ff ff ff 00 00 ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[ 2800.054366] morse_spi_find_token failed
[ 2800.058701] morse_spi_cmd53_read failed
[ 2800.063012] morse_spi spi3.0: spi: cmd53_read fn=1 0x00004d20:4 r=0x10050002 b=0xffffffff (ret:-71)
[ 2800.073151] morse_spi spi3.0: morse_spi_reg32_read failed (errno=-71)
[ 2800.080383] morse_spi spi3.0: morse_chip_cfg_detect_and_init: Failed to access HW (errno:-5)
[ 2800.089843] morse_spi spi3.0: morse_chip_cfg_detect_and_init failed: -5
[ 2800.097287] morse_spi_probe failed. The driver has not been loaded!
[ 2800.104342] morse_spi: probe of spi3.0 failed with error -5
[ 2800.104361] mphsi-ch34x 3-1.2:1.4: ch34x_mphsi_gpio_probe: Halow Wifi SPI device created, bus_num: 3, chip_select: 0
[ 2800.104455] mphsi-ch34x 3-1.2:1.4: ch34x_usb_probe: USB to SPI/I2C/GPIO adapter ch34x now attached.

From the trace, CMD53 read (function 1, address 0x4D20, 4 bytes) always returns invalid data (0xFFFFFFFF) and the driver aborts.

Questions:

1. Is there a specific initialization sequence required for the 4108ES before CMD53 transactions can succeed?
2. Are there hardware configuration requirements (pull-ups, clocking, reset timing, etc.) that must be ensured for proper SPI communication?

Any guidance or reference to documentation would be greatly appreciated.

Environment:

• Linux kernel 4.9.170, aarch64
• SPI mode 0, 50 MHz, 8 bits per word
• Module: 4108ES Halow WiFi over SPI
• Driver: morse_spi

[Rjie930]

somebody help，how make it work

[flex84]

How is the FN-Link module physically connected, do you have a schematic / photo of your setup that you can share?

It would also be good to show waveforms of your SPI interface, and details of how you’ve configured SPI (incl clock speeds etc).

If you’re looking for a native USB interface then it might be worth considering MM8108 over MM6108. General availability just got announced, see https://www.eetimes.com/from-sydney-to-smart-cities-morse-micro-on-the-road-to-iot-2-0/#google_vignette

[Rjie930]

SPI configuration: mode=0, speed=400 kHz, bits_per_word=8, chip_select=0

This is the CMD53 SPI waveform captured by the logic analyzer.
The MISO signal is shifted by one bit earlier, so the actual data should be referenced from the ch347_spi_native RX log output.

[ajudge]

Hi @Rjie930

Can you share the entire logic analyzer capture file from boot please, and not just a screenshot. SPI on the MM6108 requires a specific initialisation sequence, involving an inverted CS line which could be causing the behaviour you are seeing in the initial post.

[Rjie930]

I want to upload de file but it’s show : “Sorry, new users can not upload attachments.” dosen’t matter i upload to the : github：logic-analyzer-capture-file

[Rjie930]

the entire logic analyzer capture file from boot:driver_init_spi_waveform.sal (4.5 KB)

[ajudge]

Hi @Rjie930

Sorry for the late reply. Looking at your logic analyzer trace I can see the correct initialisation sequence, and as you’ve pointed out the data capture is shifted 1 bit earlier.
But looking at the captured cmd52 response data you have in ch347_spi_native, this matches the expected SPI bring up responses.

So from the data we have captured, everything appears to be behaving correctly!

Except this last command

[ 2800.054118] ch347_spi_native TX: ff 75 14 9a 40 04 0f ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff

Should be returning

[ 2800.054277] ch347_spi_native RX: ff ff ff ff ff ff ff ff 00 00 ff fe 06 03 00 00 7e c9 ff ff ff ff ff ff

As far as your second set of questions go:

• Make sure the reset gpio is toggled before the SPI driver is inserted for probe. On our evaluation kits the following script is run on boot. morse-feed/hardware/morse-bundle/files/morse/scripts/chipreset.sh at a62540fb88b9d8ce31fd088327db464f71f4e303 · MorseMicro/morse-feed · GitHub
  However, I don’t think this is your issue.

• Make sure VBAT is applied before or at the same time as VDDIO. Don’t allow it to come up after VDDIO.

• You will require a pull-up on the SDIO-D2 pin of the module.

• Make sure the WAKE pin is driven high by the host, or pulled up.

• There shouldn’t be any issues with your current clocking

Do you have any schematic snippets you can share around the module?

[Rjie930]

Hi @ajudge,

That was exactly the issue — the SDIO-D2 pin was left floating on my setup.
After adding a pull-up to that line, the CMD53 communication now works correctly.

Thank you very much for your guidance!

Best regards

[ajudge]

Glad that worked for you!