• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 99 subscribers
  • Views 431 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.

MP Exception raised with reserved bit set in MPFSR

SPH
Intellectual 635 points

Hi,

One of the guys here has just experienced a memory protection fault where one of the reserved bits in the L2 MPFSR is set, despite the manual indicating that they should always read as zero.

The values that I am getting are L2MPFSR: 0x00000090, L2MPFAR: 0x00000000, which has bit 7 set in the MSFSR; the latest Megamodule Reference Guide states, in table 8-5, that this bit is read-only and always reads as zero.

What does this mean?

Thanks in advance,

SPH

  • 0
    Intellectual 635 points

    A quick addendum: I should have stated that this is on a C6455.

    SPH

  • 0 in reply to SPH
    TI__Mastermind 30825 points

    The bit is reserved and doesn't have any defined meaning.  Usually these reserved bits are 0 by default, but sometimes they are not, such as this case.  That said, as mentioned, it has no definable meaning that the bit is set to 1.

    Best Regards,
    Chad 

  • 0 in reply to Chad Courtney
    Intellectual 635 points

    Hi Chad,

    So you are saying that this is a bug in the documentation; when table 8-5 (and others) states that the only valid value for this bit is 0, it should state that the both 0 and 1 are valid?

    That's a shame, I was hoping that it might provide a clue as to the problem that I am seeing!

    Thanks,

    SPH

  • 0 in reply to SPH
    TI__Mastermind 30825 points

    Well you did have the bit set for SW, a supervisor write request.  L2MPFAR has no address which is strange.  But it would indicated that a Supervisor (the DSP core is master 0, attempted to write a space that was marked not writeable.)  If the address was a correct indicator then it tried to write to 0x00000000 which doesn't have memory. I'm not sure but this may default back to the L2's MP.

    I'd check code for unitialized variables, and make sure the memory map doesn't including anything at 0x00000000

    Best Regards,
    Chad 

  • 0 in reply to Chad Courtney
    Intellectual 635 points

    Thanks Chad.

    We are already very familiar with diagnosing memory faults from the core. Unfortunately, the LOCAL bit is not set which, to my knowledge, indicates that it is an SDMA port access in to the mega-module that is faulting - so either EDMA3 or sRIO, in our case - which, in turn, makes it rather more complex to determine the cause.

    Thanks again,

    SPH

  • 0 in reply to SPH
    Intellectual 955 points

    The DSP I have worked with lately had a feature that with some settings, accessing the lowest 1MB (or part of it - reserved memory address area) causes LiD memory protection fault event. I guess that the protection forces bus error in case of illegal access, and accessing the "zero-page" causes a similar bus error. That is maybe then interpreted by the HW as memory protection violation.

    Works fine for catching null-pointer accesses. You can tell it when you get L1D memory protection event with L1DMPFAR pointing to reserved memory area.