• State Not Answered
  • Locked Locked
  • Replies 10 replies
  • Subscribers 348 subscribers
  • Views 11815 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
  • 0
    Note: This was originally posted on 7th January 2009 at http://forums.arm.com

    can anybody give the answer?I am stuck at this stage.

    regards,
    Sumit
  • 0
    Note: This was originally posted on 7th January 2009 at http://forums.arm.com

    Hi ,

    thanks for the reply.

    Mine is the multi master system having two master on APB lite bus.The code crashes when I start tx/rx from the ethernet controller.Otherwise everything works fine.The code works partially in debug but not at all in release.

    regards,
    Sumit
  • 0
    Note: This was originally posted on 9th January 2009 at http://forums.arm.com

    Hi Joseph,

    thanks a lot.You indicated the right thing.There are pointers and arrays in my c-code and possibly it creates some unaligned transfer.Soon I will check it.I am also going to design system again.I am not getting the interrupt from the core even if the interrupts are enabled.

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

    Thanks a lot sim,

    I think mine has the problem of misaligned memory access or dereferencing of pointer.My code is completely written in C and I build on SoftConsole Ide of Actel.Code is heavily using pointer so I will check that.

    I modified the access of pointer to write the register and it started working in debug mode.It works only when I do single stepping but not in run mode.

    Is there anything that forces the code to run under debug?

    regards,
    Sumit
  • 0 Arm Employee Badge
    Note: This was originally posted on 7th January 2009 at http://forums.arm.com

    If it works when stepping, but not in run mode, are you sure you are looking at the right part of the code?

    This normally indicates that the processor has run the bit that you were stepping over without a problem, and has crashed later in the code execution.

    Iso
  • 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.
  • 0
    Note: This was originally posted on 8th December 2009 at http://forums.arm.com

    Not sure if it help, there are various things you might need to check.
    First, please check if the FPGA image you are using contains the OS support.
    (On Cortex-M1 OS support hardware is optional).

    What might have happen is that :
    - you created your stack frame in the stack
      (Is the content of the stack frame correct?
      If the stack frame aligned to double word address?)
    - you set your process stack pointer (PSP) to point to the beginning of this stack frame
      (Did you update PSP correctly?
      Did you take account of the requirement of double word alignment?
      Does the PSP really pointing to the correct address in the stack frame?)
    - You carry out an exception return, LR specifying using PSP for unstacking.
      (did LR set to correct value?)
    - The exception return load the stack frame contents into registers.
      If the PSP location is wrong, the processor loaded in incorrect values.
      This include the 0xa5a5a5a5 loading into PC. Since this is not a valid location
      for program code, the hard fault is triggered when it try to fetch instruction.
    - At hard fault exception entry, the value 0xa5a5a5a5 is pushed to the stack as return address.
    regards,
    Joseph
  • 0
    Note: This was originally posted on 8th January 2009 at http://forums.arm.com

    Would it be an exception handler corrupted the stacked memory, and hence affect the register's content after exception return?  When the interrupt program is resumed after the interrupt handler, the memory pointer became invalid and might cause unaligned transfer.  You can try setup some variables to trace what exception handlers has been running before the fault, and see if the exception handler has any operations that can corrupt the stack (e.g. data array in local variables with unbounded index).
  • 0
    Note: This was originally posted on 8th December 2009 at http://forums.arm.com

    I get a hardfault expection aswell. I checked my pointers, everything seems to be OK. I'm currently porting an microKernel to the M1, so i adjust StackPointer to different Stacks in Memory (Task Control Blocks) i checked my code, i don't think i make a misstake there.  But it seems the the crash occures after the ContextSwitch. And it only occures in running mode, when i step i never leave the IRQ handler, but this might be because interrupts coming fast enough to inflict a new IRQ before i stepped through one.

    Well i sticked a breakpoint to the begin of the HardFault handler, and checked the memory adress of the StackPointer+24. This should be the ReturnAddress that has been saved automaticly on the stack while entering the (fault) exception. But for some reason i got only the initial value (a5a5a5a5) of this memory section at the address. There seems to be nothing written. I got a value in the saved LR (SP+20) and a value in the saved xPSX (SP+28) memory, which seems to be both correct.
    How can this happen? Since the procedure which pushes the 8 registers on entry of exception on the stack is pushing xPSR than returnAdress and than LR. So i't cant be an issue with abort of this push function - if there were the LR have to be empty aswell.

    I just wonder how to track this error. I have no idea how to debug this.


    I afforded 2 days in verifying my code with teammates, cant find an error there. Neither in the C Source nor in the Assembly which contains the context switch.
    I already wrote a port for another kernel, worked and was easy going.


    From all what i can find in the Reference Manuals, the Internet and this Forum it seems to be an issue with the Stackpointer, but in stepping mode its working as expected. And i reviewed my program architecture - dont think the error is coming from there.

    What ever, I'd really appreciate it if someone got an idea how to backtrack this hardfault. Thanks in advance.
  • 0
    Note: This was originally posted on 10th December 2009 at http://forums.arm.com

    [...]
    - The exception return load the stack frame contents into registers.
      If the PSP location is wrong, the processor loaded in incorrect values.
      This include the 0xa5a5a5a5 loading into PC. Since this is not a valid location
      for program code, the hard fault is triggered when it try to fetch instruction.
    - At hard fault exception entry, the value 0xa5a5a5a5 is pushed to the stack as return address.
    [...]


    Thanks for this advice. I just thought the 0xa5a5a5a5 was initial value within this adress - never thought of it has been loaded there. I changed the initial values of the Stackframe, to see if the value changes. And it did. I could backtrace this to a corruption of the stack. We made a mistake in the stack initializing function, which lead to a corruption over time.