Why does STM32U5 use a linked list to receive but normal DMA init to transmit?

[jnz86]

stm32-usart-uart-dma-rx-tx/projects/usart_rx_idle_line_irq_ringbuff_tx_loopback_U5/Src/main.c

Line 337 in 8336144

NodeConfig.DestAllocatedPort = LL_DMA_DEST_ALLOCATED_PORT1;

I see the tx is set with DMA_InitStruct.xxxwhich I am familiar with. And then the rx portion uses NodeConfig.xxx which I am not.

I see that CubeMX does this as well. Although neither the default MX nor your code uses their Linked List generator. Rather it looks like the way to use this DMA to rx is to define a linked list of one unit?

Any idea how you would describe this to someone? It looks foreign to me.

It looks like you use the normal set/get size/data commands once it's running so not using the linked list values anymore?

[MaJerle]

In the STM32 with GPDMA (U5, H5), there is a linkedlist feature, essentially allows you to reload DMA configuration from the memory. That means that you setup different configs in your memory, and then you start the DMA that will perform the transfer according to the config, once transfer is done, it will load new config and start the transfer according to the new config, and so on.

In case of circular DMA, linked list points to itself, see below.

stm32-usart-uart-dma-rx-tx/projects/usart_rx_idle_line_irq_ringbuff_tx_loopback_U5/Src/main.c

Line 365 in 8336144

LL_DMA_ConnectLinkNode(&Node_GPDMA1_Channel0, LL_DMA_CLLR_OFFSET5, &Node_GPDMA1_Channel0, LL_DMA_CLLR_OFFSET5);

From app note:

A linked list is a programmed data structure in the memory to prepare each GPDMA channel for chaining and scheduling DMA data transfers.

[jnz86]

Ah, so points to itself it... I think I was missing that concept!

So in this case the line is that link-to-self at DMA memory... Which is why if you update the size or src/dest buffers it should keep working, because the node data you initially with a temporary variable was placed at DMA ram, and IS being updated.

LL_DMA_ConnectLinkNode(&Node_GPDMA1_Channel0, LL_DMA_CLLR_OFFSET5, &Node_GPDMA1_Channel0, LL_DMA_CLLR_OFFSET5);

As where to really use the linked list feature, you would connect it not to the existing DMA object you just set, but rather to a linked list node format somewhere else in memory ideally something more statically declared. Do I have this right?

Second thing though, why does the Rx use this but the Tx doesn't? Is it only because in order to use Rx and circular that it uses the node method? Then at least Tx "could" have also used the node implementation, no? The difference threw me. It seems like it would have been possible to set RX normally, then just set the next_node pointer back to DMA memory without the Mx node functions.

[MaJerle]

As where to really use the linked list feature, you would connect it not to the existing DMA object you just set, but rather to a linked list node format somewhere else in memory ideally something more statically declared. Do I have this right?

Second thing though, why does the Rx use this but the Tx doesn't? Is it only because in order to use Rx and circular that it uses the node method? Then at least Tx "could" have also used the node implementation, no? The difference threw me. It seems like it would have been possible to set RX normally, then just set the next_node pointer back to DMA memory without the Mx node functions.

In the RX mode, when you are in the circular mode, you always want to return to the beginning of the same buffer aka start over to receive data to the same place as before -> that's the definition of circular.

When you are in TX, you are the boss of the transmission, so you can always manually set the DMA before each transmission and once it is completed, you get an interrupt and you start new transmission manually. That would be the typical approach.

With LinkedList, you may have 5 buffers to transmit, and while one is being transmitted, you prepare new one and you just notify DMA, kinda hey, once you are done with current transmission, please jump here and send this buffer for me, with this new config, and so on.

[jnz86]

Ok, I think I get it.

I think the confusing parts were:

• That the list was linked to itself.

• That your calls to update the destination address use the typical DMA style update commands and didn't mention the list again after it's init.

• That the list data was set via a temporarily defined node to that channel in GPDMA memory, in peripheral RAM, not in what I would say is "user RAM" with a static node.

Thanks T, that was very helpful. Appreciate it.

[MaJerle]

There is a variable in the application RAM, not in the peripheral RAM. See

stm32-usart-uart-dma-rx-tx/projects/usart_rx_idle_line_irq_ringbuff_tx_loopback_U5/Src/main.c

Line 19 in 8336144

static LL_DMA_LinkNodeTypeDef Node_GPDMA1_Channel0;

Here we solely control what is the next node in this linked list object:

stm32-usart-uart-dma-rx-tx/projects/usart_rx_idle_line_irq_ringbuff_tx_loopback_U5/Src/main.c

Line 365 in 8336144

LL_DMA_ConnectLinkNode(&Node_GPDMA1_Channel0, LL_DMA_CLLR_OFFSET5, &Node_GPDMA1_Channel0, LL_DMA_CLLR_OFFSET5);

It points to self

Here we tell the DMA peripheral, where to fetch first config:

stm32-usart-uart-dma-rx-tx/projects/usart_rx_idle_line_irq_ringbuff_tx_loopback_U5/Src/main.c

Line 373 in 8336144

LL_DMA_SetLinkedListBaseAddr(GPDMA1, LL_DMA_CHANNEL_0, (uint32_t)&Node_GPDMA1_Channel0);

Here we tell the DMA, which registers are the one we want to update when DMA fetches new config via linked list:

stm32-usart-uart-dma-rx-tx/projects/usart_rx_idle_line_irq_ringbuff_tx_loopback_U5/Src/main.c

Line 374 in 8336144

LL_DMA_ConfigLinkUpdate(GPDMA1, LL_DMA_CHANNEL_0,

Remember, when you fetch new confi, not all registers have to be updated, maybe you just want to update the data pointer and length of new data.

[jnz86]

I see what is going on here.

In your code, you're keeping Node_GPDMA1_Channel0 static. The default CubeMX does not. They set up once with a local. Which, seems like a bad idea if you didn't know any better and asked it to reload... Which they seem to by linking it.

I've been using their generation out of CubeMX, then I was going to roll your changes / buffers / effect into a file away from MX's usart.c. Meaning I would set the src/dest/size after the initial setup, but MX making a local and linking it, that won't work well.

I know better now. I'll remove all of MX's generated code and pull from yours.