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...

[bramble]

Hi @Taksh ,

I would check your SIM card, and if you put it in a standard mobile phone you should be able to confirm that you can see the network in a PLMN search, register and activate a PDP context. You haven't said anything about the network type that you're connecting to but of course you need to be sure that your SIMCOM modem has the necessary capabilities. e.g. If connecting to a 5G SA cell then you need a 5G SA (not NSA) modem

Good luck!

[Andrew Neil]

---

@bramble wrote:

I would check your SIM card, and if you put it in a standard mobile phone ...

---

Would that work with an NB-IoT SIM ?

But @Taksh has already said that is does register when the module is used "standalone" - so that confirms that the SIM is OK?

@Taksh again, please give more details of how, exactly, you did the "standalone" testing.

Maybe show some photos of your setup?

[bramble]

You're right, @Andrew Neil  ! Apologies, I read the post too quickly and overlooked the fact that this is NB-IOT, I was assuming it was a regular cellular modem.

Then it really does seem to be somehow related to the serial interface for AT commands, which is rather odd. Time to step back to staring hard at the AT commands and responses on a working vs non-working system. AT responses should make it fairly easy to eliminate fundamental comms issues (e.g. baud rate out of spec, which I would doubt). Some AT commands have timeouts but otherwise they're not fussy about exact timings.

I assume that @Taksh has checked voltage-level compatibility, but if not that would be worth confirming as OK.

Communicating directly with SIMCom may be a challenge, but the distributor of the module should be able to provide support.

[Taksh · Accepted solution]

Hello @Andrew Neil  and @bramble ,

Thank you for your valuable suggestions and support.

We are happy to share that the issue has been resolved. The modem is now able to connect to the NB-IoT network successfully, complete network registration, and the signal strength is being detected properly using the AT+CSQ command.

Root Cause:

Our hardware design supports both nano SIM and eSIM. During testing, we were using a nano SIM, which is fully provisioned and active. However, we discovered that the modem was unintentionally using configuration details (such as ICCID and IMSI) from the eSIM slot, which is not yet provisioned.

We observed that:

• The command AT+CICCID always returned the nano SIM ICCID as expected.

• But internally, during network registration, the modem mistakenly prioritized the eSIM configuration (which led to registration failure).

After confirming the hardware routing and ensuring the nano SIM slot was being correctly used, the issue was resolved and the network registration completed successfully.

Next Steps:

We have not yet tested with the eSIM. As our current focus was on validating nano SIM functionality, eSIM testing is still pending.

If anyone has reference documentation, AT command sequences, or configuration examples for using eSIM with the SIM7022 module, it would be greatly appreciated.

Thanks again to the community for your support!

[Andrew Neil]

Thanks for feeding-back with the resolution.

Now please mark that post as the solution - see this for instructions.

---

@Taksh wrote:

If anyone has reference documentation, AT command sequences, or configuration examples for using eSIM with the SIM7022 module, it would be greatly appreciated.

---

The SIMCOM documentation is here: https://www.simcom.com/product/SIM7022.html

You need to contact SIMCOM and/or your SIMCOM distributor for further support - it's nothing to  do with ST.

https://www.simcom.com/contact.html

https://www.simcom.com/service_cat-20.html