I was working on a code to setup ARM MMU. I work using fast models.
I put some dummy values in the VTTBR register and I got a data abort.
I have seen this post How to handle this Data Abort exception in ARM 7? mode in CPSR 0x17 and board stucked at 0x10 and I tried to look at the link register.
From there I found that the abort happened with this instruction: MOVT r3,#0x8400.
But before this already a move has happened like MOV r3,#0x9240. I am quite perplexed about what went wrong with the second move. I want to know precisely which type of data abort happened out of the four types possible (1.alignment faults 2.translation faults 3.domain faults 4.permission faults.).
My code goes like this
840000A4 : MOV r3,#0x9240
840000A8 : MOVT r3,#0x8400
I know that MOVT moves values in to upper(top) half word without affecting the bottom half word.
My LR contains 840000A8.
Actually answering this would require reproducing a dozen or more pages of the ARMv7-A Architecture Reference Manual, so consider this more of a set of signposts pointing at what to research; system-level programming on ARMv7-A is involved to the point that it's going to be painful without the proper reference material, especially if you confuse the architecture version with the much older and simpler ARM7 core (ARMv4 architecture).
Since ARMv6, what was the FSR is now the DFSR (mrc p15, 0, <Rt>, c5, c0, 0), which as it says on the tin tells you the status of a data fault (instruction faults have a separate IFSR). If the abort was synchronous, the DFAR (mrc p15, 0, <Rt>, c6, c0, 0) will also tell you the faulting address.
Furthermore, the link register* value for a data abort is 8 bytes ahead of the faulting instruction (although note that, unlike the normal PC behaviour, it is always 8 bytes, regardless of instruction set), so if your LR contains 0x840000a8, you need to be looking at 0x840000a0 for the culprit.
* Assuming of course that we're not talking about taking exceptions to Hyp mode, because Hyp mode is a different kettle of fish altogether.