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.

AM2634-Q1: Redefinition Error with Multiple UART DMA LLD Instances - gUartDmaChCfg

Part Number: AM2634-Q1
Other Parts Discussed in Thread: SYSCONFIG

Tool/software:

Hi TI Team,

I'm working with the uart_echo_dma_lld example, which functions correctly. However, when I attempt to add a second UART instance using DMA LLD in the same project, I encounter a redefinition error during compilation.

Error Details:
Description: redefinition of 'gUartDmaChCfg'
Resource: ti_drivers_open_close.c
Path: /UART_Test/Release/syscfg
Location: line 152
Type: C/C++ Problem

Root Cause: The SysConfig tool is generating two separate arrays with the identical name gUartDmaChCfg

UART_EdmaChConfig gUartDmaChCfg[CONFIG_UART_NUM_DMA_LLD_INSTANCES] =
{
    {
        .edmaRxChId = DMA_TRIG_XBAR_EDMA_MODULE_0,
        .edmaTxChId = DMA_TRIG_XBAR_EDMA_MODULE_1,
    },
};

UART_EdmaChConfig gUartDmaChCfg[CONFIG_UART_NUM_DMA_LLD_INSTANCES] =
{
    {
        .edmaRxChId = DMA_TRIG_XBAR_EDMA_MODULE_2,
        .edmaTxChId = DMA_TRIG_XBAR_EDMA_MODULE_3,
    },
};


Questions:
1. Why is SysConfig generating two arrays with the same name instead of a single array with multiple instances?

2. How can I configure SysConfig to either:

  • Generate unique array names for each UART instance, or
  • Combine both configurations into a single array with multiple elements?

Could you please provide guidance on the correct SysConfig configuration for multiple UART DMA LLD instances?

Thank you for your assistance.

  • Hi,

    I was able to reproduce the same issue on my end. The code is auto-generated from the following file: C:\ti\mcu_plus_sdk_am263x_10_02_00_13\source\sysconfig\drivers\.meta\uart\templates\uart_open_close_config_v2_lld.c.xdt

    I'm working on fixing the same, will share an updated file with the fix

    Regards,
    Shaunak

  • Hi Rahul,

    Can you please replace the default file at: C:\ti\mcu_plus_sdk_am263x_10_02_00_13\source\sysconfig\drivers\.meta\uart\templates\uart_open_close_config_v2_lld.c.xdt with the attached file and let me know if it fixes your issue:

    https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/908/uart_5F00_open_5F00_close_5F00_config_5F00_v2_5F00_lld.c.xdt

    The generated code would now look like:

    Regards
    Shaunak

  • Hi Shaunak,

    Thank you for providing the updated template file. I replaced the file with the attached version.

    Status Update: The compilation issue has been resolved, but new problems have emerged:

    Issue 1: Both UARTs Stop Working in LLD+DMA Mode

        a. When both UART instances are configured in LLD mode with DMA enabled
        b. Both UARTs transfer only a few bytes initially, then stop functioning completely
        c. No further data transmission occurs on either UART

    Issue 2: UART Functionality Dependency

        a. UART0 works correctly when UART1 is configured in a HLD mode
        b. When I configure UART1 LLD mode without DMA, I encounter a new compilation error:

    "redefinition of 'gUartDmaChCfg' with a different type: 'UART_EdmaChConfig[1]' (aka 'struct UART_EdmaChConfig_s[1]') vs 'UART_EdmaChConfig[2]' (aka 'struct UART_EdmaChConfig_s[2]')"



    There may be a resource conflict or initialization issue when both UARTs operate in LLD mode simultaneously.

    Thanks,
    Rahul

  • Hi Shaunak,

    1 more update -

    The update receive interrupt functions correctly and its callback is properly invoked. However, during transfer DMA operation, the callback function is never called. The transfer DMA only works once successfully. On the second attempt, the system becomes stuck in "try_lock_mutex" because the previous transfer callback is never triggered, preventing proper completion handling but when I send any data on UART, receive callback triggers (screenshot attached). 


    Thanks,
    Rahul

  • Hi Rahul,

    Looking into it, would need some time on proper validation to fix this bug.

    Regards,
    Shaunak

  • JIRA Bug for internal tracking purposes: https://jira.itg.ti.com/browse/MCUSDK-14704 (link not accessible externally)

  • Hi Rahul,

    Can you please let me know the urgency for the fix of this issue? Due to some ongoing debugs I haven't been able to look into it completely.

    Regards,
    Shaunak

  • Hi Shaunak,

    No problem, please take your time to fix it and feel free to let me know if you need any additional logs. At the moment, this is a lower priority as I’m currently using interrupt-based APIs to handle UART data transmission and reception within the same project. However, I expect to have it resolved by mid-July.

    Thanks,
    Rahul

  • Hi Rahul,

    Thanks for confirming. I'll try to get it resolved before Mid-July and provide a Patch in this thread itself

    Regards,
    Shaunak