FGH100M-H / MM6108: 4 modules permanently lose TX/RX while MM6108/BCF still appears operational

Software Embedded
1

Hi Morse Micro team,
We are investigating a repeatable issue with Quectel FGH100M-H modules (MM6108 based) and would appreciate help determining whether we are dealing with an MM6108 firmware/BCF issue, external FEM/PA failure, or another RF-front-end failure mechanism.
Hardware/setup:

  • Host MCU: ESP32-S3

  • HaLow module: Quectel FGH100M-H

  • Interface: SPI

  • Operating band: 915 MHz region

  • Configured TX power: 18 dBm

  • One device operates as STA, the other as SoftAP

  • STA sends a small data packet approximately once per second

  • AP primarily transmits when a control operation is requested

  • External antenna is used

  • Power rails have been checked and remain within specification

  • We have also tested the system under demanding battery/motor operating conditions and have not been able to reproduce the radio failure from the power/motor side.
    Failure history:

    We have now experienced the same type of failure on four units.

    The interesting part is that these failures occurred during operation at one particular test location. The same hardware/design has been tested successfully in other locations, including long-range testing, without this permanent failure.

    The affected units initially communicate normally. After the failure occurs, HaLow communication is permanently lost.

    Afterward:

    • There is no TX communication
    • There is no RX communication
    • Power rails remain present/normal
    • There is no obvious supply short
    • ESP32-S3 remains operational
    • Communication with the MM6108 appears sufficiently functional for firmware/BCF initialization
    • BCF is successfully detected/loaded
    • However, the RF interface no longer provides usable TX or RX
    • Power cycling does not restore RF operation

    We originally developed the product using the older MorseMicro/mm-iot-esp32 repository. We recently discovered that this repository is now archived/deprecated and that ESP32 development has moved to MorseMicro/esp-halow.

    To eliminate our application firmware as the cause, we took an already-failed board and tested it using the latest esp-halow stack and the standard Morse Micro STA and SoftAP examples. The radio still could not establish communication.

    Therefore, simply moving the failed hardware to the current SDK/firmware does not recover it.

    We would particularly appreciate guidance on the following:

    1. Is it possible for the MM6108 to boot, communicate with the host and successfully process/load its BCF while the external PA/FEM or RF front end has permanently failed?
    2. Is there a recommended MM6108 diagnostic/test that can determine whether the internal MM6108 RF TX/RX path itself is functioning, independently of the external high-power FEM/PA used by the FGH100M-H?
    3. Are there any test modes/API commands that can generate a continuous or controlled RF carrier/packet transmission so that we can measure RF output directly with a spectrum analyzer?
    4. Is there any API/diagnostic register that reports FEM state, PA enable, TX power/calibration status, RF errors, or other information that could distinguish a failed external FEM from an MM6108 RF failure?
    5. Could an older/incompatible combination of MM-IoT-SDK, MM6108 firmware and module BCF incorrectly control an external FEM/PA — for example PA enable timing/polarity, RF switching, bias, gain/power calibration or TX duty — in a way capable of permanently damaging the external RF front end?
    6. Were there any known RF/FEM-related issues fixed between the older mm-iot-esp32 releases and the current esp-halow/MM-IoT-SDK releases?
    7. Does the MM6108/BCF provide any protection against excessive RF power arriving at the antenna/RX path, and is there a way to determine from software whether an RF-overstress event may have occurred?
    8. Are there any OTP/regulatory/firmware states that could leave the MM6108 apparently operational to the host but permanently prevent RF TX/RX? If so, how can we read/check those states?

    The fact that this has now happened to four modules, while the digital side remains operational and we cannot reproduce the failure through power/battery/motor testing, is why we are trying to determine exactly where the RF failure occurs.
    Any recommended diagnostic procedure for separating:

    MM6108 SoC failure vs. BCF/firmware issue vs. external FEM/PA failure

    would be greatly appreciated.

    Thanks.