blog/posts/2012-06-11-debugging-a-hard-fault-in-arm-cortex-m3s.markdown

---
author: Sanchayan Maity
title: Debugging a hard fault in ARM Cortex M3
tags: ARM, cortex, hardfault, stellaris
---

<p style='text-align: justify;'>I have been working on the Stellaris LM3S6965 for quiet a while now. So I thought, may be I will put my learning's in one place, so others can use them and not get stuck, where I did.</p>

<p style='text-align: justify;'>The Stellaris LM3S6965 is based on the ARM Cortex M3 architecture. What I am going to mention in my post, is how to track down the source of a hard fault. So let's get straight to the point.</p>

<p style='text-align: justify;'>On getting a hard fault, check the value of MSP and PSP viz. the stack pointers. It's likely the MSP, if you are not using an RTOS.</p>

<p style='text-align: justify;'>Go to the address contained in the MSP. The following registers would be on the stack in increasing order.</p>

Registers ro - r3, r12, lr, pc, xpsr.

<p style='text-align: justify;'>One thing I must mention is, if your fault handler does something other than spinning in a loop, a couple of other registers might be pushed on to the stack by the compiler. You need to take care of this. I am assuming here, that the default fault handler does nothing else besides spinning in a loop.</p>

<p style='text-align: justify;'>So take a look at the stack. The pushed PC should help you in debugging, as it usually points to the instruction that caused the fault.</p>

<p style='text-align: justify;'>The next place to look is in the NVIC viz. the Nested Vector Interrupt Controller. The Configurable Fault Status Register is at address 0xE000ED28 and contains bits that identify the cause of the fault and can also tell if the stacked PC actually points to the faulting instruction. There are a couple of other registers, the Memory Manage Fault Address register and the Bus Fault Address register which provide the address of the fault for those kinds of faults. But, you need to look at the status register first to identify the cause of the fault and that will tell you if the BFAR or MMFAR contains a useful address.</p>

<p style='text-align: justify;'>To learn more, refer to the ARM Cortex M3 technical reference manual. If you would like to learn about ARM architecture in general, the ARM System Developer's Guide by Andrew Sloss, Dominic Symes and Chris Wright is a very good place to start.</p>
Initial commit for blog migration to Hakyll Never gave a damn about jekyll/ruby except to use it for github pages. Now use Hakyll/Haskell and migrate from jekyll/ruby. 2017-02-13 21:30:46 +01:00			`---`
			`author: Sanchayan Maity`
			`title: Debugging a hard fault in ARM Cortex M3`
Fix tags Signed-off-by: Sanchayan Maity <maitysanchayan@gmail.com> 2020-04-04 16:45:31 +02:00			`tags: ARM, cortex, hardfault, stellaris`
Initial commit for blog migration to Hakyll Never gave a damn about jekyll/ruby except to use it for github pages. Now use Hakyll/Haskell and migrate from jekyll/ruby. 2017-02-13 21:30:46 +01:00			`---`

Update posts 2017-06-10 14:13:43 +02:00			`<p style='text-align: justify;'>I have been working on the Stellaris LM3S6965 for quiet a while now. So I thought, may be I will put my learning's in one place, so others can use them and not get stuck, where I did.</p>`
Initial commit for blog migration to Hakyll Never gave a damn about jekyll/ruby except to use it for github pages. Now use Hakyll/Haskell and migrate from jekyll/ruby. 2017-02-13 21:30:46 +01:00
Update posts 2017-06-10 14:13:43 +02:00			`<p style='text-align: justify;'>The Stellaris LM3S6965 is based on the ARM Cortex M3 architecture. What I am going to mention in my post, is how to track down the source of a hard fault. So let's get straight to the point.</p>`
Initial commit for blog migration to Hakyll Never gave a damn about jekyll/ruby except to use it for github pages. Now use Hakyll/Haskell and migrate from jekyll/ruby. 2017-02-13 21:30:46 +01:00
			`<p style='text-align: justify;'>On getting a hard fault, check the value of MSP and PSP viz. the stack pointers. It's likely the MSP, if you are not using an RTOS.</p>`

			`<p style='text-align: justify;'>Go to the address contained in the MSP. The following registers would be on the stack in increasing order.</p>`

			`Registers ro - r3, r12, lr, pc, xpsr.`

Update posts 2017-06-10 14:13:43 +02:00			`<p style='text-align: justify;'>One thing I must mention is, if your fault handler does something other than spinning in a loop, a couple of other registers might be pushed on to the stack by the compiler. You need to take care of this. I am assuming here, that the default fault handler does nothing else besides spinning in a loop.</p>`
Initial commit for blog migration to Hakyll Never gave a damn about jekyll/ruby except to use it for github pages. Now use Hakyll/Haskell and migrate from jekyll/ruby. 2017-02-13 21:30:46 +01:00
			`<p style='text-align: justify;'>So take a look at the stack. The pushed PC should help you in debugging, as it usually points to the instruction that caused the fault.</p>`

			<p style='text-align: justify;'>The next place to look is in the NVIC viz. the Nested Vector Interrupt Controller. The Configurable Fault Status Register is at address 0xE000ED28 and contains bits that identify the cause of the fault and can also tell if the stacked PC actually points to the faulting instruction. There are a couple of other registers, the Memory Manage Fault Address register and the Bus Fault Address register which provide the address of the fault for those kinds of faults. But, you need to look at the status register first to identify the cause of the fault and that will tell you if the BFAR or MMFAR contains a useful address.</p>

			`<p style='text-align: justify;'>To learn more, refer to the ARM Cortex M3 technical reference manual. If you would like to learn about ARM architecture in general, the ARM System Developer's Guide by Andrew Sloss, Dominic Symes and Chris Wright is a very good place to start.</p>`