• State Resolved
  • Locked Locked
  • Replies 1 reply
  • Subscribers 100 subscribers
  • Views 603 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

DSP MMU Error Fault! MMU_IRQSTATUS = [0x1]. Virtual DSP addr reference that generated the interrupt = [0xff114060].

vishnu prasad
Prodigy 55 points
Other Parts Discussed in Thread: OMAP3530

Hi,

I am using OMAP 3530. Using DSPLink I am able to load and unload DSP. 

I have 2 sample DSP .out files. (DSP1.out and DSP2.out). If i load and unload any one of the out files (either DSP1.out or DSP2.out) continuously each will work fine but when I load DSP1.out then unload and then try to load DSP2.out its causing trouble. Sometimes its showing "DSP MMU Error Fault! MMU_IRQSTATUS = [0x1]. Virtual DSP addr reference that generated the interrupt = [0xff114060]."  Error

Both out files try to communicate to ARM through shared memory which currently selected as DSP internal L1DSRAM location. Each out files are of different file size.

Sometimes the linux kernel hangs and the serial console becomes unresponsive. Why is this happening? Please help to fix this problem

Linux kernel version used is - linux-2.6.32-psp03.00.01.06

DSPLink version used is - dsplink_linux_1_65_02_09

 

regards

Vishnu Prasad

  • 0
    TI__Expert 6860 points

    This seems to be pointing to a cache related issue that has been seen in the past when loading and running different slave core applications that run DSPLink.


    DSPLink's Proc module allows the user to load/start/stop the DSP core but doesn't completely power down (and reset) the DSP.  Because of this there is usually stale data in the cache when re-loading the slave core.  This isn't much of a problem if the same slave core app is reloaded.  When loading a different salve application, the stale cache data can cause unexpected results which is what I suspect is happening here.

    Solution is to completely power down the DSP domain on the device.  If you are using TI DVSDK 4.x for the OMAP3530, you can use the Local Power Management (LPM) package included in the kit which contains a kernel utility module to help with powering on/off the DSP core on the OMAP3530.

    LPM is also part of the Multimedia Framework Products (MFP aka Codec Engine).

    You can find both TI's DVDSK 4.x and/or MFP at:

    http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/index.html