• State
  • Locked Locked
  • Replies 6 replies
  • Subscribers 31 subscribers
  • Views 301 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Original question:

MCU-PLUS-SDK-AM243X: uart_echo_dma_lld problem

MCU-PLUS-SDK-AM243X: uart_echo_dma_lld problem: SysConfig problem when using two UARTs

Alexander Baehr
Intellectual 616 points
Part Number: MCU-PLUS-SDK-AM243X
Other Parts Discussed in Thread: SYSCONFIG

Tool/software:

Hi experts.

I am using motor_control_sdk_am243x_09_02_00_09, CCS 12.6, SysConfig 1.21.1.

I am working with the uart_echo_dma_lld_am243x-evm_r5fss0-0_nortos_ti-arm-clang example, I simply tried to add another UART in DMA mode. The result is a compiler error in the auto-generated sysconfig code:

1602.example.syscfg.zip
Building file: "syscfg/ti_drivers_open_close.c"

[...]

syscfg/ti_drivers_open_close.c:136:19: error: redefinition of 'gUartDmaChCfg'
UART_UdmaChConfig gUartDmaChCfg[CONFIG_UART_NUM_DMA_LLD_INSTANCES] =
^
syscfg/ti_drivers_open_close.c:100:19: note: previous definition is here
UART_UdmaChConfig gUartDmaChCfg[CONFIG_UART_NUM_DMA_LLD_INSTANCES] =
^
1 error generated.
gmake: *** [syscfg/ti_drivers_open_close.o] Error 1

 

The problem is gone when I remove the second UART and insert again, this time in polling mode.

There seems to be a problem with code generation. Is there a workaround?

BR

Alexander

  • 0
    TI__Mastermind 45676 points

    Hi,

    I have been able to reproduce this issue.

    Since the SysConfig driver files are shared across most of the Sitara SoCs, so I was able to reproduce this on AM64x TI EVM as well.

    Note, I imported the UART ECHO DMA LLD application and then went ahead and added one more UART port, set the transfer mode to DMA and then the SDK Infrastructure to LLD.

    Post this I got the same build error.

    Allow me sometime to investigate if this is expected or else I will raise an internal bug for this to be fixed.

    Regards,

    Vaibhav

  • 0 in reply to Vaibhav Kumar
    TI__Mastermind 46696 points

    Hello Alexander,

    I feel that to transfer the DMA 12 bytes data is not much DMA benefit to your requirement.

    My suggestion is that pleas try to measure the how much Time is taking by the DMA to complete it's operation.

    Start the timer before the DMA starts (Udma_ringQueueRaw) and stop after the DMA interrupt the call back in the release build.

    This time can give some insights and really meets the measurement time is acceptable to your requirements or not .

    Later we can work on the DMA split functionality.

    Regards,

    Anil.

  • 0
    TI__Mastermind 45676 points

    Hi,

    I debugged inside SysConfig generated files further, and its pretty clear that when we add two instances of a specific peripheral, then the expected rendered file should be as follows. The following is an example of I2C two instances.

    But for UART we see that its not the same case as per the uart dma lld addition. The following snippet is generated twice in the ti_drivers_open_close.c file.

    Rather it should be more like this:

    I have raised an internal bug to fix this issue.

    Regards,

    Vaibhav

  • 0 in reply to Swargam Anil
    Intellectual 616 points

    Hi Anil,

    I managed to split the DMA initialization, as you suggested.

    The time from calling Udma_ringQueueRaw until the call back is about 2200 cycles = 2.75 us. This is a nice result, but I think it does not make sense: The pure UART transfer time for 12 bytes @ 115200 baud should be about 1 ms (12 * 10 / 115200 = 0.001 s). This suggests that maybe the callback is not really the end of the transfer, as discussed in this thread.

    The time which we spend in code to re-trigger the DMA (from calling Udma_ringQueueRaw until directly after its return) is about 0.5 µs, which would be a fine solution for us.

    What I am still missing, is a way to get rid of the callback function. Could you give a short example how to poll the "DMA ready" instead of using a callback?

    BR
    Alexander

  • 0 in reply to Alexander Baehr
    TI__Mastermind 46696 points

    Hello Alexander,

    It is really good that, based on our suggestion, the DMA UART functionality is split into init and DMA start and makes them work.

    I will work on the DMA in the polling mode, and you may expect a reply by next week.

    Regards,

    Anil.

  • 0 in reply to Swargam Anil
    TI__Mastermind 46696 points

    Hello Alexander,

    I measure at my side in the release build. Please check my results.

    In my test case, I used the GTC timer to measure the results.

    I followed the steps below.

    Start the Timer before DMA starts 

    Stop the Timer after the call back 

    Take the them difference which gives time.

    In my example, I have used the 94-byte transfer and baud rate is 115200.

    If I calculate the theoretical time to complete data transfer with UART DMA is 8.15msec and in my testing also , I got the same result 8.15msec.

    I feel that you measure in the not correct way.

    Can you please confirm how did you measure ? What is the timer did you use ? Are you using a freeRTOS or NORTOS application?

    Result variable value is 8151 usec .

    Regards,

    Anil.