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

alloc ram causes hardfault

Hello,

I'm using a lpc1766 and made a very simple program to debug a hardfault exception.

After initiallisation the main routine is called where a array is allocated using the library function malloc().

When the malloc function is called a "bus fault" exception arises which ends up in a "hard fault" exception. In the hard fault exception handler I can read the exception registers using the debugger "fault reports" dialog.

When I double click on the topmost entry of the callstack it jumps to the following instruction:
0x00000280 4605 MOV r5,r0

Can somenone tell me why my code ends up in hardfault exception?

Below is the function in C and assembly.

void *alloc_ram(uint16 size)
{
  void *ram;

  __disable_irq();

  ram = malloc(size);

  __enable_irq();

  return(ram);
}


    32: {
    33:   void *ram;
    34:
0x00000274 B570      PUSH     {r4-r6,lr}
0x00000276 4604      MOV      r4,r0
    35:   __disable_irq();
    36:
0x00000278 B672      CPSID    I
    37:   ram = malloc(size);
    38:
0x0000027A 4620      MOV      r0,r4
0x0000027C F000F840  BL.W     malloc (0x00000300)
0x00000280 4605      MOV      r5,r0
    39:   __enable_irq();
    40:

Parents
  • WOW, that was a quick response.
    Unfortunately, after reading your e-mail, I did more checks and found no reason why the code is failing. The only thing that I would like to explore more is the "blocking" (see below).

    1) where it dies? most likely inside the malloc. When I step into malloc, the PC "arrow" does not come back. If I stop the program, its always in the hard fault interrupt loop (forever loop).

    2) this is the first allocation in the program i.e. I should have enough memory. In all cases, 1) I do check for a NULL return before trying to access the data and 2) the jump to the fault handler is happening during alloc.

    3) I thought that alloc uses heap not stack! but I have a heap size of 0x4000 and a stack size of 0x1000. Since its failing on the first call to alloc, I dont think that I have used all of that memory.
    In addition, no stack overflow is detected by the RTOS.

    4) please explain further on the blocking. it might be the cause.

    5) I dont think that the the malloc() data structures have been destroyed. Again, I did not get beyond the allocation command.

    6) no stack overflow is reported. The os_stk_overflow (replaced by os_error) is not called.

    7) yes I'm writing a normal C code.

    One additional information, If I disable the RTX kernal, malloc works fine

    khaled.

Reply
  • WOW, that was a quick response.
    Unfortunately, after reading your e-mail, I did more checks and found no reason why the code is failing. The only thing that I would like to explore more is the "blocking" (see below).

    1) where it dies? most likely inside the malloc. When I step into malloc, the PC "arrow" does not come back. If I stop the program, its always in the hard fault interrupt loop (forever loop).

    2) this is the first allocation in the program i.e. I should have enough memory. In all cases, 1) I do check for a NULL return before trying to access the data and 2) the jump to the fault handler is happening during alloc.

    3) I thought that alloc uses heap not stack! but I have a heap size of 0x4000 and a stack size of 0x1000. Since its failing on the first call to alloc, I dont think that I have used all of that memory.
    In addition, no stack overflow is detected by the RTOS.

    4) please explain further on the blocking. it might be the cause.

    5) I dont think that the the malloc() data structures have been destroyed. Again, I did not get beyond the allocation command.

    6) no stack overflow is reported. The os_stk_overflow (replaced by os_error) is not called.

    7) yes I'm writing a normal C code.

    One additional information, If I disable the RTX kernal, malloc works fine

    khaled.

Children