SIM7022 Fails to Register on Network When Interfaced with STM32L496ZG via UART

[Taksh]

Hello ST Community,

We are currently working on a project involving NB-IoT connectivity using the SIMCom SIM7022 modem, which is interfaced with the STM32L496ZG microcontroller via UART. Our goal is to establish MQTT communication with AWS IoT Core by sending AT commands from the MCU to the modem.

Working Standalone Test:

Before integrating with the STM32 MCU, we tested the SIM7022 module using a USB-to-TTL converter connected to a PC terminal. In this setup, the modem behaves as expected:

• Responds to AT commands properly (e.g., AT, ATI, AT+CSQ)

• Shows strong signal strength (AT+CSQ returns good RSSI)

• Registers on the NB-IoT network (AT+CEREG? returns +CEREG: 5,5)

• Connects to AWS IoT MQTT broker over SSL/TLS with certificate authentication

This confirmed that the firmware version 2110B13SIM7022 works correctly and the modem is functioning properly.

Issue with STM32L496ZG Integration:

When we use the STM32L496ZG to send the same AT commands to the SIM7022 module through UART, the results are inconsistent:

• The modem responds correctly to general commands: AT, ATI, AT+CPIN?, AT+CGSN, etc.

• But the network registration fails. When we send AT+CEREG?, the responses are:

  • Initially: +CEREG: 5,2 → Not registered, searching

  • After a delay: +CEREG: 5,3 or +CEREG: 5,0 → Registration denied or not registered

• As a result, we cannot get a valid signal (AT+CSQ shows poor or invalid signal) or establish a network connection.

Observations:

• The UART communication seems reliable — there are no garbage characters, and echo/response works well.

• Power supply is stable, and the modem boots properly.

• SIM card is active and functional (confirmed in standalone tests).

• We're using basic UART (no hardware flow control enabled: RTS/CTS are not used).

• Using the same command sequence that worked in the standalone setup.

Questions:

1. What could cause the modem to fail network registration only when interfaced with STM32?

2. Are there additional pins (e.g., DTR, RTS, CTS, RI, DCD) that need to be handled/configured by the MCU for proper modem operation?

3. Is there any specific UART configuration recommended for STM32 when working with NB-IoT modems like SIM7022?

4. Could timing, delays, or UART baudrate mismatch cause this kind of issue (though commands respond properly)?

5. Any ST-specific tips for reliable UART communication or NB-IoT module integration?

---

Hardware Setup:

• MCU: STM32L496ZG

• Modem: SIM7022 (Firmware: 2110B13SIM7022)

• UART Baudrate: 9600

• Power Supply: 3.8V regulated (with sufficient current headroom)

• Connections: TX, RX, GND, VCC (No flow control lines used)

Thank you in advance for your support!

Best regards,
Taksh Patel
Sr. Embedded Firmware Engineer

[Andrew Neil]

---

@Taksh wrote:

Are there additional pins (e.g., DTR, RTS, CTS, RI, DCD) that need to be handled/configured by the MCU for proper modem operation?

---

You'd need to ask the module manufacturer that - it's nothing to do with ST!

What does the module documentation tell you?

Did you use any of those pins in your "standalone" testing?

---

@Taksh wrote:

Is there any specific UART configuration recommended for STM32 when working with NB-IoT modems like SIM7022?

---

A UART is a UART - that's the whole point of such standard interfaces!

---

@Taksh wrote:

Could timing, delays, or UART baudrate mismatch cause this kind of issue (though commands respond properly)?

---

If the baud rate were wrong, the commands wouldn't work at all.

In your "standalone" tests, were you sending commands by manually typing at the terminal keyboard?

Clearly, a microcontroller will send with very much faster timing!

Probably the commonest mistake is to just use arbitrary delays and not wait for & act on the replies from the modem

Have you tried "sniffing" the comms between your STM32 and the module - both RX & TX - to see exactly what's happening?

Some tips on debugging serial comms here;

https://community.st.com/t5/community-guidelines/how-to-write-your-question-to-maximize-your-chances-to-find-a/tac-p/706966/highlight/true#M49

PS:

---

@Taksh wrote:

• Power supply is stable, and the modem boots properly.

---

How have you proved this?

Booting is the easy part - it's when the module actually tries to join the network that the power supply really gets tested...

It is definitely possible for a module to boot on an inadequate power supply, and then fail when it tries to register.

Been there, done that!

Is it the same power supply as used in your "standalone" tests?

If not, then try using that power supply when controlled from the STM32...