Checking the link register (r14) as described in your Keil link above will show you the instruction that triggered the data abort. From there you'll have to figure out why it triggered a data abort and how that could have happened, which is the difficult part.
In my experience what most likely happened is that you accessed an invalid pointer. It can be invalid for many reasons. Here are a few candidates:
- You used the pointer before it was initialized
- You used the pointer after it, or the containing memory, had been freed (and was subsequently modified when another function allocated it)
- The pointer was corrupted by a stack overflow
- The pointer was corrupted by other, unrelated, misbehaving code that is trampling on memory
- The pointer was allocated on the stack as a local variable and then used after the allocating function had exited
- The pointer has incorrect alignment for its type (for example, trying to access 0x4001 as a uint32_t)
As you can see, lots of things can be the root cause of an ARM data abort. Finding the root cause is part of what makes ARM software/firmware development so much fun! Good luck figuring out your puzzle.