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.

AM623: UDMA usage in MCU+ SDK

Part Number: AM623
Other Parts Discussed in Thread: SYSCONFIG

Tool/software:

Hi,

My customer is planning to use UDMA in MPU+ SDK on AM6232.
Here are environments.
SDK version : mcu_plus_sdk_am62x_11_00_00_16
Sysconfig : 1.23.1+4034

Q1) When UDMA is enabled in sysconfig, it seems TIMER7 is automatically enabled as "Other dependencies".
Is this mandatory for UDMA? TIMER7 cannot be used for other purpose?

Q2) Dpl_init() is called inside System_init() which is generated by sysconfig.
The customer wants to avoid to call Dpl_init(). Is this possible?
HW initialization is done at different part.

Thanks and regards,
Koichiro Tashiro
  

  • Hello Koichiro Tashiro,

    I am looking at your queries and you may expect reply in one or two days .

    Regards,

    Anil.

  • Hi Anil,

    Do you have any updates for this item?

    Thanks and regards,
    Koichiro Tashiro

  • Hello Koichiro Tashiro,

    Q1) When UDMA is enabled in sysconfig, it seems TIMER7 is automatically enabled as "Other dependencies".
    Is this mandatory for UDMA? TIMER7 cannot be used for other purpose?

    In MCU+SDK 11.0, there is no direct link or dependency between Timer 7 and UDMA.
    I have reviewed the current SDK and confirm that:
    • UDMA is not tied to any specific timer
    • Timer 1 appears in the default SysConfig-generated configuration, but it is primarily used by the FreeRTOS scheduler
    • This timer is not used or required for UDMA operations

    Please refer to the attached image .

    About Dpl_init() :

    By default, Dpl_init() is invoked inside System_init(), which is auto-generated by SysConfig.
    • Dpl_init() is critical because it enables global interrupt handling .
    • Skipping Dpl_init() is not recommended.

    Suggested Workaround:

    If the customer wants to control the initialization sequence manually, they can follow this approach:
    1. Comment out the System_init() call in the main application.
    2. Manually invoke each required initialization in a custom function:
    • Call Dpl_init() only iwhen needed
    • Initialize peripherals (like UDMA, GPIO, etc.) separately


    Why customer wants to change the dpl_init call position ?

    Regards,

    Anil.

  • Hi Anil,

    Thanks for your reply.

    Why customer wants to change the dpl_init call position ?

    There are some conflicts between Dpl_init() and a custom initialization function.
    So calling Dpl_init() causes an exception. So they want to skip Dpl_init().
    H/W initialization is done by a custom function.

    Thanks and regards,
    Koichiro Tashiro

  • Hello Koichiro Tashiro,

    Why is customer doing a custom function to init the dpl_init?

    Already the dpl_init is generated from syscfg and has the hwip_interrupts enabled and other clock init which need to be done before the application init.

    I am not sure why the customer wants to do dpl_init if sys_cfg is already supported ?

    If the customer wants to change the dpl_init calling position where they want to call it dpl_init, like after the system_init or before the system_init.

    Please share all the details.

    Regards,

    Anil.