• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Subscribers 99 subscribers
  • Views 508 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.

AM6442: UDMA Memcpy polling example failure

James Cassidy
Prodigy 50 points
Part Number: AM6442
Other Parts Discussed in Thread: SYSCONFIG

Importing, compiling and running the AM64x UDMA memcpy polling example fails to run (actually, all SDK dma examples fail in exactly the same place).  The example loops forever in the DebugP_assertNoLog() function with the following stack trace:

_DebugP_assertNoLog( 0 )

_clockSetFrequency()

PowerClock_init()

System_init()

main()

The actual failure is occurring in the Module_clockSetFrequency() function when calling SOC_moduleSetClockFrequency() with moduleID = 146, clkId = 0, clkRate = 96000000.  Stepping into the SOC_moduleSetClockFrequency() function reveals that the source of the problem is when that function tries to disable the clock before changing the frequency by calling  Sciclient_pmModuleClikRequest(), which returns -1.  The parameters passed to Sciclient_pmModuleClikRequest() are moduleID = 146, clkId = 0, TISCI_MSG_VALUE_SW_STATE_UNREQ, 0U, and SystemP_WAIT_FOREVER.

This is being run under the following:

Board      TMDS64GPEVM  (Configuration SW:  S2 = 11000010,  SW3 = 01000000)

CCS        12.0.0.00009

SDK        mcu_plos_sdk_am64x_08_03_00_18

Enclosed is the zipped project showing the problem.  Any assistance would be greatly appreciated. 

8054.DMATest.zip

  • 0
    TI__Genius 12330 points

    Dear James,

    Thanks for your query .

    please allow me few days to look at your issue, Next Monday is a holiday in India so will be able to look at it after then. please expect some delay.

    regards

    Anshu

  • 0 in reply to Anshu Choudhary
    Prodigy 50 points

    Thanks Anshu.  Have a great holiday. 

    Regards,

    Jim.

  • 0 in reply to James Cassidy
    TI__Mastermind 48686 points

    Hello James,

    I am working on your issue and please expect a response with in 1 day or two.

    Regards,

    S.Anil.

  • 0 in reply to Swargam Anil
    TI__Mastermind 48686 points

    Hello James,

    I verified the example "udma_memcpy_polling_am64x-sk_r5fss0-0_nortos_ti-arm-clang" on my HW and
    the example software is running perfectly and there is no DebugP_assertNoLog assertion issue.

    I have verified example on below configurations .

    Board      TMDS64GPEVM  (Configuration SW:  S2 = 1100 1110,  SW3 = 0100 0000)

    CCS        12.0.0.00009

    SDK        mcu_plos_sdk_am64x_08_03_00_18

    I have a doubt why you put sw2 position in 11000010 ?

    Can you try putting the HW in OSPI or other modes and please do the same test ?

    Please use below link to put the HW in different Boot modes.

    https://software-dl.ti.com/mcu-plus-sdk/esd/AM64X/08_02_00_31/exports/docs/api_guide_am64x/EVM_SETUP_PAGE.html#autotoc_md24

    Please let me know if you are facing problem .

    Regards,

    S.Anil.

  • 0 in reply to Swargam Anil
    Prodigy 50 points

    Thank you for looking into our issue Swargam!

    I have configured SW2 and SW3 to your recommended settings: SW2 = 1100 1110, SW3 = 0100 0000 and rerun the DMA test.  However, I observe a different outcome:

    1) Linux does not boot.

    2) CCS fails to load the application into the R5.

    I am uncertain why the board does not run the examples when I use your recommended settings.  There are several jumper blocks on the board, all of which have no jumper installed.  Could that be the difference?

    Also...

    In response to your question regarding why my original switch settings were chosen:  That was the recommended settings from both the TDMS64GPEVM quick start as well as the TDMS64GPEVM Users manual:

    Kind Regards,

    Jim.

  • 0 in reply to James Cassidy
    TI__Mastermind 48686 points

    Hello James,

    I understand you are using Linux + SD card boot mode and trying to reproduce the issue at my end .

    Please allow me some time, I will get back to you .

    Regards,
    S. Anil

  • +1 in reply to Swargam Anil
    TI__Mastermind 48686 points

    Hello James,

    I was able to recreate your issue.

    The A53 core is already using USART0 for debug logging and if we try to initialize the  same USRAT from the R5F core it will create an issue which you were observing.

    Please try to use USART other than USART0 in R5F core , in order to do that please use sysconfig and make changes in the system configuration as shown below


    I followed the following steps:

    1. I have placed the positions of sw2 and sw3 in the configuration below

    SW: S2 = 11000010, SW3 = 01000000

    2. The WIC image is loaded on the SD card

    3. SD card inserted in EVM

    4. Power on

    5. Open the example system config file and please change "UART Example" from USART0 to USART1

    6. Compile software

    7. Load binaries on R5F core.

    Finally I didn't face any problem and example software is running perfectly and there is no DebugP_assertNoLog assertion issue.

    Please let me know if this helps

    Regards,
    S. Anil

  • 0 in reply to Swargam Anil
    Prodigy 50 points

    Thank you for your persistence Swargam.  I returned the switch settings to their original position and removed the conflict as you suggested.  The example is working now.  The difference was running Linux caused the conflict as you discovered.  I will keep an eye out in the future as such conflicts don't show up on sysconfig.

    Thanks again!

    Jim.

  • +1 in reply to James Cassidy
    TI__Mastermind 48686 points

    Thanks James ,

    If there are more questions, please raise new Threads.

    Regards,

    S.Anil