LPCXpresso IDE中的主题 Re: LPC1114 hard fault issue

LPC1114 hard fault issue

lpcware — Wed, 15 Jun 2016 22:06:52 GMT

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.

Re: LPC1114 hard fault issue

lpcware — Wed, 15 Jun 2016 22:06:53 GMT

Content originally posted in LPCWare by CodeRedSupport on Mon Jul 26 04:42:25 MST 2010
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.,

You don't say where you are calling RSI_user_malloc. Is it before main()? If so, that could be a problem as the C library has not been initialised at that point.

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.

Re: LPC1114 hard fault issue

lpcware — Wed, 15 Jun 2016 22:06:54 GMT

Content originally posted in LPCWare by karthik.s on Mon Jul 26 04:51:03 MST 2010
I called RSI_user_malloc() after main().

Re: LPC1114 hard fault issue

lpcware — Wed, 15 Jun 2016 22:06:54 GMT

Content originally posted in LPCWare by CodeRedSupport on Mon Jul 26 05:13:15 MST 2010
That was one point out of three...

Re: LPC1114 hard fault issue

lpcware — Wed, 15 Jun 2016 22:06:55 GMT

Content originally posted in LPCWare by karthik.s on Mon Jul 26 05:48:02 MST 2010
Can you please elaborate?

Basically what i meant was RSI_user_malloc() is called within the main() funtion.

Re: LPC1114 hard fault issue

lpcware — Wed, 15 Jun 2016 22:06:55 GMT

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.

Re: LPC1114 hard fault issue

lpcware — Wed, 15 Jun 2016 22:06:56 GMT

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.

Re: LPC1114 hard fault issue

lpcware — Wed, 15 Jun 2016 22:06:56 GMT

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.

Re: LPC1114 hard fault issue

lpcware — Wed, 15 Jun 2016 22:06:57 GMT

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

Re: LPC1114 hard fault issue

lpcware — Wed, 15 Jun 2016 22:06:58 GMT

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.

Re: LPC1114 hard fault issue

lpcware — Wed, 15 Jun 2016 22:06:58 GMT

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

Re: LPC1114 hard fault issue

lpcware — Wed, 15 Jun 2016 22:06:59 GMT

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?

Re: LPC1114 hard fault issue

lpcware — Wed, 15 Jun 2016 22:06:59 GMT

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.

Re: LPC1114 hard fault issue

lpcware — Wed, 15 Jun 2016 22:07:00 GMT

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

Re: LPC1114 hard fault issue

lpcware — Wed, 15 Jun 2016 22:07:01 GMT

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

Re: LPC1114 hard fault issue

lpcware — Wed, 15 Jun 2016 22:07:01 GMT

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.

Re: LPC1114 hard fault issue

lpcware — Wed, 15 Jun 2016 22:07:02 GMT

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.

Re: LPC1114 hard fault issue

lpcware — Wed, 15 Jun 2016 22:07:03 GMT

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

Re: LPC1114 hard fault issue

lpcware — Wed, 15 Jun 2016 22:07:03 GMT

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.

Re: LPC1114 hard fault issue

lpcware — Wed, 15 Jun 2016 22:07:04 GMT

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)