HCM111Z Resets When Controlling a Relay via GPIO in a QuecOpen SDK Application

WIFI/BT
1

Hello Quectel Team,

We are currently developing firmware for the HCM111Z module using the QuecOpen SDK.

In our application, one GPIO is used to control a relay. We are experiencing an issue where the HCM111Z module immediately resets whenever the relay is switched on through the GPIO.

The interesting point is that we have previously used the same HCM111Z hardware design with standard AT commands and an external MCU, and we didn’t encountered this problem. The issue only appeared after migrating the application to QuecOpen SDK and running the application directly on the HCM111Z.

We are already investigating the hardware side. We have tested additional capacitors, LC filters, and various power supply improvements, but the problem still persists.

We would like to know whether there are any software-related settings or debugging methods available in the QuecOpen SDK that could help us identify the root cause of the reset.

Specifically:

  1. Is there a way to determine the reset reason (e.g., watchdog reset, brownout reset, power-on reset, software reset, etc.)?

  2. Does the SDK include brownout detection mechanisms that could trigger a reset when a relay causes a temporary voltage drop?

  3. Are there any watchdog-related configurations that could unintentionally cause a reset?

  4. Do you have any recommendations for GPIO-driven relay applications on HCM111Z when running under QuecOpen SDK?

Any guidance on how to diagnose the source of the reset would be greatly appreciated.

Thank you for your support.

Best regards,

2

Hi Haron,

Sorry for the late reply.

May I know if you have collected any debug logs so far? Before we can determine the root cause of the issue, we will need the debug logs for further analysis.

To capture the GPIO debugging logs, open UART port 1 (GPIO 1) to obtain the debugging logs. The log information will be displayed as follows:

image
image345×173 4.28 KB

You might need to manually fly wire and connect the pin through a USB-TTL board to get the output on your serial port tools.

If the following information is printed during the debugging, it indicates that the GPIO interrupt has been triggered.

image
image267×277 7.87 KB

FYI, UART PORT 1 is located at pin 4, sharing the same PIN as GPIO 1. You can find the materials using the hardware design document of HCM111Z:

image
image562×487 22.1 KB

image
image714×184 7.14 KB

3

Along with the logs, if you could provide info on

(1) Which GPIO triggered the RESET
(2) The QuecOpen code related to that specific GPIO Control
(3) If available, share the PCB design on your board or just the specific part on the GPIO pin

I have emailed you separately, you can also send the files through email