How should I initialise my stm32 ( f215 )

I am trying to make an extremely minimal stm32f215 firmware to teach myself its boot-up intricacies. As it is now I have this dump which, to my knowledge, should write the stack address to r0 and loop forever:

firmware-d:     file format elf32-littlearm


Disassembly of section .isr_vector:

08000000 <vector>:
 8000000:       20002000        andcs   r2, r0, r0
 8000004:       08000009        stmdaeq r0, {r0, r3}

08000008 <reset_handler>:
 8000008:       f85f 00c       ldr.w   r0, [pc, #-12]  ; 8000000 <vector>

0800000c <loop>:
 800000c:       e7fe            b.n     800000c <loop>

But when I debug it I end up with PC = 0xFFFFFFFF, LR = 0x20002000, R0 = 0x0 and SP = 0x0. And, also, nothing in the CFSR to hint at what goes wrong...

Any experienced coders here that have a clue?

(PS: the hardware boot pins are set to alias 0x0 to 0x800 0000)

Edit: I just realised that the CPSR has the overflow flag set. Still no clue why, though.

Edit2:

• All information I have found states that the cortex-m3 only can execute thumb and will hard fault if told to execute arm.
• I am aware that it is a bad idea to place my code in the isr_vector in the long term. I have tried padding it with addresses to "loop", but it made no change. I have this code as a minimal example.
• "With a breakpoint..." So far I have not been able to make it stop at any breakpoint. The only thing that works is "starti", which stops it before branching to "reset_handler". "stepi" from there puts me directly to the described state.
• This is a dump of the elf file, since it looks prettier than GDB's output. I have verified that this data exists both in 0x0 and 0x800 0000 on chip.
• Data from the card, fresh flash and "starti":

(gdb) info registers 
r0             0x0                 0
r1             0x0                 0
r2             0x6d8d1d05          1837964549
r3             0x7fbf              32703
r4             0x8000008           134217736
r5             0x8000008           134217736
r6             0x8000008           134217736
r7             0x8000008           134217736
r8             0x8000008           134217736
r9             0x8000008           134217736
r10            0x8000008           134217736
r11            0x8000008           134217736
r12            0x8000008           134217736
sp             0x8000008           0x8000008
lr             0x8000008           134217736
pc             0x8000008           0x8000008
cpsr           0x8000008           134217736
(gdb) disassemble /r 0x0,0x10
Dump of assembler code from 0x0 to 0x10:
   0x00000000:  00 20   movs    r0, #0
   0x00000002:  00 20   movs    r0, #0
   0x00000004:  09 00   movs    r1, r1
   0x00000006:  00 08   lsrs    r0, r0, #32
   0x00000008:  00 48   ldr r0, [pc, #0]    ; (0xc)
   0x0000000a:  fe e7   b.n 0xa
   0x0000000c:  68 46   mov r0, sp

(As you can see the value in 0xc is currently dead code.)

(gdb) disassemble /r 0x8000000,0x8000010
Dump of assembler code from 0x8000000 to 0x8000010:
   0x08000000 <vector+0>:   00 20   movs    r0, #0
   0x08000002 <vector+2>:   00 20   movs    r0, #0
   0x08000004 <vector+4>:   09 00   movs    r1, r1
   0x08000006 <vector+6>:   00 08   lsrs    r0, r0, #32
=> 0x08000008:  00 48   ldr r0, [pc, #0]    ; (0x800000c <reset_handler_c>)
   0x0800000a:  fe e7   b.n 0x800000a
   0x0800000c <reset_handler_c+0>:  68 46   mov r0, sp

• The board is a custom board based around the stm32f215. I use st-link (v2) to flash and debug through https://github.com/stlink-org/stlink. Flashing it with known good code works with this solution, but I am not sure if the debugger is working entirely as it should.
• Both boot pins are directly grounded through 1kOhm resistors.
• After changing the code a bit to branch directly to loop I can conclude that no matter what assembly instruction is first it will lock up. The branch back to loop caused the same error.
• The CFSR and HFSR:

(gdb) print/x *(uint32_t *) 0xE000ED28
$1 = 0x0
(gdb) print/x *(uint32_t *) 0xE000ED2C
$2 = 0x0

• I can very nearly guarantee that the stlink application I use is mixing up sp and lr. A known good program doesn't have sp=0x8f0d180 and lr=0x2001ff88. Will tomorrow look into using openocd instead.

And the culprit has been found! It appears the st-util debugger (from the project mentioned above) causes an error somehow. openocd works like a charm and with that the minimal code above works.

Anyway, bug reports to write and all that...

Thank you all so much for verifying my assembler and helping me with dotting all the t's and crossing all the i's!