Descriptor memory allocation on SRAM1 for DMAC in LPC84x etc...

[shoichi_kojima]

Dear fellows,

I'm trying to utilize DMAC at its best performance balance in a system.

Let me pick up LPC845 for examples.

Due the architecture nature of that DMAC, RAM resource must be assigned

as virtual DMAC registers, sometimes called (Head) Descriptor.

Of course it is obvious that assigned SRAM is not the one which is used

by CPU busmaster related accesses such as stack access at interrupt,

write access by MTB etc...

MTB is limited to access only with SRAM0.

So, the RAM which is to be assigned to DMAC had better be SRAM1.

In fsl_dma.c/h implementation, I can not enjoy SRAMs as described above.

An API "DMA_InstallDescriptorMemory()" is provided, which set s

SRAMBASE register of DMA. SRAM1's base address 0x10002000 would

be the reasonable setting, I suppose.

But, any of further DMA driver APIs accepting channel parameter ignore

current SRAMBASE setting made on DMA hardware. 

Why this happens?

Implementation concept of those APIs do not fit SRAM1 assignment ?

[shoichi_kojima]

Dear staff,

Thank you for your reply.

I think I understand the mechanism of DMAC and Descriptor SRAM area for DMAC.

Probably, the default array of DMA descriptor named "s_dma_descriptor_table0" is

intended to be a kind of "static-link"-ed variable.

My understanding and idea is that those area are to be handled as "dynamic-link"-ed ones

like variable vector base of Cortex-M0+.

By some reasons, such as power-management, and memory resource-management

"on-demand" setting might be expected. User may change it to the most reasonable

SRAM resources on-demand. Of course, those SRAM area candidates are strategically

allocated by employing linker's feature, giving them independent region/sections.

From the software point of view, especially for "prepared API set", the only value every

corresponding code can ever depend would be the DMAC.SRAMBASE,

not a particular array-variables such as "s_dma_descriptor_table0".

This is my confusion and the reason why I asked

> Implementation concept of those APIs do not fit SRAM1 assignment ?

Current "fsl_dma" driver API set seems depending on "s_dma_descriptor_table0",

which is just a particularly-named statically-linked variable and is encapsulated among API set.

Why does the implementer team working on "fsl_dma" chose that way that corresponding

DMA API functions never see the CURRENT content of DMAC.SRAMBSE ?

I don't think it cost much even in run-time.

Probably, the team has its own design/implementation concept, which is not as same as

I have, at least...

I would like to know theirs as an alternative.

Thanks

[diego_charles]

HI @shoichi_kojima 

Continuing with the follow up. Here is the feedback that  our team provided me:

When implementing DMA, there are some limitations for memory use. For example, a right alignment condition might need to be followed.

To get rid of confusion of these limitations by the customers, the driver usually provides  pre-allocated memory for several memory items (in this case de DMA descriptor table)  .This  leaves more flexibility to the customers, while they would not see the limitation. Usually, there might be a balance between the performance and flexibility.

Please note that addres of the DMA channel descriptor memory at DMA->SRAM_BASE register should be 512 bytes aligned. * Also, a piece of memory , like the descriptor table , should be always allocated when initializing the DMA module, before using it.

If you want to manage the DMA->SRAM_BASE it is OK, please try to follow the align condition described above.  However, after the initialization of the DMA controller, changing the DMA->SRAM_BASE is not recommended.

We hope this information could help you with your inquiries.

Best regards,

Diego.

Edit *:  Adding sentence with further details: Also, a piece of memory , like the descriptor table , should be always allocated when initializing the DMA module, before using it.

[diego_charles]

Hi @shoichi_kojima  

I just wanted to let you know that I requested feedback from  my colleagues before getting back to you with a reply to your inquiries. We are checking further and I will keep you updated on this process.

My apologies for the delay.

Yours,

Diego.

[diego_charles]

Hi @shoichi_kojima 

Probably , when you called the DMA_InstallDescriptorMemory() function , the address of the DMA descriptors was set in the  SRAMBASE . However the functions that received the DMA channel arguments where using the default address of s_dma_descriptor_table0, which is  placed on SRAM0 at 0x1000_0200

For example:

void DMA_SubmitChannelTransferParameter(
    dma_handle_t *handle, uint32_t xferCfg, void *srcStartAddr, void *dstStartAddr, void *nextDesc)
{
...
  dma_descriptor_t *descriptor = (dma_descriptor_t *)(&s_dma_descriptor_table[instance][handle->channel]);

    DMA_SetupDescriptor(descriptor, xferCfg, srcStartAddr, dstStartAddr, nextDesc);
...
}

Using the lpcxpresso845max dma_m2m_polling example I tried to  set the DMA descriptors into SRAM1

1 I created a new  memory region, according  to the  address of SRAM1 region. And then I specified the dma descriptor table to be placed in that  area.

#include  "cr_section_macros.h"
__DATA(descriptor_RAM ) dma_descriptor_t s_dma_descriptor_table0[(25)]   __attribute__((aligned((512)))); // ;

 2 After the DMA_init was done,  the SRAMBASE received the addres of the s_dma_descriptor_table0

3 FInally ,  I was able to run the example ,having the DMA descriptors placed into the SRAM1 area. 

DMA memory to memory polling example begin.
Destination Buffer:
0	0	0	0	
DMA memory to memory polling example finish.
Destination Buffer:
1	2	3	4	

You will find more details on how to place variables into specific memory areas in the following post.

https://community.nxp.com/t5/Kinetis-Design-Studio-Knowledge/Relocating-Code-and-Data-Using-the-MCUX...

My  apologies for the delayed reply.

Please let me know if this is what you where looking for.

Regards,

Diego.