Problem with USART communication between 2 processors

[GS1]

I have two STM32H743 processors which are connected by USART ports. We have to transmit data between these 2 µPs and have no other ports left (SPI or so) which could be used instead.

I initialized the 2 USARTs using STM32CubeMX with the identical settings (Bitrate 800kHz only, Clock-Polarity High, Clock 2.Edge, etc.)

 husart2.Instance = USART2;

 husart2.Init.BaudRate = 800000;// 25000000;

 husart2.Init.WordLength = USART_WORDLENGTH_8B;

 husart2.Init.StopBits = USART_STOPBITS_1;

 husart2.Init.Parity = USART_PARITY_NONE;

 husart2.Init.Mode = USART_MODE_TX_RX;

 husart2.Init.CLKPolarity = USART_POLARITY_HIGH;

 husart2.Init.CLKPhase = USART_PHASE_1EDGE;

 husart2.Init.CLKLastBit = USART_LASTBIT_ENABLE;

 husart2.Init.Prescaler = USART_PRESCALER_DIV1;

 husart2.Init.SlaveMode = USART_SLAVEMODE_DISABLE;

 husart2.Init.FIFOMode = USART_FIFOMODE_ENABLE;

 husart2.Init.TXFIFOThreshold = USART_TXFIFO_THRESHOLD_1_8;

 husart2.Init.RXFIFOThreshold = USART_RXFIFO_THRESHOLD_1_8;

 if (HAL_USART_Init(&husart2) != HAL_OK)

 {

   Error_Handler();

 }

When transmitting only one byte (not via DMA, just with HAL_USART_Transmit_IT), and echoing it back, it seems that the data gets shifted by one bit in the end.

I send 0x55, the receiver gets 0x55, this is sent back but then the original sender gets 0xAA received.

What could be the reason? I played around with 1./2 Edge but this doesn't help.

Transmitted data on the Osci looks ok. Pin speed for the ports are set to "High".

Thank you for any hints.

[Jack Peacock_2]

​You didn't mention what physical transmission line is used.  RS-232, RS-485, point to point TTL levels?

Does the UART status show any errors?  I'd expect to see framing or overruns.

From your description your receiver is triggering at the wrong time for the start bit, causing sequential bits after start to shift by 1.  This is a common problem with async serial at higher baud rates when the baud rate clocks don't match exactly.  Try lowering the baud rate to determine at what point it starts to fail.  You might also try extending the stop bit idle time to two bits to give yourself a little more timing margin for the next start bit incoming. 

Are both baud rate generators derived from a crystal oscillator, and are the frequencies the same?  Using the internal RC that 1% jitter is enough to cause it to fail.

if you happen to be using RS-232, well, that won't work.  The slew rate on RS-232 limits reliable transmission to 115Kbaud.  It might work for a while at higher speed, but not reliably, especially at high rates.  If it's TTL try some small damping resistors in series (10-22 ohm) with the two data lines to reduce ringing.  If it's RS-485 make sure you have 120 ohm terminators at each end of the differential cable (and make sure it is twisted pair, straight wires are useless with differential signaling).

  Jack Peacock

[GS1]

Hello Jack, thank you for your reply!

In fact the two processors are on 2 boards, which are connected by a Pin connector. They are in one system which will sample data and display them on an LCD.

Both boards are designed by our hardware department. The signals are 3.3V.

I will try your proposals a.s.a.p. and let you know the results.

[GS1]

Update:

I did try several different configurations and up to now there is no successful transmission achieved.

• baudrates 115 200 .... 12 500 000 show same effect. So reducing baudrate is no means
• 1 Stop / 2 Stop Bits: doesn't change the result
• Adapted Usart input Clocks (which were partly configured too high) to the maximum of 100 MHz
• Last Bit Enable / Disable: no improvement, makes it even worse
• Low Clock / 1Edge instead of High Clock: not solving problem
• Disabling FIFO Mode: same fault

The USARTs do not report any errors. But the received data is wrong. On the Oscilloscope everything looks perfect (Sampling time of data at 2nd Edge of Clock is correct. Transmission frame in both directions look identical - but one gets wrong data).

One more information: The boards are connected with 2 USART ports:

Each processor has one USART as Master the other USART is configured as Slave. So both processors are able to start a communication as a Master.

Both have USART 2 as Master ports. One has USART 3 as Slave, the other one has USART 6 as Slave.

Currently it seems the USART 3 Slave is the one failing.

Is there anybody out there who did use synchronized communication between 2 STM32H7 processors yet?

[GS1]

New update: USART Synchronous communication is working now.

Reason was: The bootloader application, which is called first after power-on, initialized the USARTs with a different configuration and did not call "HAL_USART_DeInit", before jumping to the application. The subsequent initialisation call from the application level could not configure the USART according to the needs.

Lesson learned: ALWAYS call "DeInit" routine for an initialized peripheral before reconfiguring the thing. There might be some bits, which will not be reconfigured by calling HAL_... Init.