Does the eDMA peripheral driver major loop transfer [Byte] setting have a bug?

cancel
Showing results for 
Search instead for 
Did you mean: 

Does the eDMA peripheral driver major loop transfer [Byte] setting have a bug?

Jump to solution
201 Views
Senior Contributor I

Hello,

I am using MCUXpresso Config Tools v7 and added an eDMA Peripheral driver in the peripheral tool and tried to set the minor and major loop to the maximum values. The Minor loop transfer [Byte] value can only be set to 2^30-1 and not to 2^32-1. This is correct because the called function EDMA_Init() is always setting the Enable Minor Loop Mapping Bit to 1 so there are only 30 Bits for NBYTE.

Now I understand from comparing with the generated code that the value Major loop transfer[Byte] divided by Minor loop transfer [Byte] equals to the major loop counts (CITER/BITER).

Here is the problem: MCUXpresso only allows a value of 2^16-1 which I think is incorrect. If we look at the TCD memory structure from the RT1020 reference manual

pastedImage_1.png

we can see that the CITER field is at maximum 15 Bits wide if we do not set the checkbox "Channel link initialization" which would equal to a value of 32765. Therefore there has to be some logic behind it (like for the Minor loop transfer [Byte] field which depends on the Minor loop offset initialization) if the E_LINK Bit is 1 or 0.

Furthermore the field Major Loop transfer [Byte] is NOT equal to the major loop count CITER. The calculation mentioned at the beginning of the post will result in the major loop count CITER.

I think the maximum allowed value for the field Major loop transfer[BYTE] should be the maximum allowed value for CITER (depends on the ELINK Bit) multiplied by the maximum allowed value for the field Minor loop transfer [Byte] (depends on the Minor loop offset initialization).

Am I correct or is there some additional setting for DMA which sets the maximum Major loop transfer [Byte] field to 65535?

Kind regards,

Stefan

0 Kudos
1 Solution
12 Views
NXP Employee
NXP Employee

Hi Steffan,

thank you very much for your feedback. I apologize for the inconvenience, the setting you mentioned includes incorrect constraint calculation, which will be fixed in the next update.

The correct constraint calculation is part of the Non-transactional (TCD structures) mode (Major loop counts setting), which writes direct value to the CITER field. In other two modes, the resulting CITER value is calculated as you stated: Major loop transfer [Byte] / Minor loop transfer [Byte].

If you find any inconsistency do not hesitate to contact us.

Best Regards

View solution in original post

5 Replies
12 Views
NXP Employee
NXP Employee

Hi,

in the attachment there is package with a patch of the eDMA peripheral component (v2.3.0), which solves your issue before the next Config tools version update. You can find there the installation process.

If you have any further questions, feel free to contact us.

Best regards

0 Kudos
12 Views
Senior Contributor I

Hello,

I closed MCUXpresso Config Tools v7, copied the included folder mcu_data_v7 to c:\ProgramData\NXP\ and answered the Replace dialog with "Replace the files in the destination" after that I restarted the program.

Unfortunately the field Major loop transfer [Byte] still does not allow inputs >65535

pastedImage_7.png

and stops the code generation.

I don't know how MCUXpresso Config Tools work but the date modified of edma.component is 11th of December 2019. Is it the wrong file in the attachment?

pastedImage_8.png

Kind regards,

Stefan

0 Kudos
12 Views
NXP Employee
NXP Employee

Hi Stefan,

I apologize for the inconvenience. I mistakenly attached the original (wrong) component version. Now the previous attachment is updated with the correct eDMA component version. Thank you for you feedback.

Best Regards

0 Kudos
12 Views
Senior Contributor I

Now it is working, thank you.

Kind regards,

Stefan

0 Kudos
13 Views
NXP Employee
NXP Employee

Hi Steffan,

thank you very much for your feedback. I apologize for the inconvenience, the setting you mentioned includes incorrect constraint calculation, which will be fixed in the next update.

The correct constraint calculation is part of the Non-transactional (TCD structures) mode (Major loop counts setting), which writes direct value to the CITER field. In other two modes, the resulting CITER value is calculated as you stated: Major loop transfer [Byte] / Minor loop transfer [Byte].

If you find any inconsistency do not hesitate to contact us.

Best Regards

View solution in original post