# ESP32-C6 + FGH100MAAMD (MM6108) -  "FW manifest pointer not set"

**URL:** <https://community.morsemicro.com/t/esp32-c6-fgh100maamd-mm6108-fw-manifest-pointer-not-set/1483>\
**Category:** Embedded\
**Created:** [March 17, 2026, 3:48pm UTC](https://community.morsemicro.com/t/esp32-c6-fgh100maamd-mm6108-fw-manifest-pointer-not-set/1483 "2026-03-17T15:48:02Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![Days](https://avatars.discourse-cdn.com/v4/letter/d/8edcca/32.png) [@Days](https://community.morsemicro.com/u/Days)\
**Post date:** [March 17, 2026, 3:48pm UTC](https://community.morsemicro.com/t/esp32-c6-fgh100maamd-mm6108-fw-manifest-pointer-not-set/1483/1 "2026-03-17T15:48:02Z")

</div>

Hello.

I am trying to use a **Quectel** **FGH100MAAMD (MM6108)** together with an **ESP32-C6** over **SPI** , using **MM-IoT-ESP32**.

The **porting\_assistant** example passes smoothly, all the tests, but the **sta\_connect** example gives me the error: **“FW manifest pointer not set“**.  
I am posting to ask whether i am missing something in the firmware/BCF setup, or whether this points to an incompatibility/mismatch between the SDK and BCF.

## Software / version

- **mm-iot-sdk:** 2.10.4
- **mm-iot-esp32 commit** : 96d9bf4
- **ESP-IDF** : 5.5.3

## Hardware

Custom board with:

- **ESP32-C6-MINI-1**
- **Quectel FGH100MAAMD**
- Supply: 3.3V

## BCF / firmware setup

I am using the BCF .bin file from [morse-firmware/bcf/quectel/bcf\_fgh100maamd.bin at main · MorseMicro/morse-firmware · GitHub](https://github.com/MorseMicro/morse-firmware/blob/main/bcf/quectel/bcf_fgh100maamd.bin), and using the [mm-iot-esp32/framework/tools/buildsystem/convert-bin-to-mbin.py at main · MorseMicro/mm-iot-esp32 · GitHub](https://github.com/MorseMicro/mm-iot-esp32/blob/main/framework/tools/buildsystem/convert-bin-to-mbin.py) script to convert the .bin file to .mbin. And the **MM Firmware File** is set to **mm6108.mbin**. I just configured the project in the menuconfig, the rest of the example is unmodified.

## porting\_assistant output

```auto
MM-IoT-SDK Porting Assistant
----------------------------

Memory allocation [PASS]
Memory reallocation [PASS]
Passage of time [PASS]
Task creation and preemption [PASS]
WLAN HAL initialisation Actual SPI CLK 40000kHz

Hard reset device
SDIO/SPI Startup [PASS]
Read chip id from the MM chip [PASS]

        Chip ID: 0x0306

Verify BUSY pin [PASS]
Bulk write/read into the MM chip [PASS]
Raw throughput test [PASS]

Note: This will not be the final WLAN TPUT. See test step for more info.
        Time spent (ms): 2520
        Transaction count: 9
        Bytes xferred: 26928
        Raw TPUT (kbit/s): 85

Validate MM firmware [PASS]
Validate BCF [PASS]

13 total test steps. 11 passed, 0 failed, 2 no result, 0 skipped
I (6511) main_task: Returned from app_main()

```

As i can tell, the communication between the IC’s is working and the MM6108 is fine.

## sta\_connect output

```auto
I (379) main_task: Calling app_main()

Morse STA Demo (Built Mar 17 2026 10:01:01)

Actual SPI CLK 40000kHz
E 5460 FW manifest pointer not set
E 5486 Failed
E 5512 Failed
E 5512 Firmware init failed
-----------------------------------
  HW Version: esp32c6
  BCF API version: 8.0.0
  BCF build version: 6b00e4d 2031952 _Modified
  BCF board description: mf08251
  !! Error occured whilst retrieving version info !!
  Morselib version:
  Morse firmware version:
  Morse chip ID: 0x0000
  Morse chip name:
-----------------------------------

```

Its confusing to me, because porting\_assistant can talk to the chip and read chip ID **0x306** , but the sta\_connect reports the chip ID as **0x0000**.  
And the BCF version appears to be recognized, as it reads the API version 8.0.0, build version and board description, but it fails with “FW manifest pointer not set”.

## Questions

1. What are the possible causes for the **“FW manifest pointer not set”** message, exactly?
2. For **FGH100MAAMD** , is converting **bcf\_fgh100maamd.bin** to .mbin with **convert-bin-to-mbin.py** the correct procedure for **mm-iot-esp32**?
3. Is **ESP32-C6** expected to work with this setup, or are there known limitations compared to S3?
4. Since **porting\_assistant** passes, does this suggests that the issue is **not hardware/SPI** , but purely **firmware/software/configuration**?

Any guidance would be much appreciated, i would be glad to provide any more information.

Thanks.

---

<div class="post-metadata">

**Author:** ![cmistry](https://avatars.discourse-cdn.com/v4/letter/c/ccd318/32.png) [@cmistry](https://community.morsemicro.com/u/cmistry)\
**Post date:** [March 19, 2026, 4:18am UTC](https://community.morsemicro.com/t/esp32-c6-fgh100maamd-mm6108-fw-manifest-pointer-not-set/1483/2 "2026-03-19T04:18:07Z")

</div>

Hi @Days

Please can you try doing a `clean build`

> Since **porting\_assistant** passes, does this suggests that the issue is **not hardware/SPI** , but purely **firmware/software/configuration**?

Yes, it suggests that everything _should_ be working fine, and something unexpected happening with this configuration.

FWIW we are unable to reproduce your issue with a similar module

---

<div class="post-metadata">

**Author:** ![Days](https://avatars.discourse-cdn.com/v4/letter/d/8edcca/32.png) [@Days](https://community.morsemicro.com/u/Days)\
**Post date:** [March 19, 2026, 10:36am UTC](https://community.morsemicro.com/t/esp32-c6-fgh100maamd-mm6108-fw-manifest-pointer-not-set/1483/3 "2026-03-19T10:36:34Z")

</div>

Thanks for the response.

Unfortunately doing a `clean build` generates the same error.

Do you have a ESP32-C6 + FGH100MAAMD build? What is the version of your ESP-IDF? Could you pass me your working directory somehow?

Thanks.

---

<div class="post-metadata">

**Author:** ![Days](https://avatars.discourse-cdn.com/v4/letter/d/8edcca/32.png) [@Days](https://community.morsemicro.com/u/Days)\
**Post date:** [March 25, 2026, 4:31pm UTC](https://community.morsemicro.com/t/esp32-c6-fgh100maamd-mm6108-fw-manifest-pointer-not-set/1483/4 "2026-03-25T16:31:39Z")

</div>

Sorry. There was a power supply problem on our board that was causing the problem. Case closed.
