• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 98 subscribers
  • Views 494 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.

DM368/DM365 Asynchronous timeout using HPI with heavy EDMA load

Craig Smith
Intellectual 810 points

Hello,
I am using a dm365 as an HPI slave and a dm368 as an HPI host. I am seeing EMIF async. timeout's (on the host) when doing HPI reads and the slave is also doing a lot EDMA transfers. I have not seen any details on how the HPI DMA logic interacts with EDMA with respect to contention for DRAM access, so I'm not sure how they share access.

For example, when this condition occurs I see the EM_WAIT (HDRY on the slave) stay low (meaning the host should wait) for as long as 85 us. Of course this exceeds the EMIF timeout (MEWC) and I see the async. timeout interrupt, the host completes the cycle and as a result the data read over HPI is wrong. BTW, the HPI host read is an auto-increment data read and I see the timeout occur in the middle of the read.

1. Is there a document describing the how the HPI DMA logic and EDMA contend for DRAM access?

2. What would cause the HRDY/EM_WAIT signal to stay low for so long (80+ us) during an auto-increment read?

3. Are the any specs. or limitations on simultaneous use of HPI DMA and EDMA (on the slave)?

4. Is there a way to prioritize between the DMA modules?

Regards,
-Craig

  • 0
    TI__Expert 5955 points

    Hello,

    1. Unfortunately, we don't have such document. The HPI DMA bus has higher priority than the EDMA if both of transfers are issued at the same time. I think in this case the EDMA is already started and taking a lot of time to do the transfer hence the HPI DMA has to wait.

    2. It could be that it waits for the EDMA transfer to complete.

    3. Unfortunately we don't have such specs. Both HPI DMA and EDMA accesses are in round-robin and HPI DMA has higher priority if both are issued at the same time.

    4. No. the HPI DMA has higher priority than the EDMA.

    Regards,

    Tai 

     

  • 0 in reply to Tai Nguyen
    Intellectual 810 points

    Thanks Tai, that is helpful information.

    I have another question regarding the EMIF asynchronous timeout with respect to NAND flash. I see this timeout occur on just about every flash access (on our board and even on the dm365 EVM w/ standard Micron flash). Looking at the signals on a scope, it seems that this usually occurs during the "block erase busy time", which can be up to 2 ms (according to out flash datasheet).We are actually seeing only ~240 us.

    The max EMIF timeout (0xff EMIF clock cycles, from AWCCR.MEWC) is not nearly long enough to cover these cases.I do not necessarily see errors every time we get this timeout (like the HPI read), but occasionally we see files either disappear or end up with zero-length so I'm wondering if the EMIF timeout could be the cause of this.

    1. Is there another was to extend the timeout for accessing NAND (other than AWCCR.MEWC)?

    2. If the EMIF is going to frequently timeout and complete its cycle without RDY being high, then how do we guarantee data integrity?

    Regards,

    -Craig

  • 0 in reply to Craig Smith
    TI__Expert 5955 points

    Hi Craig,

    You should not use the EW when you use the AEMIF with the NAND Flash. Please see section 2.5.6 of the AEMIF UG (sprufi1c) to configure the AEMIF for NAND flash.

    Thanks and regards,

    Tai

     

  • 0 in reply to Tai Nguyen
    Intellectual 810 points

    OK, I see this now. So, now I'm wondering why the TI UBL configures A1CR to use Extended Wait?

    I just checked the latest UBL code and it is the same value I've been using.

    From http://arago-project.org/files/releases/davinci-psp_3.x.0.0-r37/sources/flash-utils-davinci.tar.gz flash_utils/DM36x/Common/src/device.c

    Uint32 DEVICE_EMIFInit()
    {

    ...

      AEMIF->A1CR = 0x40400204;

    ...

     

    Bit 30 is the EW bit. 

    Regards,

    -Craig

  • 0 in reply to Craig Smith
    TI__Expert 5955 points

    Hi Craig,

    I have reported the UBL/NAND issue to the UBL team. Sorry about the issue.

    Thanks and regards,

    Tai