cancel
Showing results for 
Search instead for 
Did you mean: 

Two STM32 communicating over UART

DJ1
Associate III

I have written code for both the transmitter as well as receiver board. The issue is when i see the communication over logic analyzer or even while using TTL to RS232 converter, i can see that the port is continuously occupied and master is transmitting data continuously over Tx and for the same Tx of slave is sending acknowledgement continuously.

In case of ideal situation, the communication should only happen after 1 second not until that. Even if the data is getting transferred continuously, though at every 1 second i can see correct data being transmitted and received by both the boards in their respective debuggers (STM32CubeIDE).

If i remove the connection between both the boards then the master is transmitting only at an interval of 1 second. The issue lies only when both the boards are communicating. Also when both the boards are communicating, i can see OVERRUN, IDLE and RXNE Flag SET in my Status Register. If i remove connection then non of these flags are SET.

Connection: Master          Slave

                     Tx   -----------   Rx

                     Rx  ------------  Tx

Please do share some insights on this!!

7 REPLIES 7

We can't really comment about a program we don't see. But the amount of error may also indicate something unexpected is going on. Check power and reset (e.g. blink a LED upon reset). Are the two boards powered from the same power source? How is ground arranged?

JW

Receive.c is the master sending the Frame of 50 bytes and Receive_test.c is the slave controller board Code.

I know I wrote that can't comment code I don't see, but did not expect a whole application, which I'm not going to review.

Try to isolate the problem. As I've said above, check, if hw is OK, first. Then observe in code how acknowledgements are processed - do they cause the repeated transmissions? What happens if in code you disable processing of received bytes (i.e. acknowledgements)?

JW

KDJEM.1
ST Employee

Hello @DJ1 ,

I advise you to take a look at this wiki: Getting started with UART

This article explains what is UART and how to use it through examples using two NUCLEO-L476RG boards

  • Simple UART communication in polling mode
  • UART with Interrupt
  • UART with DMA

I hope this help you!

Kaouthar

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

Ozone
Lead II

> I know I wrote that can't comment code I don't see, but did not expect a whole application, which I'm not going to review.

I would second that.
I just had a look, and didn't really like what I saw.
Waiting for flags (supposedly transmission finished) inside interrupt handlers is IMHO not a good idea.
The OVL flag is a sign you are spending too long in other code, presumably the same interrupt handler.

It kind of irks me when I see 70-80% of source code inside of an interrupt and you're also transmitting inside of an interrupt. That's all bad practice. Because you're in an interrupt parsing and transmitting, you're going to miss receiving bytes.

Instead save the data, set a flag and exit the interrupt. Then you can poll the flag, then do your parsing and transmitting.

Tips and Tricks with TimerCallback https://www.youtube.com/@eebykarl
If you find my solution useful, please click the Accept as Solution so others see the solution.

> Because you're in an interrupt parsing and transmitting, you're going to miss receiving bytes.

More precisely, transmitting inside the interrupt assures that one loses at least one character.
The busy-wait loop waiting for the transmit to finish will take as long as a character reception takes.

> Instead save the data, set a flag and exit the interrupt. Then you can poll the flag, then do your parsing and transmitting.

I would second that.
And dealing with receive buffer overflows, missed characters and corrupted packages is a necessity for a robust software. The protocol should re-synchronize after drop-outs.