STMH7 UART interrupt does not trigger on serial Rx from a STM32F103CB (OpenCM9.04)

[JayTombot]

I am testing Rx handler logic on a STM32H7 based board. Pins PD0/PD1 are set as Rx/Tx (huart4) with Global Interrupt set. 

The uart is setup to interrupt on Idle...

HAL_UARTEx_ReceiveToIdle_DMA(_uart, _JoyRxData, BROADCAST_CMD_SIZE);

and the interrupt is reset inside callback 

HAL_UARTEx_RxEventCallback(UART_HandleTypeDef * huart, uint16_t Size)

 

I tested the serial connection and handler logic with the STM32H7 board connected to a PC (via USB-TTL converter), and separately with it connected to a OpenCM9.04 development board.

 

When the STM32H7's Rx/Tx pins are connected to an OpenCM9.04 development board's Tx/Rx pins, the callback fails to trigger, even though uart->RxState changes...

- When uart is initialized, and HAL_UARTEx_ReceiveToIdle_DMA is set, uart->RxState changes from HAL_UART_STATE_READY to HAL_UART_STATE_BUSY_RX. (the UART is now waiting for data Rx)

- When a connected OpenCM transmits data to STM32H7, uart->RxState changes from HAL_UART_STATE_BUSY_RX to HAL_UART_STATE_READY. But HAL_UARTEx_RxEventCallback is not called! (Don't know what causes its state to change!). So, the interrupt is never reset by calling HAL_UARTEx_ReceiveToIdle_DMA. And any subsequent transmission of data packet from OpenCM is ignored!

 

On the other hand, when the STM32H7's Rx/Tx pins are connected to a PC via TTL-USB converter, any text typed on a connected Terminal on the PC are reliably received and handled repeatedly. 

 

- With the STM32H7 board connected to a PC, and the PC sends data, then also the uart->RxState changes from HAL_UART_STATE_BUSY_RX to HAL_UART_STATE_READY. However, this time the callback is triggered. This causes the received data to be handled and the interrupt is reset to receive to Idle, for another packet of data (by calling HAL_UARTEx_ReceiveToIdle_DMA).

Questions are....

1) Why does the callback not get called when receiving data from the OpenCM board?

2) When connected to the OpenCM board, the uart->RxState on STM32H7 does change state as expected - how, if the callback is not getting triggered?

3) Could there be a voltage level incompatibility between the OpenCM board (which runs an STM32G103CM) and the STM32H7 on my board? 

[mƎALLEm]

Hello @JayTombot and welcome to the community.

Need to tell which STM32H7 exact part number, which board you are using? Custom board? ST board?

[JayTombot]

Hi @mƎALLEm thanks for writing back!

The processor is STM32H747AI used on a custom board, intended to go into a product. 

The source of serial data is a tool (a joystick) that is designed around an OpenCM9.04 board which incorporates the STM32F103CB MCU.

On the H7 based board, the PD0/PD1 pins are exposed on a header, and configured to be a UART port. 

On the OpenCM, 2 of the I/O pins are configured to operate as a UART, and exposed on a header. 

The port headers are connected using a custom harness which connects 3 pins - OpenCM Tx/Rx <-> Rx/Tx STM32H7, and GND-GND. However, during tests, I tried swapping the Rx/Tx pins, just in case I had them labeled incorrectly.

[JayTombot]

One more thing to mention. The communication is set to take place at baud rate 1MB, which is higher than anything I've used before. I'm going to try testing at lower baud rates. Will write back if that makes a difference!

[JayTombot]

SOLVED!

On our custom board with the STM32H7 processor, I was using DMA to receive messages over serial COM. That involved using the combination of HAL_UARTEx_ReceiveToIdle_DMA and HAL_UARTEx_RxEventCallback. Also, I had the baud rate set to 1000000. This combination was causing all kinds of communication problems as I described earlier.

So, I switched to using interrupt based communication, utilizing the combination of HAL_UART_Receive_IT and HAL_UART_RxCpltCallback. Even with that I was still having issues communicating at 1M Baud rate. I had to drop it down to 57600 Baud. With this setup, everything works well.

Still don't know why the COMs didn't work at 1M baud and using DMA?!