I've just spent a few hours debugging an issue on a KL17 that was driving me crazy. I want to preface this by saying it's resolved. Once I power cycled the part everything worked fine, but I'm still perplexed as to what was going on in case I have future issues like this.
Here's the scenario:
I connected to the KL17 using IAR and a J-Link debugger. The debugger dropped me at the application's reset vector and everything looked great. I ran the application and nothing happened. Hitting the break button, the debugger showed that execution was in the bootloader on a jump-to-self instruction. I reset and stepped through and managed to get all the way to MQX start when it sets PendSV and prepares to start the Main Task. As soon as interrupts are enabled, execution ended up at the same address.
I checked to see if it was stepping to that instruction, but no, it jumped directly to that address. The SCB indicated that the PendSV exception was active (and SysTick was pending behind it). I double checked the vector table at 0x00000000, and double checked that VTOR was indicating that the table was at address 0. That all checked out. It wasn't until I power cycled the system that everything started working.
Here's what I suspect: this was the first time this chip had been programmed, meaning it would have been sitting in the ROM bootloader when I connected with the debugger. I suspect that for whatever reason the core was still using the bootloader's vector table (at 0x1C000000). Checking the memory there, I did find that the address I was ending up at (the infinite loop) was used for the NMI, SVC and PendSV handler address (presumably a "not used" handler).
I can't for the life of me figure out how the wrong table was being used, though. Are there any registers or controls that I've missed that may have stealth remapped the vector table?
