UART2 GPRS Communication Issue – Continuous Interrupts & Random Data

[pankajprasad100]

Hello,

I'm currently working on an STM32 project using FreeRTOS, and I'm facing an issue with UART2 communication when interfacing with a GPRS module.

Project Setup:

• UART3 is used for debugging (connected to a PC terminal) and is functioning correctly.

• UART2 is used for communication with a GPRS module.

• Both UART2 and the GPRS module operate at 3.3V logic levels.

• The firmware uses STM32Cube HAL drivers and FreeRTOS.

What I’ve Verified:

• The GPRS module was tested by connecting it directly to a PC using a USB-to-Serial converter, and it responds correctly to AT commands.

• I also performed a loopback test on UART2 (connecting TX to RX), and it worked as expected — transmitted data was received correctly.

Issue Faced:

However, when I connect the GPRS module to UART2 (TX to RX, RX to TX, GND to GND), I observe that:

• The UART2 interrupt triggers continuously, even when nothing is being sent.

• The receive buffer fills with random or garbage data.

• As a result, I’m unable to communicate with the GPRS module properly.

Questions:

1. What could be the cause of continuous UART interrupts with invalid data?

2. Are there any specific UART configurations or precautions when using external modules under RTOS?

3. Could this be related to electrical noise, grounding, or missing hardware flow control (RTS/CTS)?

Additional Details:

• STM32 MCU:STM32H755ZIT6U

• Baud rate: 115200

• UART2 is initialized through STM32CubeMX

Please let me know if you need any further details or if there’s a recommended way to debug this kind of issue.

Please look into my project and screenshots and I am using CM7 core.

Looking forward to your support.

[Andrew Neil]

Welcome to the forum.

Please see How to write your question to maximize your chances to find a solution for best results.

In particular, please give details of your hardware setup - used board(s), the GPRS module, etc - your tool versions, etc

 

---

@pankajprasad100 wrote:

• The GPRS module was tested by connecting it directly to a PC using a USB-to-Serial converter, and it responds correctly to AT commands..

---

Excellent - always a good start.

So have you done the same with your STM32?

ie, can the STM32 reliably communicate with a PC terminal?

How have you verified that the UART baud rate is actually correct?

 

---

@pankajprasad100 wrote:

I connect the GPRS module to UART2 (TX to RX, RX to TX, GND to GND)

Are you sure that's correct?

Some modules require TX-to-TX, and RX-to-RX (DCE connection)

 

---

@pankajprasad100 wrote:

I observe that:

• The UART2 interrupt triggers continuously, even when nothing is being sent.

• The receive buffer fills with random or garbage data.

---

Have you looked at the signals on an oscilloscope?

Have you used a USB-to-UART converter (or two) to "sniff" what's actually happening on the lines?

See:

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:~:text=some%20tips%20specifically%20on%20Debugging%20Serial%20Comms

 

PS:

 

---

@pankajprasad100 wrote:

• I also performed a loopback test on UART2 (connecting TX to RX), and it worked as expected — transmitted data was received correctly..

---

Note that this test will pass even if the baud rate is not what you think it should be.

 

Have you got reliable comms working between STM32 & GPRS unit without the RTOS ?

[Karl Yamashita]

---

Issue Faced:

However, when I connect the GPRS module to UART2 (TX to RX, RX to TX, GND to GND), I observe that:

• The UART2 interrupt triggers continuously, even when nothing is being sent.

• The receive buffer fills with random or garbage data.

• As a result, I’m unable to communicate with the GPRS module properly.

---

What GPS module is this so we can look at the datasheet? 

Did you check with an oscilloscope to see what the Rx pin on the STM32 is doing? Is the signal level high and not appear to be floating? Maybe the GPS module isn't using a push-pull type on the Tx pin and so requires the Rx on the STM32 to be pulled up? 

 

[Tesla DeLorean]

GPRS (Cellular) not GPS/GNSS

Yes, would agree the pull-up on the RX

Watch for other sticky error/status, say noise, framing, etc.

[Karl Yamashita]

I was just literally viewing GNRMC messages moments before hand, prior to viewing this post, so GPS was stuck on my mind, lol.

[Karl Yamashita]

Module Verification

The GPRS module (EC-25) was first tested by connecting it directly to a PC via the USB-to-Serial converter. It responds correctly to AT commands. So, the module itself is working.

STM32 UART Testing

Yes, I have tested communication between the STM32 and a PC terminal via UART, and it's working as expected.

The UART baud rate is set to 115200, and this was verified during testing.

---

Well that level shifter may be your weak link. You've done your test as mentioned above, but you've never talk about the level shifter being in the circuit during the test.

A block diagram showing how it's connected for both the above scenarios would help, including supply power. A part# would help.

You didn't respond about in my initial post about checking with a oscilloscope on how the signals look at the STM32 Rx line..

[pankajprasad100]

CASE 1:
 Sending data from STM32 → EC-25, and the EC-25 responds. These signals are successfully captured using a USB-to-Serial converter.

 

This is the signal captured from A2 where RX is connected to usb-serial converter.

 

CASE 2:
When I connect the RX pin of the STM32 to the setup, even the USB-to-Serial converter stops working.

 

 

 

This is the signal captured from A2 where RX of STM and USB-Serial converter are connected. 

 

 

[Andrew Neil]

---

@pankajprasad100 wrote:

CASE 2:

When I connect the RX pin of the STM32 to the setup, even the USB-to-Serial converter stops working.

---

That's bound not to work!

You can't have two TX outputs shorted together like that - they will "fight" each other.

If you want to monitor both lines between the STM32 & EC25, you will need two USB-to-UART converters - as linked previously:

https://www.avrfreaks.net/s/topic/a5C3l000000UYWbEAO/t146507?comment=P-1422786