This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Prefetch Abort due to unaligned PC.

Note: This was originally posted on 22nd August 2011 at http://forums.arm.com

Hi,

I am working on ARM1136 processor in Thumb mode.

Problem

I am getting a prefetch abort while executing an instruction. Program Counter at this instant is odd.



Description

My source code has few instructions as below...

                            ....
                        [color=#FF0000]    [/color]bx lr   [color=#FF0000]       [/color];lr = 0xB76B2A39 i.e. some odd value


After executing this instruction the code jumps to the  location 0xB76B2A38 (pc = lr & 0xFFFFFFFE) which has the instruction as below

Address 0xB76B2A38:   [color=#FF0000]  [/color]ldr r0, #0xB76B5DAC [color=#FF0000]    [/color];prefetch abort.

The above instruction generates a prefetch abort as the pc value is odd 0xB76B2A39.



BX Instruction description

BX Rm instruction ensures that the location that you jump to is half a word aligned. i.e. pc = lr & 0xFFFFFFE

ARM thumb mode requires that pc should always be half a word aligned.



In this case pc alignment (to be done by the processor) did not take place. How can I figure out whether the processor is goofing up or there is some software issue?

Thank you.
Nikhil.
  • Note: This was originally posted on 23rd August 2011 at http://forums.arm.com


    The bottom bit in the address of a BX instruction is used to encode the "eXchange" - the state change from ARM to Thumb. So the address you feed the BX instruction looks fine.

    I would check the following:
    • Does the destination address exist (i.e. is it mapped in the MMU)?[list]
    • Yes
    • Does the destination address contain code (i.e. is it mapped as executable in the MMU)?
      • Yes
      • Does the destination address contain an instruction which is valid encoding for the current instruction set?
        • Yes
        • If you are using ARM and Thumb code make sure it is all compiled for "interworking"
          • Yes
          • Check the Fault Status Register in CP15 - this will give more info about why an abort was raised.
            • Status is 0x7; TTBR0 - 0xB7568B58, CR - 0x00457B7D
            • Status 0x7 translates to b0111 - Translation Fault. How the cpu can crash during translation?[/list]

              What platform are you running on, and which core revision?

              Cheers,
              Iso
          • Note: This was originally posted on 23rd August 2011 at http://forums.arm.com

            Hi isogen74,

            Thanks for the info.

            1) Can you explain in a little more detail about how you are concluding that " you are branching to an invalid address (the L2 page table entry is a fault page)."

            2) One more thing is the PC and LR value at this point is same 0xB76B2A39.

            Address 0xB76B2A38 contains the correct code to be executed.

            So when I execute this instruction :

                bx lr    ; lr = 0xB76B2A39 - arm mode

            I am supposed to go to the location 0xB76B2A38 which has the correct code that should be executed.

            Few things to note:
            • I am switching from arm to thumb mode with bx lr.
            • After executing the instruction "bx lr" - pc should become lr & 0xFFFFFFFE (from arm instruction manual)[list]
            • So pc should become lr & 0xFFFFFFFE -> 0xB76B2A39 & 0xFFFFFFFE -> 0xB76B2A38
            • However, the pc value at this point is shown as 0xB76B2A39 and automatic alignment is not happening.[list]
            • So I thought that some alignment fault is causing prefetch abort.
            • But IFSR as well as DFSR value is 00000000.[/list]
            • In abort handler we print the last fault status which is 0x7 (I guess translation page fault)
            • CR value at this point is 0x00457B7D[/list]
              DFSR, IFSR, IFAR, DFAR are not updated. I read in the documentation that if fault is due to some instruction MMU does not updates the registers. These registers are updated only in the case of data access.

              Also since TTBR0 is updated it could be due to a TLB miss. What kind of a fault can occur in this case? Is this a software or a hardware problem?
              Please give some pointers.


              It is a translation fault for the page walk, which implies that you are branching to an invalid address (the L2 page table entry is a fault page). If you expect this address to be valid check your page table creation code.

              See http://infocenter.ar...h/Babicjaf.html
          • Note: This was originally posted on 8th September 2011 at http://forums.arm.com

            Any Update? The issue solved? What is the root cause?


            The issue is still pending. MMU raised a false alarm (Translation page fault) even though the address being accessed was a valid virtual address.
            I was hoping arm tech support would help me with this issue. No response yet!
          • Note: This was originally posted on 8th September 2011 at http://forums.arm.com


            Did you e-mail, or were you hoping they'd look at the thread?


            I am under the impression that ARM guys are active on this forum. Anyway, we are trying to contact them also.

            I will post the solution as soon as we find it. Till then any kind of help is welcome.
          • Note: This was originally posted on 8th September 2011 at http://forums.arm.com

            Any Update? The issue solved? What is the root cause?
          • Note: This was originally posted on 8th September 2011 at http://forums.arm.com

            Did you e-mail, or were you hoping they'd look at the thread?
          • Note: This was originally posted on 8th September 2011 at http://forums.arm.com

            Dear All,

            Although the forums are hosted by ARM, ARM's support team do not guarantee monitor the forum threads or provide answers.  As explained in the pinned thread on service levels, answers are provided voluntarily by the public.

            Regards,

            Martin
          • Note: This was originally posted on 22nd August 2011 at http://forums.arm.com

            The bottom bit in the address of a BX instruction is used to encode the "eXchange" - the state change from ARM to Thumb. So the address you feed the BX instruction looks fine.

            I would check the following:
            • Does the destination address exist (i.e. is it mapped in the MMU)?
            • Does the destination address contain code (i.e. is it mapped as executable in the MMU)?
            • Does the destination address contain an instruction which is valid encoding for the current instruction set?
            • If you are using ARM and Thumb code make sure it is all compiled for "interworking"
            • Check the Fault Status Register in CP15 - this will give more info about why an abort was raised.
            What platform are you running on, and which core revision?

            Cheers,
            Iso
          • Note: This was originally posted on 23rd August 2011 at http://forums.arm.com

            It is a translation fault for the page walk, which implies that you are branching to an invalid address (the L2 page table entry is a fault page). If you expect this address to be valid check your page table creation code.

            See http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0333h/Babicjaf.html