LPC1114 hard fault issue

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

LPC1114 hard fault issue

5,073 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by karthik.s on Mon Jul 26 04:16:12 MST 2010
I am running an application on LPC1114 device.On running the application code,the program is getting halted at HardFault_Handler() routine at the brace marked in red.
void HardFault_Handler(void)
[COLOR=Red][B]{[/B][/COLOR]
    //
    // Enter an infinite loop.
    //
    while(1)
    {
    }
}
After pushing "F5" to step into,the program halts at a user defined function(does dynamic memort allocation) at the line highlighted in red.The function is as follows.

void *RSI_user_malloc(uint32_t bytes) /* This function is registered by the user for allocating  the dynamic memory */
{
  void *dynamic_data;
  [COLOR=Red]dynamic_data[/COLOR] = (void *)malloc([COLOR=DarkOrchid]bytes[/COLOR]);
  return dynamic_data;

}

When i checked the content of "bytes" variable, it displays it to be 293.I am wondering if my heap memory is not sufficient to allocate memory equivalent to 293 bytes.

Any help is appreciated.
0 Kudos
Reply
24 Replies

4,724 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by saimot on Fri Mar 01 17:40:35 MST 2013
Yes I stepped it and it failed on that allocation so I cant see return value. For a while it was working well, just now when I added code after(which doesent allocate anything) it started to crush again.

After removing this additional code, it keeps crushing!

And it also happens on the first run when Im allocating just a few Bytes.

Add: even allocating char crashes when replaced.
0 Kudos
Reply

4,724 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by TheFallGuy on Thu Feb 21 00:49:01 MST 2013
Have you single-stepped through the code and checked the value returned by malloc? If you allocate to much memory, or never free, you will quickly run out of memory and malloc will fail.
0 Kudos
Reply

4,724 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by saimot on Wed Feb 20 19:07:37 MST 2013
I have compiled it many times but mostly Im getting the same error. When I made changes you recomanded, it seemed working but after some code added(after this allocation) it crushed again
0 Kudos
Reply

4,724 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by Ex-Zero on Wed Feb 20 17:25:39 MST 2013

Quote: saimot
However this doesent help ...



:confused:

Changing to a standard pointer solved this error here :eek:
0 Kudos
Reply

4,724 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by saimot on Wed Feb 20 17:18:11 MST 2013
Thanks, for reply. However this doesent help and Im getting the same error. I have already tried different ways but its still the same. I also tried to build it again  based on the demo project for base board.

Any ideas? Im stuck right now and its just a beginning of a project...
0 Kudos
Reply

4,724 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by Ex-Zero on Tue Feb 19 19:54:27 MST 2013
Looks like a pointer error :eek:
Something like:
//    DS_ROM_Type**  pDsArr = 0;                            //pointer na pole pointerov na struktuy
   [COLOR=Red] DS_ROM_Type* [COLOR=Black] pDsArr; [/COLOR]   [/COLOR]                        //pointer na pole pointerov na struktuy

    DS_ROM_Type *aDsTemp;


    for(i=0;i<64;i++)    conflict = 0;                //flagy pre konflikty v ROM adrese
//alloc memory for 4 pointers to device struct and return pinter to it
    //pDsArr = (DS_ROM_Type**) malloc( (idDev+4)*sizeof(DS_ROM_Type*));
    pDsArr = ([COLOR=Red]DS_ROM_Type*[/COLOR]) malloc( (idDev+4)*sizeof(DS_ROM_Type*));
    pDsArr->device =0x11111111;
    pDsArr++;
    pDsArr->device =0x22222222;
    pDsArr++;
    pDsArr->device =0x33333333;
is looking more familiar to me and is working (Memory view shows structured data)
0 Kudos
Reply

4,724 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by saimot on Tue Feb 19 18:34:25 MST 2013
Problem  even in debugging is that when the problem began I deleted parts that I have recently added and brought code to state as before error. However even then the error remained!

Also there was no difference between allocating memory in main or in function. The behavior is strange and Im unable to determine adding which core starts it.

Here is my code. It is based on demo application for LPCXpresso.
0 Kudos
Reply

4,724 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by Ex-Zero on Tue Feb 19 16:45:52 MST 2013
Your picture doesn't look too unusual :eek: Could be useful to reduce your project to the problem and export/post it :)
0 Kudos
Reply

4,724 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by saimot on Tue Feb 19 16:08:47 MST 2013
Hi, I have now similar problem. Program jumps to HardFault_Handler when calling malloc() function. This is first call of allocation in program and it is in main(). Before I call just some peripherial inits. Call is falling immediately. Picture should explain more.

[IMG][IMG]http://img856.imageshack.us/img856/5115/lpc3.png[/IMG] Uploaded with ImageShack.us[/IMG]

Could Stack be the reason? My program is really small and this call is on the begining.
0 Kudos
Reply

4,724 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by CodeRedSupport on Wed Jul 28 01:06:22 MST 2010
That is a problem in your code - not with our tools.
0 Kudos
Reply

4,724 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by karthik.s on Tue Jul 27 23:56:46 MST 2010
Also i noticed that very frequently the code is stuck at SPI receive at the following statement.However,this doesn't cause any hard faults but the code is stuck.

while ( (LPC_SSP->SR & (SSPSR_BSY|SSPSR_RNE)) != SSPSR_RNE );
0 Kudos
Reply

4,724 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by karthik.s on Tue Jul 27 23:50:18 MST 2010
I registered yesterday at the support link that you provided.Waiting for the reply.

Currently i am using Build id: LPCXpresso v3.4.0 [Build 187] [23/06/2010] .
0 Kudos
Reply

4,724 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by CodeRedSupport on Tue Jul 27 23:39:07 MST 2010
The most likely cause is that the stack has been corrupted and thus a function return uses an incorrect return address. If this is the case, you are likely to see random errors/crashes.

As mention in my previous post, can you please contact us directly. We would have a beta release of a new version that we would like yo to try to see if it resolves your problem.
0 Kudos
Reply

4,724 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by karthik.s on Tue Jul 27 22:48:56 MST 2010
Why does the VECTPC point to an unknown location such as 0x20000000 and thereby cause a hardfault error?
0 Kudos
Reply

4,724 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by CodeRedSupport on Tue Jul 27 05:19:26 MST 2010
Could you contact our support group. Please use the link on this page:
http://www.code-red-tech.com/contact.php

Thanks
0 Kudos
Reply

4,724 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by karthik.s on Tue Jul 27 01:51:35 MST 2010
As soon as i run the program,this error occurs after few seconds.Basically here is what i am doing.

I am sending few bytes to the remote PC over WLAN and receiving them back from the remote PC to the microcontroller over WLAN.So,whenever the data is being received,it is stored in a buffer which is created dynamically using malloc.I am freeing up the dynamic memory location after reading the data from the buffer.

I am not able to find any clue to reduce the stack consumption so that it doesn't overlap with heap.Suggest me some coding tips to reduce stack consumption in the microcontrollers memory.
0 Kudos
Reply

4,724 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by CodeRedSupport on Tue Jul 27 00:02:10 MST 2010
The VECTPC is a pseudo-register (it doesn't really exist in the core) that shows the PC that caused the fault. If you want to understand the Cortex-M3 exception model and the meaning of the registers, see the Cortex-M3 Architecture Reference Manual, which is available from NXP or ARM.

It looks like it is failing in the C runtime malloc(), but this is likely to be caused by stack/heap corruption. Is the call failing immediately, or after some time? Can you produce a cutdown example?

NXP have written an example on how to monitor stack usage. See:
http://ics.nxp.com/support/lpcxpresso/zip/examples.stack.usage.lpc17xx.zip
0 Kudos
Reply

4,724 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by karthik.s on Mon Jul 26 21:01:20 MST 2010
@CodeRedSupport :On harld fault error,in the core registers view ,two registers were marked in red.One is "VECTPC" which showed "0x542c(21548) malloc+64 in section.text".The other is "CFSR" which showed "0x0 (0) g_pfnVectors in section.text".Please help me understand each of those register's status.

Also,please tell me how to check if the stack and heap memory have overalapped.

@micronpn: How and where to define memory range for heap?Please let me know.
0 Kudos
Reply

4,724 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by micronpn on Mon Jul 26 10:09:20 MST 2010
In my opinion this is a library problem. It could be better define a memory range for the heap to don't overflow (malloc calloc etc. can return the error return code) so only the stack may corrupt the heap and not the viceversa.
0 Kudos
Reply

4,724 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by CodeRedSupport on Mon Jul 26 06:17:59 MST 2010
I made 3 points in my, you only commented on the 2nd. To repeat the others:

  When the HardFault occurs, the Core Registers view will show some  additional information to help determine the cause of the Fault. e.g.  VECTPC will show the PC that caused the fault, and the tooltip will show  where that is in your code. Look at this to help you determine where your code has gone wrong.

Also, note that the heap and the stack share memory.
- The heap starts at the end of your RAM data and grows 'up' (larger  addresses)
- The stack starts as the top of RAM and grows 'down (small addresses)
There is no stack checking, so the two can grow to overwrite each other.  So one possibility is that this has happened.
0 Kudos
Reply