I am developing an MCU system by using the DesignStart Pro, CortexM0 version. I program the DesignStart Pro RTL into Altera FPGA, and I use Keil C for software building.
The system has been run properly so far. But when I changed a small logic in RTL of a peripheral module (called A) in the system, a HardFault Error occurs.
I use ULINK2 debugger to debug the problem, and I see the phenomenon as below.
In “The Definitive Guide to ARM® Cortex®-M0 and Cortex-M0+ Processors” (Second Edition) of Joseph Jiu, I already read the following information.
iii. In “Trouble Shooting” section, there are also 2 cases for troubleshooting the problems that I think it has relation with my case: “Program does not run/start” and “Program started, but enter HardFault”.
My questions are as follows.
For hardware, I check my changes RTL logic of peripheral module (called A), this does not make any error during hardware compile or send a bus error to CPU. As my debug information, when I start to enter debug session, the T bit is cleared right away. There is no chance for any peripheral modules in MCU system running.
For the software, I used the same software which can run well in case I did not modify the logic of hardware.
From above information, I guess the hardware error cause the hardfault. But I can not know which condition of hardware error can clear the T bit to 0 and cause the hardfault.
Is the T bit cleared to 0 caused the PC point to SRAM area?
“. If the T bit in the stacked xPSR is 0 and the stacked PC is pointing to the beginning of an ISR, check the vector table (all LSB of exception vectors should be set to 1).
. If the stacked IPSR (inside xPSR) is indicating an ISR is running, and the stacked PC is not inside the address range of the ISR code, then you likely to have a stack corruption in that ISR. Look out for data array accesses with unbounded index.”
I am sorry for too long question. It takes me several weeks to find out the cause of my problem, but I have not solved my problem yet. Also, I am a newbie of ARM usage, so I do not have enough experience for debug hardfault.
I appreciate for any support from you.
Thank you for your reply.
Firstly, I already built a stable working system. In that system, I investigated how the system works: software code is stored in Code area (0x00000000-0x1FFFFFFF). When the system enters to debug session, PC (R15) points to 0x00000264 (Reset Handler), SP(R13) points to 0x20000968. At this time, T bit is set to 1. Below figure is the information of the working system (not hardfault system).
Regarding to your mention about vector table, I investigated the vector table of my hardfault system (not working system). As my checking, at address 0x00000004 (Reset vector), it contains Reset Handler (0x00000264). At address 0x00000004, it is not 0x20000968 as your guess.
When I enter do debug session, PC point to 0x20000968 and T bit is clear to 0. Both PC and T bit are different from the working system (not hardfault system).
Below is vector table of hardfault system. You can check the Disassembly windows for more information.
Sean Houlihane said:Particularly, watch the stack pointer and the data in the stack since the most likely cause of a problem like the one you describe is stack corruption.
I have thought my hardfault related to stack corruption. Does stack corruption clear the T bit to 0? I want to know which factor clears T bit to 0.
At my thinking, T bit and PC pointing are the root cause of my hardfault problem.
Thank you for your support.
Jack BK said:At my thinking, T bit and PC pointing are the root cause of my hardfault problem.
I would describe this as a symptom of the problem. Somehow, you have attempted an operation which loads illegal state (from the vector table, a branch target or a value read from the stack), and this causes the hardfault.
The possible ways to clear the T bit are described in the ARMv6-M-ARM:
Attempt to execute in an invalid EPSR state, forexample after a BX type instruction has changed state.This includes state change after entry to or return fromexception, or return from interworking instructions.
In the debugger, you are able to change the T bit, and set the PC anywhere legal, then step through your code. You can also change the debug connection options (to reset or not, and to halt after reset).