• State
  • Locked Locked
  • Replies 2 replies
  • Subscribers 98 subscribers
  • Views 505 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.

Urgent 5912 Issue: Heavy activity on ARM flash bus interferes with DSP DMA

Dennis Ochs
Prodigy 20 points
Other Parts Discussed in Thread: OMAP5912

I am having a problem with the OMAP5912 in which heavy access on the ARM flash bus causes occasional DSP DMA timeout errors.  The DSP DMA process is moving data from the McBSP1 to DSP DARAM.  The ARM process is computing a CRC on a large chunk of data which resides on a Flash chip on the Flash Bus.  I have found that I can make the problem worse by increasing the amount of CRC work the ARM is doing. 

I fundamentally don't understand how these two thing are related.  I think of the DSP DMA process being entirely contained in the DSP core.  I don't think  heavy traffic on the flash bus should affect the DSP DMA since I think the DSP DMA isn't going through the Traffic Controller.   I wish I could understand how the ARM is affecting the DSP in this way.

I am operating the OMAP5912 in synchronous scalable mode with the DSP at 192 MHz and the ARM and TC at 96 MHz.    The TC is operating with the round robin priority algorithm selected and default priority weighting of 0 for the ARM, DSP, DMA and OCP-I.  I think this means that each of thes 4 items gets one access and then passes control onto the next item what wants an access.  As an experiment, I tried increasing the priority of the DSP and the DMA but saw no noticeable effect and the problem still persists.   I also tried running the ARM at 192 MHz and this did not change anything.

I am wondering if anybody has has seen this kind of interaction between the ARM and the DSP.

I am planning to try changing settings on the MPUI interface next. 

Thanks,

Dennis Ochs

Philips Medical Systems

  • 0
    TI__Intellectual 1990 points

    Have you looked into Advisory "TC_1" of sprz209k?

    http://focus.ti.com/lit/er/sprz209k/sprz209k.pdf

    Because you mentioned operating OMAP5912 in "synchronous scalable mode" Advisory "TC_1" might apply. This would mean that at boot time TC = DSP clk = 192 MHz which is > that 96 MHz max.

    This happens becuase at boot time "the DPLL is still enabled and OMAP5912 is switched back automatically to fully synchronous mode".

    Workaround:

    Before performing a Global Software Reset, it is recommended that the DPLL be bypassed so
    that after the clock module has reset to fully synchronous mode, the TC frequency is equal to
    the OMAP5912 base frequency.

    This is all I could personally find on this topic.

    I hope this helps

  • 0 in reply to Thierry3197
    Prodigy 20 points

    I appreciate you taking time to think about my problem, but I think this really is not the cause of the problem.  Advisory TC_1 talks about a problem which could occur if a SW_RESET or a ARM_RST is commanded through the ARM_RSTCT1 register after the DPLL is taken out of bypass.  We never do this in our system and the problem seems to occur at random times well after booting.

    The advisory DSP_DMA_2 seems to be more on target with the way I understand the problem.  This advisory says that the DSP DMA may get into a bad state if the EMIF times out on an access.   The workaround is to reset the DMA and start over when this happens.  So far I have been  trying really hard to not do the workaround because this causes a major disturbance of our real time system.   Instead, I have been focused on trying to make sure that the EMIF does not ever time out.  When the DMA does time out,  we consider this a catastrophic failure and shut the system down.  It seems to me that avoiding the timeout altogether should be another acceptable solution, and I haven't found any errata that makes me think this is also not possible.  I have tried to do this through various configurations of the TC Priority registers, but have not been successful at avoiding the timeouts completely.  I have found that I can greatly increase the rate of occurence by making the ARM pound on the Flash bus while running a CRC calcluation on the contents of the external flash chip. 

    I am wondering if anybody has been successful at completely avoiding EMIF timeouts as described in DSP_DMA_2 so as to not require the workaround described in DSP_DMA_2?   Does anybody know a reason why it should not be possible to completely prevent EMIF timeouts under normal operation?  I am ok with a design in which abnormal conditions could cause a timeout which leads to our system shutting down.  But I want to have the expectation that this will never happen.  Right now I can generally see this happen several times in a 24 hour period when I run ~13 units.  This is not abnormal enough. 

    The fact that DSP_DMA_2 was written makes me think that somebody else has been through the same problem that I am having. 

    Dennis Ochs