• State Not Answered
  • Locked Locked
  • Replies 10 replies
  • Subscribers 348 subscribers
  • Views 11817 views
  • Users 0 members are here
Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

hard fault with Cortex M1

sumit sumit
Note: This was originally posted on 24th December 2008 at http://forums.arm.com

Hi all,

I am developing firmware on Cortex M1 on Actel fusion FPGA.I have built the design that has sram at 0x0 location ,size is 1mb and I use it as my program memory.I have Ethernet interface and I want to debug the driver for the ipcore.

I am facing the problem due to hard fault.When I start the transmission on the Ethernet,after transmission first frame the cortex goes to hard fault.

Would anyone tell me  what may be the reason for hard fault? How to overcome?

I am completely new to arm environment.

regards,
Sumit
Parents
  • 0 Arm Employee Badge
    Note: This was originally posted on 24th December 2008 at http://forums.arm.com

    Sumit,

    On Cortex-M1, all non-recoverable faults will enter HardFault.

    If the cause is associated to an instruction, then on entry to the HardFault handler, the memory location at SP + 24 will contain the address of the instruction that generated the HardFault; the cause of this is typically execution of an UNDEFINED instruction, or more likely (assuming your code is written in C) attempting to perform a mis-aligned memory access (for example as the result of an unpredictable cast in C, e.g, casting a char pointer to a word pointer and dereferencing), or, if you integrated the NIC yourself, generation of an AHB error (HRESP = 1). Other causes include the use of a BKPT without a debugger attached, or an SVC instruction at too higher priority (or on a Cortex-M1 without OS extensions).

    Failing that, if you are using interrupts, then you need to ensure that the least-significant bit of the vector table entries are set, so as to execute Thumb code rather than in the unimplemented/unsupported ARM mode.

    hth
    s.
Reply
  • 0 Arm Employee Badge
    Note: This was originally posted on 24th December 2008 at http://forums.arm.com

    Sumit,

    On Cortex-M1, all non-recoverable faults will enter HardFault.

    If the cause is associated to an instruction, then on entry to the HardFault handler, the memory location at SP + 24 will contain the address of the instruction that generated the HardFault; the cause of this is typically execution of an UNDEFINED instruction, or more likely (assuming your code is written in C) attempting to perform a mis-aligned memory access (for example as the result of an unpredictable cast in C, e.g, casting a char pointer to a word pointer and dereferencing), or, if you integrated the NIC yourself, generation of an AHB error (HRESP = 1). Other causes include the use of a BKPT without a debugger attached, or an SVC instruction at too higher priority (or on a Cortex-M1 without OS extensions).

    Failing that, if you are using interrupts, then you need to ensure that the least-significant bit of the vector table entries are set, so as to execute Thumb code rather than in the unimplemented/unsupported ARM mode.

    hth
    s.
Children
No data