Debugging INVSTATE UsageFault in an unexpected location

I'm working on a project using an STM32F413 processor (Cortex-M4), using the Micrium UCOS-II operating system. I've been trying to debug this very odd INVSTATE UsageFault that started happening when I added some new features. The fault seems to always happen 3 nested interrupts deep, in UCOS-II's OSTimeTick function (which is called from the SysTick handler), but occurs at an inconsistent time, generally between 1 and 10 minutes after boot (which makes it very hard to debug).

Here's some information on one instance of the fault.

Stack frame:

{
    r0 = 0x0,
    r1 = 0x0,
    r2 = 0x0,
    r3 = 0x0,
    r12 = 0x12121212,
    lr = 0x800f42f <OS_Sched+94>,
    pc = 0x800ecb0 <OSTimeTick+16>,
    xpsr = 0xf
}

Two things jump out at me here:

1. LR is an odd-numbered value, which shouldn't happen on this processor since it's Thumb only
2. The T-bit in the XPSR is 0, which also shouldn't happen on this processor for the same reason. This is obviously the source of the INVSTATE fault.

The stacked PC points to this code (snippet from the disassembly of OSTimeTick()):

0x0800eca0: 80 b5           	push	{r7, lr}
0x0800eca2: 84 b0           	sub	sp, #16
0x0800eca4: 00 af           	add	r7, sp, #0
0x0800eca6: 00 23           	movs	r3, #0
0x0800eca8: 7b 60           	str	r3, [r7, #4]
0x0800ecaa: ff f7 23 fe     	bl	0x800e8f4 <OSTimeTickHook>
0x0800ecae: f1 f7 cd fa     	bl	0x800024c <OS_CPU_SR_Save>
0x0800ecb2: 78 60           	str	r0, [r7, #4]
0x0800ecb4: 44 4b           	ldr	r3, [pc, #272]	; (0x800edc8 <OSTimeTick+296>)
0x0800ecb6: 1b 68           	ldr	r3, [r3, #0]
0x0800ecb8: 01 33           	adds	r3, #1
0x0800ecba: 43 4a           	ldr	r2, [pc, #268]	; (0x800edc8 <OSTimeTick+296>)
0x0800ecbc: 13 60           	str	r3, [r2, #0]
0x0800ecbe: 78 68           	ldr	r0, [r7, #4]

What seems odd to me here is that the value of the PC (0x0800ecb0) does not actually point to any instructions here, but to an address in the middle of the BL instruction at 0x0800ecae, which is a branch to OS_CPU_SR_Save. I don't know what would cause that to happen, unless I'm just misinterpreting how that memory is stored and accessed. Regardless, even if it was executing the BL instruction correctly, why would it trigger an INVSTATE fault? There shouldn't be any instruction set exchange happening there.

I'm not necessarily looking for a solution; more of just some recommendations on where to look, especially if people have seen something similar before. I'm by no means an ARM expert, so it's very likely I missed something in my debugging of this.