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.
Philips Medical Systems
Have you looked into Advisory "TC_1" of sprz209k?
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 sothat after the clock module has reset to fully synchronous mode, the TC frequency is equal tothe OMAP5912 base frequency.
This is all I could personally find on this topic.
I hope this helps
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.
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with respect to these materials. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.