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.
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).