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.

[pankajprasad100]

The EC-25 module operates at 1.8V logic levels, so I’m using a level shifter to interface between the STM32 (3.3V UART) and the module’s 1.8V signals.

I initially mentioned 3.3V to clarify the STM32’s logic levels, but to interface correctly with the EC-25—which operates at 1.8V logic levels—the level shifter is essential to ensure proper voltage translation and reliable communication between the two devices.

[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

[Andrew Neil]

Your scope has a USB socket to capture screenshots:

This will give far clearer results that photos of the screen!

[Karl Yamashita]

@Andrew Neil is correct in that you should not have both Tx pins connected. The Tx pins are push-pull outputs. The internal circuitry uses transistors to push high and pull low. So the STM32 is pushing high while you're trying to use the USB<>Serial adapter to push low during data transmission, which is a short circuit. 

You haven't shown how you test the STM32 Rx with the level shifter in place, which you still haven't told us the part number. So, i assume your USB<>Serial adapter doesn't have a 1.8V supply so you're not able to test it in that way. Try this adapter to emulate the EC-25 https://www.amazon.com/dp/B07TXVRQ7V

My money says it is the level shifter that is causing the issue, whatever that part# is. 

[pankajprasad100]

Hi,

I'm currently sending the AT command every one second.

To monitor the response, I'm probing the signal at point A2 on the level shifter (which is the TX output from the GPRS module and input to the STM32 RX pin).

Here's the interesting part:

• If the STM32 RX pin is not connected to A2, I can see the correct response (OK) from the module using a USB-to-Serial converter and viewing it in PuTTY. The signal on the scope also looks clean and properly framed.

• However, as soon as I connect the STM32 RX pin to A2, the response disappears — some random data is in PuTTY, and the signal gets distorted.

Attached is the oscilloscope trace showing the A2 signal when STM32 RX is disconnected.

Attached is the oscilloscope trace showing the A2 signal when STM32 RX is connected.

I’m using the TXS0108EPWR level shifter for voltage translation between the STM32 and the EC-25 LTE module.

Below is a snapshot of the schematic showing the connections.

I have tested the STM32 RX pin without the level shifter — both in a loopback configuration (TX connected to RX) and by using a USB-to-Serial converter. In both cases, the RX pin behaves as expected and communication works correctly.

The issue only occurs when the level shifter is introduced into the setup. As soon as the STM32 RX is connected through the level shifter, communication breaks down — and even the USB-to-Serial converter stops receiving valid data.

 

[Andrew Neil]

---

@pankajprasad100 wrote:

sending the AT command every one second.

---

That's a really bad idea.

Never send AT commands just on arbitrary, blind delays.

You must always wait for the reply before sending the next command, especially with network-related commands - which can take a long & variable time to complete.

From your scope plots, it looks like you have a ground problem.

Please show the full schematic, and some good, clear photos of your setup.

Your block diagram doesn't match your schematic excerpt:

• In the block diagram, you have A1 & A2 on the 3V side;
• In the schematic excerpt, you have B1 & B2 on the 3V side.

PS:

You've marked this as solved - but that doesn't seem to be the case?

How to un-mark a solution:

https://community.st.com/t5/community-guidelines/help-others-to-solve-their-issues/ta-p/575256#:~:text=If%20you%20accidentally%20chose%20the%20wrong%20post%20as%20solution%2C%20you%20can%20always%20revert%20this%20action%20by%20clicking%20%22Not%20the%20Solution%22

[Tesla DeLorean]

Definitely looks like the A/B sense is wrong or there's a grounding issue between the 3.3V and 1.8V supplies.

The lasts scope trace looks like the ground's risen, or the 1.8V signal is modulated onto the 3.3V one.