• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 83 subscribers
  • Views 1020 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.

CCS/TMS320F28377D: F28377D CPU2 DMA overrun

Green Deng
Expert 4490 points
Part Number: TMS320F28377D

Tool/software: Code Composer Studio

hi TI Experts,

I created a project in Code composite studio, by using F28377D CPU2 to DMA data from emif1. I encountered an issue that DMA reported overrun when trigger event frequency is 667khz or ever more. There's no overrun flag set when I set trigger event at 500khz.

If it run the same configuration in CPU1, there's no overrun flag reported. What's issue?

I tried with external GPIO interrupt and EPWM1 SOCA in CPU2 as trigger source, both over run if frequency at 667khz or 1M.

I am using DMA ch1. Even I set ch1 highest priority, nothing changed.

Below are code for CPU2 DMA configuration. The DMA clock was enable at main.

 // Initialize DMA
 DMAInitialize();

 EALLOW;
 DmaRegs.PRIORITYCTRL1.bit.CH1PRIORITY = 1;// configure channel 1 high priority
 EDIS;

 DMACH1AddrConfig((volatile Uint16 *) &DMAbuffer[0], (volatile Uint16 *) EXTERNAL_ADC_ADDRESS);
 DMACH1BurstConfig(0, 0, 0); //Will set up to use 32-bit data size, pointers are based on 16-bit words
 DMACH1TransferConfig(0, 0, 2);
 DMACH1WrapConfig(0xFFFF, 0, 0xFFFF, 0);

 DMACH1ModeConfig(DMA_EPWM1A, PERINT_ENABLE, ONESHOT_DISABLE, CONT_ENABLE,
   SYNC_DISABLE, SYNC_SRC, OVEFLOW_ENABLE, THIRTYTWO_BIT, CHINT_BEGIN,
   CHINT_ENABLE);

Can you help analysis?

Thanks in advance.

  • 0
    TI__Guru 55700 points
    Do you see this problem on every single device (or) isolated to one device?

    -Manoj
  • 0 in reply to Manoj Santha Mohan
    TI__Guru 55700 points
    Other questions:-

    1) Wondering whether there were any differences in EMIF configurations between CPU1 / CPU2
    2) Are you using the same memory (buffer) in both CPU1 / CPU2 case?
    3) Is the configuration of DMA the same?
    4) Can you try disabling other triggers of DMA but for EMIF on both CPUs?
    5) Develop a debug code to do the transfer using CPU instead of DMA? If you still see the problem, then it must be due to DMA

    Regards,
    Manoj
  • 0 in reply to Manoj Santha Mohan
    Prodigy 40 points

    hi Manoj,

    After check all the configurations, the root cause was the Emif config. When I move Grab EMIF1 for master code from CPU1 to CPU2 project. The overflow issue was resolved. When I set to 2.5M, no overrun observed. 

    I am still curious why the DMA busrt related with Emif configuration?

    Thanks.

    Regards,

    Jerome Jiang  

  • 0 in reply to Jerome Jiang
    TI__Guru** 115271 points

    Hi Jerome,

    I did not understand following comment -

    I am still curious why the DMA busrt related with Emif configuration?

    Can you provide more detail on the link between DMA burst with EMIF configuration?

    Regards,

    Vivek Singh

  • 0 in reply to Vivek Singh
    Prodigy 40 points

    hi Vivek,

    In my not-working configuration, the Emif1 was grabbed by CPU1. Per data manual description below and we only do read from external ADC module via Emif1, all the Emif1 signals and pins are configured for CPU2. In this configuration, CPU2.DMA request/event cannot be serviced by Emif controller. When I changed to CPU2 grab master, it works.

    spruhm8e_page2415. The master arbitration block always allows RD access from any of the masters. But for WR access (or
    execute access), the master arbitration block only allows access of masters from a CPU subsystem which
    grabs master ownership of the EMIF module based on the configuration in the EMIF1MSEL register in the
    Memory Controller module.

    I don't have more question now.

    Maybe the data manual can be updated to encourage CPU2 to grab master when Emif request from CPU2.  

    Thanks tips again for my trouble shooting.

    Regards,

    Jerome Jiang

  • 0 in reply to Jerome Jiang
    TI__Guru** 115271 points
    Hi,

    Since you are only doing READ access, EMIF1MSEL setting should not impact the functionality unless there is write access as well to EMIF. I understand that after switching the EMIF1MSEL resolved the issue but it may be good to check if there is write access as well in your setup which was causing this issue.

    Regards,
    Vivek Singh