(my original post had this all int he title line, reposting)
This may span into KDS and the Kinetis SDK. But I am bringing up a K22FRDM board with a Segger Jlink base debugger, and the KDS environment. I am using the SDK startup code, and and properly disabling the watchdog on powerup. But I am still getting an interrupt (which leads to the default unhandled interrupt loop). This happens if I just do a main() while(1) loop and happens a few seconds after startup. How do I determine the source of an interrupt? I have referenced ARM documentation TRM for arm_cortexm4 and looking at the NVIC entry, but there isn't much listed there. What registers would I look for in the debugger to see what the ISR source is? And what is the method in KDS to open a memory dump/display window?
Solved! Go to Solution.
IPSR:
Interrupt Program Status Register
The IPSR contains the exception type number of the current Interrupt Service Routine (ISR).
See the register summary in Table 2-2 on page 2-3 for its attributes. The bit assignments are:
Table 2-5 IPSR bit assignments
Bits Name Function
[31:9] - Reserved
[8:0] ISR_NUMBER This is the number of the current exception:
0 = Thread mode
1 = Reserved
2 = NMI
3 = HardFault
4 = MemManage
5 = BusFault
6 = UsageFault
7-10 = Reserved
11 = SVCall
12 = Reserved for Debug
13 = Reserved
14 = PendSV
15 = SysTick
16 = IRQ0.
.
.
.
n+15 = IRQ(n-1)a
see Exception types on page 2-21 for more information.
a. The number of interrupts, n, is implementation-defined, in the range 1-240.
The stacked PC may or may not provide useful info about the cause.
Thanks to both of you. These both were helpful and got me oriented to find that, yes, it was a hardfault. I was trying to setup a GPIO port that hadn't been enabled yet. Thanks for this help!
Hi Timm Walker,
You also can refer to this post to determine the source of the interrupt:
https://mcuoneclipse.com/2012/11/24/debugging-hard-faults-on-arm-cortex-m/
Please refer to it at first.
waiting for your reply!
Have a great day,
Jingjing
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------
IPSR:
Interrupt Program Status Register
The IPSR contains the exception type number of the current Interrupt Service Routine (ISR).
See the register summary in Table 2-2 on page 2-3 for its attributes. The bit assignments are:
Table 2-5 IPSR bit assignments
Bits Name Function
[31:9] - Reserved
[8:0] ISR_NUMBER This is the number of the current exception:
0 = Thread mode
1 = Reserved
2 = NMI
3 = HardFault
4 = MemManage
5 = BusFault
6 = UsageFault
7-10 = Reserved
11 = SVCall
12 = Reserved for Debug
13 = Reserved
14 = PendSV
15 = SysTick
16 = IRQ0.
.
.
.
n+15 = IRQ(n-1)a
see Exception types on page 2-21 for more information.
a. The number of interrupts, n, is implementation-defined, in the range 1-240.
The stacked PC may or may not provide useful info about the cause.