• State TI Thinks Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 98 subscribers
  • Views 632 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.

DSP MMU Error Fault!

hdp
Intellectual 330 points
Other Parts Discussed in Thread: OMAP3530

Hi all,

I am running the dsplink readwrite example and I am getting the error message below. I have read the platformguide_omap3530 as well as this wiki http://wiki.davincidsp.com/index.php?title=DSP_MMU_Faults#If_you_know_the_memory_range_to_map_to_the_DSP_MMU_at_build_time_of_DSP_server

but I am still having difficulty figuring out what is going on.

I am running Linux on the ARM and not using LPM nor CMEM. Should I enable hardware TWL to resolve this?

Another odd thing is the .out file used to work fine but now it is giving me this error.

 

============= Sample Application : READWRITE ==========
Entered RDWR_Create ()
Leaving RDWR_Create ()DSP MMU Error Fault!  MMU_IRQSTATUS = [0x1]. Virtual DSP addr reference that generated the interrupt = [0xff204100].

  • 0
    TI__Guru*** 125430 points

    It means that you've tried to access an address that is not mapped into the DSP's MMU.  When the ARM loads the DSP it also sets up the DSP's MMU as part of that process.  By default it maps the memory areas corresponding to the memory sections DDR2, DDRALGHEAP, DSPLINKMEM, CMEM, and RESET_VECTOR.  If you're trying to access an address that is not contained by one of those sections you'll get an MMU fault.

    You cannot turn on the TWL as dsplink has not configured the MMU to be able to support that.

    Brad

  • 0 in reply to Brad Griffis
    Intellectual 330 points

    Thanks for the reply, I have couple more question regarding this.

    1) Does the ARM set up the DSP's MMU via the PROC_control function with the PROC_CTRL_CMD_MMU_ADD_ENTRY enumerated type?

    2) You wrote that the TWL cannot be turned on since DSPLINK has not configured the MMU. How do you configure DSPLINK to turn on TWL?

    3) How can I trace down the line(s) of code that is trying to access an address that is not mapped into the DSP's MMU? I am at a lost as to what I could have written to cause the MMU Error Fault.

     

  • 0 in reply to hdp
    TI__Guru*** 125430 points

    hdp said:

    Thanks for the reply, I have couple more question regarding this.

    1) Does the ARM set up the DSP's MMU via the PROC_control function with the PROC_CTRL_CMD_MMU_ADD_ENTRY enumerated type?

    That API was added recently to allow users to be able to make additions at run-time rather than just build-time.  The code corresponding to PROC_CTRL_CMD_MMU_ADD_ENTRY was derived from code that was originally elsewhere in DSPLink.  I don't know if they refactored the original code to make calls into this new code or not.

    hdp said:

    2) You wrote that the TWL cannot be turned on since DSPLINK has not configured the MMU. How do you configure DSPLINK to turn on TWL?

    TWL support requires a significant engineering effort to implement.  It is on the roadmap for the next major version of DSP Link, which has been renamed to SysLink 2.0.

    hdp said:

    3) How can I trace down the line(s) of code that is trying to access an address that is not mapped into the DSP's MMU? I am at a lost as to what I could have written to cause the MMU Error Fault.

    Breakpoints?  Selectively comment out code?

    I see from the printout in your original post that you're using the readwrite example.  I recommend staying away from that example because direct access into the DSP's memory map is ripe for problems, as you are now painfully aware!  I recommend staying with the MSGQ example (message) for best results.