Finding the source of an interrupt on the FRDMK22 board.

取消
显示结果 
显示  仅  | 搜索替代 
您的意思是: 
已解决

Finding the source of an interrupt on the FRDMK22 board.

跳至解决方案
1,879 次查看
timmwalker
Contributor I

(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?

1 解答
1,673 次查看
egoodii
Senior Contributor III

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.

在原帖中查看解决方案

3 回复数
1,673 次查看
timmwalker
Contributor I

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!

0 项奖励
回复
1,673 次查看
kerryzhou
NXP TechSupport
NXP TechSupport

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!
-----------------------------------------------------------------------------------------------------------------------

1,674 次查看
egoodii
Senior Contributor III

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.