• State
  • Locked Locked
  • Replies 6 replies
  • Subscribers 98 subscribers
  • Views 525 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 PCE1

coroger
Prodigy 40 points
Other Parts Discussed in Thread: OMAP3530

Hello,

I'm not a DSP programmer, but am integrating some DSP code into a Linux application using dsplink.  The DSP code works much of the time, but every now and then takes a memory fault.  The dsplink kernel module tells me the fault address and type. I've looked at the docs and dsplink code, and can see the reported values taken from the mmu registers, but I don't see a pointer in the hal structure for the DSP control registers where the PC is located (I think I want PCE1---please tell me if I'm wrong...).

Is there a simple (or even a bit complex) way to get the PC of the fault, or a document I should be looking at to see how all this hooks together, or am I just wasting my time and need to think about this problem differently?

Thanks,

Clyde

  • 0
    TI__Expert 4930 points

    Clyde,

    From the post I am not very clear which platform you are on. From the contents, I am guessing OMAP3530. My answer is based on the assumption that it is OMAP3530.

    Are you getting a MMU fault with the message like DSP MMU Error Fault! MMU_IRQSTATUS = [0x10]. Virtual DSP addr reference that generated the interrupt = [0x82f00000].

    The link http://wiki.davincidsp.com/index.php/DSP_MMU_Faults describes the common reasons for faults to occur. This will help you get the reason why you are seeing the fault. If you are looking for info on how to configure OMAP MMU, you can look at http://wiki.davincidsp.com/index.php/DSP_MMU_Faults

    Deepali

  • 0 in reply to Deepali Uppal
    Prodigy 40 points

    Deepali,

    Thanks for the response, and yes, it is a 3530 (sorry about leaving that out).

    I have read the wiki page, but during extended test I can't have a debugger connected.  I'm hoping that in these situations I could get at the DSP PC at the time of fault so I could pass that data off to our DSP developer.

    Clyde

  • 0 in reply to coroger
    TI__Expert 4930 points

    Clyde,

    The error message prints the error code as well as the address that causes the fault. Do you require more information than that to fix the problem?

    As the wiki has mentioned fixing the fault issues require some application code changes. I am not clear how the debugger/DSP PC will help you?

    Deepali

  • 0 in reply to Deepali Uppal
    Prodigy 40 points

    Hello Deepali,

    What I occasionally see is that the DSP faults on an address that it shouldn't access at all, so that address isn't providing useful information---all I know is that somewhere in the DSP, some instruction at times accesses a wild memory location.  The PC could be mapped back to the code so the DSP guy could see how that address is being calculated or fetched.  Even if that didn't show him exactly how to fix the problem, it would give him a start on instrumenting the code to detect the problem.

    If there is some other way DSP developers generally debug this sort of problem, I'd be happy to hear about it...

    Thanks,

    Clyde

  • 0 in reply to coroger
    TI__Expert 4930 points

    Clyde,

    The most common causes for memory faults are incorrect memory configuration. But it looks like your memory map is correctly setup and you are facing general instability issues.

    There can be two causes for this:

    1) Have you taken care of setting proper bootargs to reserve some memory for DSPLink shared memory & DSP using the mem=<> parameter. Not doing this also causes random crashes since the DSP ends up trampling over Linux memory space.

    2) Are  you using 'just' DSPLink or DSPLink within Codec Engine environment.

    If you are using just DSPLink, you need to use LPM module to power-cycle the DSP between runs of DSPLink applications. When Linux boots up, the DSP is in the correct state, so you don't need to run LPM the first time. But after you run one sample application, you need to power off & then on the DSP using LPM off & on before you run the next sample application. This is because when DSP cache is enabled, we have seen that it does not get cleared out completely on simply doing a reset/release. Complete power off & on of the DSP is required before running the next application, otherwise it results in random MMU faults.

    For details on LPM usage, refer to the DSPLink Install Guide for OMAP3530 (InstallGuide_Linux_OMAP3530.pdf). The document contains detailed information on why LPM is needed and how it needs to be used (refer to sections 9.3 & 10. I see that there is a bug in the document where it shows running lpmON followed by lpmOFF before running the sample application. This should actually be lpmOFF followed by lpmON.

    If you are using DSPLink within Codec Engine environment, CE takes care of this for you by calling LPM API's directly in their code.

    Deepali

  • 0 in reply to Deepali Uppal
    Prodigy 40 points

    Thanks for the LPM information, Deepali.  We are using just DSPLink, and are not doing the power cycle.  I'll get that in, and see if the problem goes away.

    Clyde