STM32H753ZI UART TX DMA

[A3]

Hi,

I am using STM32H753ZI nucleo board, developing with Keil IDE. I am using UART RX and TX DMA. I want to check if there is a possibility of corruption of UART data while transmitting with DMA Tx.

The sending device will send 8-byte defined command to STM32H753ZI and then STM after performing the required operation will send response in a 8-byte defined format.

My system works very well, but sometimes the UART data which is transmitted back to sending device in response to some specific command is seen to be corrupt or any random data other than defined protocol or packet message data

Also, it is seen that the data is sent to sending device without any command which the code never does (that data are mostly 0 0 0 0 0 0 0 0 all 0's of 8 byte).

I am doubting something has gone bad on USB to UART TTL module or USB hub or something in hardware. But just wanted to be sure if there is nothing missed from firmware side for DMA Tx with respect to corruption since DMA uses memory to store data.

Anything to be taken care with respect to memory assignment (stack and heap) in startup file for this? 

[TDK]

The issue is likely related to the convoluted calling scheme you have set up, as you discovered looking at the previous issue. Only you have the code.

[A3]

Hi,

But I think that won't block TX DMA forever and which can be recovered only after controller restart.

Here, problem is Rx is working, but sending is blocked. Means sending device sending the command and STM performing action based on the received command, but no response received it is completely blocked (Tx DMA is completely blocked).

Thats why I was doubting the below errata sheet issue

I didn't clearly understand this errata sheet issue, could you please help me out.

[Karl Yamashita]

You're repeating the same thing about transmit being blocked, but until you show the transmit code and how you're building your 8 bytes, you're not going to get any worthwhile help.

[A3]

You still haven't shown how you're parsing the aRxBuffer data and the code sending particular data back. Are you using any of the aRxBuffer when sending data back?

Parsing is done inside HAL_UARTEx_RxEventCallback(). Refer below code

//UartPuts("TCsize: %d\r\n",Size);
memcpy(&event,&aRxBuffer,sizeof(event_t));
//send message to communication task

Event message contains the command which is sent further to comm task. Comm task forwards to control task for action.

No, I am not using aRxBuffer when sending data back. There is a separate buffer for that.

You have 2  handleMsg in your code.

Eack task communicates using message queue. There is a handleMsg function for each task, runs inside every task body will be executed if a message is received to that task.

Do you have other tasks that periodically transmit data besides you responding to the receive packets?

There are no tasks which periodically transmits data. Task will send response only in response to the receive packets after performing required action based on received command.

But there are chances that two TX DMA or response (need to check )from STM may occur and it wont check if first is completed? Will that stuck TX DMA infinitely?

[Karl Yamashita]

But there are chances that two TX DMA or response (need to check )from STM may occur and it wont check if first is completed? Will that stuck TX DMA infinitely?

---

I finally found that you posted this code further away from the other functions that pass the pointers so i didn't see this. 

Two things you need to work on. 

1. You need to check the HAL return status when you call HAL_UART_Transmit_DMA. 
2. You need a way to resend your packet if send a packet while the DMA is still sending data because it'll return HAL_BUSY. 

void sendUart1Data(uint8_t * buff, uint8_t length)
{
    uart1_Info.uart_state = E_uart_State_Busy;
    HAL_UART_Transmit_DMA(&UartHandle, (uint8_t *)buff, length);
    HAL_Delay(1u);
    uart1_Info.uart_state = E_uart_State_Ready;
}

 Look at my signature. Maybe that will help give you some ideas on the 2 things i'm talking about.