cancel
Showing results for 
Search instead for 
Did you mean: 

how to configure usart1 to use the dma.

vbuon.1
Associate III

hi,

we are using usart1 to communicate w/ a device using custom baud rates. we have it working but sometimes we don't get all of the data that is sent by the device. it one or two bytes are dropped at the beginning of the message or there are several bytes dropped at the end of the message. we use usart3 to communicate w/ a device that is similar to the one connected to usart1. however, there are no dropped bytes. also, usart3 is configured to use the dma.

we would like to configure usart1 to use the dma. we configured it in the kernel device tree as follows:

&usart1{
	pinctrl-names = "default", "sleep";
	pinctrl-0 = <&usart1_pins_z_mx>;
	pinctrl-1 = <&usart1_sleep_pins_z_mx>;
	status = "okay";
 
	/* USER CODE BEGIN usart1 */
	power-domains = <&pd_core>;
	dmas = <&dmamux1 71 0x400 0x15>,
		   <&dmamux1 72 0x400 0x11>;
	dma-names = "rx", "tx";
	/* USER CODE END usart1 */
}

this caused usart1 to no longer function correctly. that is, we are no longer receiving data from the device connected to usart1.

how do we correctly configure usart1 to use the dma?

thanks,

vince

3 REPLIES 3
Kevin HUBER
ST Employee

Hello @vbuon.1​ ,

I can see two problems in your DTS configuration:

MDMA and not DMA

USART1 is not linked to the DMA, but it is connected to MDMA

You can see that by using CubeMX, for USART1 only a tab MDMA Settings is available:0693W00000Nr676QAB.png 

When for the other USART like USART2, you can see a DMA Settings tab:

0693W00000Nr67VQAR.png 

This information is also wrote in the refman (RM0436.pdf) table 98 page 1158: https://wiki.st.com/stm32mpu/wiki/STM32MP15_resources_-_v3.1.0

Where the USART1 is only in the MDMA table, but not in the DMAMUX table at the page 1224.

DMA Request MUX Input

Regarding your dmamux configuration, we can see in the same table page 1224, that the MUXs that you try to request are the one for USART6

0693W00000Nr692QAB.png 

As explained above, USART1 is not connected to the dmamux.

If you look at the file "stm32mp151.dtsi" you can see an example with SPI6 of how to configure the MDMA and you have to use the mux 32 and 33

0693W00000Nr6UoQAJ.png 

Hope it helps,

Regards,

Kevin

In order 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.
vbuon.1
Associate III

hi kevin,

thank you for the response.

i did update my device tree file and i was able to communicate w/ our device connected to usart1. however, i'm still having problems w/ usart1.

what i'm seeing is that usart1 does not behave the same way as usart3.

both usart3 and usart1 have been configured identically except for the dma. usart3 uses dma 1 and usart1 uses mdma. the configuration parameters used to open and configure the uart port are the same for both usarts. except for the baud rate: one is 3,599,882.13 and the other is 3,149,938.58 . and yet they behave differently.

there are times that usart1 will not return the data when it is sent back by our device. we have confirmed this using a logic analyzer connected to the uart lines. the read call to read the data will return 0 bytes. and yet, when a subsequent data request is sent to our device the return data from the read call will include the data from the previous read. also, the time btwn the data request and the data response is about 1.3 us.

the devices that are connected to the two uarts are essentially the same. that is, they both use the same uart ip. and yet there is a different behavior btwn the usarts.

thanks,

vince

vbuon.1
Associate III

hi kevin,

we decided to switch to uart4 which is configured similarly to usart3. we configured the console to use usart7 (currently not being used on our custom board) instead of uart4. we rerouted the uart signals to our device to use uart4. we are now able to reliably communicate w/ our device. this seems to indicate that usart1 is an unreliable uart port. maybe you have some suggestions as to why usart1 is unreliable.

thanks,

vince