Finding the source of an interrupt on the FRDMK22 board.

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Finding the source of an interrupt on the FRDMK22 board.

Jump to solution
1,121 Views
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 Solution
915 Views
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.

View solution in original post

3 Replies
915 Views
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 Kudos
Reply
915 Views
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!
-----------------------------------------------------------------------------------------------------------------------

916 Views
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.