cancel
Showing results for 
Search instead for 
Did you mean: 

Unwanted received byte at startup with UART+DMA

Davood_Kesha
Associate III

Hello ST experts,
I have a weird experience with UART communication between two STM32G4 microcontrollers. MCU1 sends 10 bytes to MCU2 via UART. Both UARTS are configured with 9600 Baud rate with DMA in circular mode. The Problem arises when the MCU1 is turned on, it sends 11 bytes which the first byte is 0x00 in case I need only 10 bytes to be received. Can you help me in this issue?
Best,
Davood.

3 REPLIES 3
TDK
Super User

Put an external pullup resistor on the RX line so the line is idle high when the pin is not initialized.

If you feel a post has answered your question, please click "Accept as Solution".
Karl Yamashita
Principal

Are you sure MCU1 sends11 bytes? Or does MCU2 receive a byte (0x00) on POR, then you get 10 bytes from MCU1 making you think MCU1 sent 11 bytes?

I've seen the NUCLEO-G431KC interrupt upon POR even though no data is sent to it. I use a queue so my pointer indicates it received ~10 bytes which were all 0x00. So the first message would not parse because of the nulls, but all other messages received afterwards synced just fine. Using a pull-up on RX didn't help. 

 

I'm currently working on a project using a NUCLEO-G491RE and it does the same thing but my pointer says around ~20 bytes and shows 0x00. Using a pull-up on RX also doesn't help. I've never see this issue with other NUCLEO boards that are not G4 series.

 

My fix was to call HAL_UARTEx_ReceiveToIdle_DMA, then initialize everything else. Then before entering the main while loop, i reset all my queue/DMA pointers.

If i tried to reset my pointers right after calling HAL_UARTEx_ReceiveToIdle_DMA, my pointer was still indicating bytes received. By resetting the pointers after all other routines were done, I believe it gave time for the DMA to finish interrupting so the pointers would actually get reset. 

 

If a reply has proven helpful, click on Accept as Solution so that it'll show at top of the post.
CAN Jammer an open source CAN bus hacking tool
CANableV3 Open Source

Andrew Neil
Super User

@Davood_Kesha wrote:

 when the MCU1 is turned on, it sends 11 bytes which the first byte is 0x00 .


That's (almost certainly) not the MCU actually sending an byte.

That'll be just a power-on glitch, which the receiver interprets as a byte.

It is common to find that turning on any equipment while connected to something that's already listening will cause an initial "glitch".

Do you get any errors (eg, framing) in this case ?

As @TDK said, a pullup should help.

It might also be wise to make your receiver more resilient against errors - rather than just rely on exactly 10 perfectly-formed bytes ...

 

PS:

If, as suggested, it is just a power-on glitch then this has nothing to do with DMA.

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.