Feasibility of Porting Wi-Fi HaLow Code from STM32U to STM32F407G-DISC1

Software Embedded
1

Dear Team,

I would like to confirm whether the existing Wi-Fi HaLow code, which is currently developed for the STM32U series MCU, can be ported to the STM32F407G-DISC1 platform.

Is this migration officially supported? If so, could you please let me know whether there are any known limitations or compatibility issues that should be considered during the porting process?

From my understanding, the STM32U and STM32F4 families have different HAL drivers, clock configurations, peripheral implementations, startup files, and CMSIS support. Therefore, I expect that the hardware-dependent layer (SPI, GPIO, DMA, UART, interrupts, timers, etc.) will require modification while the Wi-Fi HaLow protocol and application logic can remain largely unchanged.

Could you also advise if there are any known issues that may be encountered during the migration, such as:

  • SPI communication or timing issues
  • Driver or HAL compatibility problems
  • Clock configuration differences
  • DMA or interrupt-related issues
  • Any STM32U-specific dependencies that are difficult to replace
  • Other known limitations when using the STM32F407G-DISC1

If there are any application notes, porting guides, or reference projects available for STM32F4, I would greatly appreciate it if you could share them.

Thank you for your support. I look forward to your guidance.

Kind regards,

Amal Jishnu

2

Hi @amaljishnuinthings7

Yes this is supported. You will need to provide the appropriate platforms and bsps files.

You can use the Morse Micro IoT SDK Porting Guide | App Note 45 as a reference for porting.

These are very out of date, but as a point of reference, we previously released files for an F4 platform:

3

The Morse Micro development board does not have a test point for the BUSY pin. So, I implemented the BUSY pin logic entirely in software instead of using a physical BUSY pin. Is this approach correct?

Pin Configuration:

  • CLK (PB13) → SPI2 Clock
  • MISO (PB14) → SPI2 Master In Slave Out
  • MOSI (PB15) → SPI2 Master Out Slave In
  • CS (PB12) → Chip Select
  • RESET (PE0) → Reset Transceiver
  • WAKE (PD0) → Wakeup Control
  • SPI IRQ (PE1) → Interrupt
  • BUSY (PB5) → Not connected / Unused (BUSY logic is handled entirely in software)
4

Current Progress

  • Phase 1: MCU & SPI Hardware Initialization — COMPLETE

  • Phase 2: Transceiver Hardware Reset & Training Sequence — COMPLETE

  • Phase 3: ROM Bootloader Handshake & Chip ID 0x0809 Verification — COMPLETE

  • Phase 3: Firmware Payload Upload (fw_mm8108b2_rl) — IN PROGRESS NOW (8,192-byte DMA chunks)

  • Phase 4: Transceiver Boot & Wi-Fi AP Connection (INTHINGS-HALOW) — NEXT

The ROM bootloader handshake succeeds, and the chip ID is correctly detected as 0x0809. However, firmware initialization fails after the firmware and BCF are processed.

Below is the complete boot log:

[0000.038] ---> [LOG] Log level set to verbose....!
[0000.043] ---> [HALOW_APP]   STM32F407 Wi-Fi HaLow AP Connection V25 (SLEEP DISABLE)
[0000.051] ---> [HALOW_APP] ========================================
[0000.058] ---> [HALOW_APP] Initialising Wi-Fi HaLow interface (SPI Mode 0 - 2.625MHz)...
[0000.067] ---> [APP_WLAN] Step 1: Preparing WLAN subsystem (mmwlan_init)...
[0000.075] ---> [APP_WLAN] Step 2: Booting Wi-Fi HaLow module (mmwlan_boot)...
[0000.083] ---> [HAL_WLAN] mmhal_wlan_init() called
[0000.088] ---> [HAL_WLAN] hard_reset() start: PE0 LOW...
[0000.154] ---> [HAL_WLAN] hard_reset() complete: PE0 HIGH.
[0000.210] ---> [HAL_WLAN] send_training_seq() bit-bang 80 clocks start
[0000.217] ---> [HAL_WLAN] send_training_seq() complete
[HAL_BIN] FW read: offset=0, req_len=4 -> ret_len=4
[HAL_BIN] FW read: offset=4, req_len=4 -> ret_len=4
[HAL_BIN] FW read: offset=8, req_len=4 -> ret_len=4
[HAL_BIN] FW read: offset=12, req_len=4 -> ret_len=4
[HAL_BIN] FW read: offset=16, req_len=4 -> ret_len=4
[HAL_BIN] FW read: offset=20, req_len=4 -> ret_len=4
[HAL_BIN] FW read: offset=24, req_len=8192 -> ret_len=8192
[HAL_BIN] FW read: offset=8216, req_len=4 -> ret_len=4
[HAL_BIN] FW read: offset=8220, req_len=4 -> ret_len=4
[HAL_BIN] FW read: offset=8224, req_len=32768 -> ret_len=32768
[HAL_BIN] FW read: offset=40992, req_len=4 -> ret_len=4
[HAL_BIN] FW read: offset=40996, req_len=4 -> ret_len=4
[HAL_BIN] FW read: offset=41000, req_len=32768 -> ret_len=32768
[HAL_BIN] FW read: offset=73768, req_len=4 -> ret_len=4
[HAL_BIN] FW read: offset=73772, req_len=4 -> ret_len=4
[HAL_BIN] FW read: offset=73776, req_len=20928 -> ret_len=20928
[HAL_BIN] FW read: offset=94704, req_len=4 -> ret_len=4
[HAL_BIN] FW read: offset=94708, req_len=4 -> ret_len=4
[HAL_BIN] FW read: offset=94712, req_len=3920 -> ret_len=3920
[HAL_BIN] FW read: offset=98632, req_len=4 -> ret_len=4
[HAL_BIN] FW read: offset=98636, req_len=4 -> ret_len=4
[HAL_BIN] FW read: offset=98640, req_len=3720 -> ret_len=3720
[HAL_BIN] FW read: offset=102360, req_len=4 -> ret_len=4
[HAL_BIN] FW read: offset=102364, req_len=4 -> ret_len=4
[HAL_BIN] FW read: offset=102368, req_len=3612 -> ret_len=3612
[HAL_BIN] FW read: offset=105980, req_len=4 -> ret_len=4
[HAL_BIN] FW read: offset=105984, req_len=4 -> ret_len=4
[HAL_BIN] FW read: offset=105988, req_len=32768 -> ret_len=32768
[HAL_BIN] FW read: offset=138756, req_len=4 -> ret_len=4
[HAL_BIN] FW read: offset=138760, req_len=4 -> ret_len=4
[HAL_BIN] FW read: offset=138764, req_len=32768 -> ret_len=32768
[HAL_BIN] FW read: offset=171532, req_len=4 -> ret_len=4
[HAL_BIN] FW read: offset=171536, req_len=4 -> ret_len=4
[HAL_BIN] FW read: offset=171540, req_len=32768 -> ret_len=32768
[HAL_BIN] FW read: offset=204308, req_len=4 -> ret_len=4
[HAL_BIN] FW read: offset=204312, req_len=4 -> ret_len=4
[HAL_BIN] FW read: offset=204316, req_len=32768 -> ret_len=32768
[HAL_BIN] FW read: offset=237084, req_len=4 -> ret_len=4
[HAL_BIN] FW read: offset=237088, req_len=4 -> ret_len=4
[HAL_BIN] FW read: offset=237092, req_len=6524 -> ret_len=6524
[HAL_BIN] FW read: offset=243616, req_len=4 -> ret_len=4
[HAL_BIN] FW read: offset=243620, req_len=4 -> ret_len=4
[HAL_BIN] FW read: offset=243624, req_len=3088 -> ret_len=3088
[HAL_BIN] FW read: offset=246712, req_len=4 -> ret_len=4
[HAL_BIN] FW read: offset=246716, req_len=4 -> ret_len=4
[HAL_BIN] FW read: offset=246720, req_len=28040 -> ret_len=28040
[HAL_BIN] FW read: offset=274760, req_len=4 -> ret_len=4
[HAL_BIN] FW read: offset=274764, req_len=4 -> ret_len=4
[HAL_BIN] FW read: offset=274768, req_len=3188 -> ret_len=3188
[HAL_BIN] FW read: offset=277956, req_len=4 -> ret_len=4
[HAL_BIN] FW read: offset=277960, req_len=4 -> ret_len=4
[HAL_BIN] FW read: offset=277964, req_len=32768 -> ret_len=32768
[HAL_BIN] FW read: offset=310732, req_len=4 -> ret_len=4
[HAL_BIN] FW read: offset=310736, req_len=4 -> ret_len=4
[HAL_BIN] FW read: offset=310740, req_len=18516 -> ret_len=18516
[HAL_BIN] FW read: offset=329256, req_len=4 -> ret_len=4
[HAL_BIN] FW read: offset=329260, req_len=4 -> ret_len=4
[HAL_BIN] FW read: offset=329264, req_len=5836 -> ret_len=5836
[HAL_BIN] FW read: offset=335100, req_len=4 -> ret_len=4
[HAL_BIN] FW read: offset=335104, req_len=4 -> ret_len=4
[HAL_BIN] FW read: offset=335108, req_len=3040 -> ret_len=3040
[HAL_BIN] FW read: offset=338148, req_len=4 -> ret_len=4
[HAL_BIN] FW read: offset=338152, req_len=4 -> ret_len=4
[HAL_BIN] FW read: offset=338156, req_len=25880 -> ret_len=25880
[HAL_BIN] FW read: offset=364036, req_len=4 -> ret_len=4
[HAL_BIN] FW read: offset=364040, req_len=4 -> ret_len=4
[HAL_BIN] FW read: offset=364044, req_len=3612 -> ret_len=3612
[HAL_BIN] FW read: offset=367656, req_len=4 -> ret_len=4
[HAL_BIN] FW read: offset=367660, req_len=4 -> ret_len=4
[HAL_BIN] FW read: offset=367664, req_len=1696 -> ret_len=1696
[HAL_BIN] FW read: offset=369360, req_len=4 -> ret_len=4
[HAL_BIN] BCF read: offset=0, req_len=4 -> ret_len=4
[HAL_BIN] BCF read: offset=4, req_len=4 -> ret_len=4
[HAL_BIN] BCF read: offset=8, req_len=4 -> ret_len=4
[HAL_BIN] BCF read: offset=12, req_len=192 -> ret_len=192
[HAL_BIN] BCF read: offset=204, req_len=4 -> ret_len=4
[HAL_BIN] BCF read: offset=208, req_len=4 -> ret_len=4
[HAL_BIN] BCF read: offset=212, req_len=68 -> ret_len=68
E     2061 Fa36fmst pointer not set
E     2061 Failed
E     2061 Failed
E     2061 Failed
E     2061 Failed
E     2061 Firmware init failed
[0002.099] ---> [APP_WLAN] ERROR: mmwlan_boot failed with status 1! Resetting MCU...
5

ldennis could you please reply?

6

Hi @amaljishnuinthings7

Just to verify your hardware connection, and that your firmware load hal functions are correct, have you run the porting assistant application? This will step you through the necessary hardware bringup tests.

The other way a “firmware manifest pointer not set” could crop up is using the wrong binary files. Are you using the .mbin files provided in the mm-iot-sdk?

7

Subject: Re: STM32F407 + MM8108 SPI Bringup - Hardware Verification & Binary Query

Hi sir,

Thank you for the guidance! Here is the status of our hardware connections and firmware configuration:

1. Hardware Connections & Bringup Status:

We are interfacing an STM32F407 Host MCU with an MM8108B2 module over SPI2 (SPI Mode 0 @ 2.625MHz). We have verified all 7 physical lines with a multimeter and active live-pulse tests:

  • CLK: PB13 (SPI2_SCK, AF5)
  • MISO: PB14 (SPI2_MISO, AF5)
  • MOSI: PB15 (SPI2_MOSI, AF5)
  • CS: PB12 (GPIO Output, Active LOW)
  • RESET_N: PE0 (GPIO Output, Active LOW)
  • WAKE: PD0 (GPIO Output, Active HIGH)
  • SPI IRQ: PE1 (EXTI1 Falling Edge Input)

Live GPIO toggling tests confirm that RESET_N, WAKE, and CS are all responding properly to MCU drive.

2. Firmware Binary (.mbin / BCF) Verification:

Regarding the firmware binary:

  • We are serving fw_mm8108b2-rl and bcf_mf15457 via mmhal_wlan_read_fw_file() and mmhal_wlan_read_bcf_file().
  • Could you confirm if fw_mm8108b2-rl.mbin has a specific manifest header layout requirement at offset=0 when provided to morselib (e.g. alignment or size stripped vs full header)?

3. Porting Assistant:

We would love to run the Porting Assistant application to complete the step-by-step automated bringup sequence. Could you share the recommended config/source setup for running the porting_assistant on an STM32F4 bare-metal/FreeRTOS port?

8

The BUSY pin is not physically connected to the hardware. BUSY signal is controlled and handled through the code only, is that make error ?

ajudge ldennis could you please reply ?

9

What is fw_mm8108b2-rl - specifically why is it prefixed with fw_, and is it the mm8108b2_rl.mbin file provided in the repository?

Connect the busy pin properly. While i believe it’s unlikely to cause the manifest pointer error you are seeing you are losing feedback from the chip by implementing busy in software.

It sounds like you’ve already got a significant chunk of a port going for the STM32F4 that building the porting assistant should now just he replacing application files with those from the porting assistant sample. It depends how you’ve structured your port.