cancel
Showing results for 
Search instead for 
Did you mean: 

UART2 GPRS Communication Issue – Continuous Interrupts & Random Data

pankajprasad100
Associate II

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.

1 ACCEPTED SOLUTION

Accepted Solutions

Level Shifter: Used between STM32 and EC-25

In your first post, you mention Both UART2 and the GPRS module operate at 3.3V logic levels

So why a level shifter? Part#?

I was told that if a devices starts to smoke, put the smoke back in. I guess I never got all the smoke because the device never worked afterwards.
Don't worry, I won't byte.
TimerCallback tutorial! | UART and DMA Idle tutorial!

If you find my solution useful, please click the Accept as Solution so others see the solution.

View solution in original post

18 REPLIES 18
Andrew Neil
Super User

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 ?

A complex system that works is invariably found to have evolved from a simple system that worked.
A complex system designed from scratch never works and cannot be patched up to make it work.
Karl Yamashita
Principal

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? 

 

I was told that if a devices starts to smoke, put the smoke back in. I guess I never got all the smoke because the device never worked afterwards.
Don't worry, I won't byte.
TimerCallback tutorial! | UART and DMA Idle tutorial!

If you find my solution useful, please click the Accept as Solution so others see the solution.

GPRS (Cellular) not GPS/GNSS

Yes, would agree the pull-up on the RX

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

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

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

I was told that if a devices starts to smoke, put the smoke back in. I guess I never got all the smoke because the device never worked afterwards.
Don't worry, I won't byte.
TimerCallback tutorial! | UART and DMA Idle tutorial!

If you find my solution useful, please click the Accept as Solution so others see the solution.

Also - is GPRS still a thing ?

Many places have already closed 2G networks, and others are planning it - so it seems a bit late to be starting on a new GPRS project!

Definitely NRND.

 

https://wirelesslogic.com/iot-sim/global-network-closures

https://www.emnify.com/blog/global-2g-3g-phase-out

#2GSunset #3GSunset

A complex system that works is invariably found to have evolved from a simple system that worked.
A complex system designed from scratch never works and cannot be patched up to make it work.

Hardware Setup and Issue Summary

I'm working with the following hardware configuration:

  • MCU: STM32H755ZIT6U

  • LTE Module: Quectel EC-25

  • Level Shifter: Used between STM32 and EC-25

  • USB-to-TTL Converter: Waveshare 4-channel serial converter

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.

GPRS Connection to STM32

I am connecting the EC-25 GPRS module to UART2 on the STM32 as follows:

  • TX (STM32) → RX (GPRS)

  • RX (STM32) ← TX (GPRS)

  • GND ↔ GND

I also tested TX-to-TX and RX-to-RX (in case the module behaves like DCE), but communication still did not work.

Issue Observed

  • If I disconnect the RX pin of STM32 (i.e., only connect STM32 TX → GPRS RX, and observe the GPRS TX line using a USB-to-TTL converter), I can see the GPRS module responding to the AT command sent by STM32.

  • But as soon as I connect STM32 RX to GPRS TX, communication breaks — the GPRS response is no longer received, and garbage starts to appear in the receive buffer.

Additional Notes

  • The issue is the same with or without FreeRTOS.

  • I've confirmed the wiring and pin configuration multiple times.


Request

Can anyone advise on what might be causing this issue — specifically, why connecting the RX pin of the STM32 causes garbage reception or communication failure, even though TX alone works and the GPRS module is sending a response?

Thank you!

You're absolutely right — GPRS is largely obsolete and being phased out in many regions.

Apologies for the confusion earlier — I'm actually using the Quectel EC25, which is an LTE module, not GPRS.
So this is indeed an LTE-based project, and we're not relying on 2G or GPRS at all.

Thanks for pointing that out!

I already verified with a pull-up on the RX line, but unfortunately the issue still persists.
I'll also take another look at possible UART error flags like noise, framing, or overrun errors to see if anything is getting silently triggered.

Thanks for the suggestion!


Level Shifter: Used between STM32 and EC-25

In your first post, you mention Both UART2 and the GPRS module operate at 3.3V logic levels

So why a level shifter? Part#?

I was told that if a devices starts to smoke, put the smoke back in. I guess I never got all the smoke because the device never worked afterwards.
Don't worry, I won't byte.
TimerCallback tutorial! | UART and DMA Idle tutorial!

If you find my solution useful, please click the Accept as Solution so others see the solution.