help ! memcpy causes hardfault

Posted on December 11, 2012 at 08:34

It stops at the breakpoint just before the memcpy function

 

however when I rerun from this point

 

it ends up at hardfault handler as shown below

 

 

Of course it does. It does not make a difference if you made an intermediate stop.

 

please advice how can I proceed ?

 

Step into the memcpy function.

Check that both source and target are proper locations in RAM, and that size does not exceed your bufffer size. It would be a ggod idea to check this before calling memcpy(), at least in the development phase.

Your hardfault might well be caused by a stack overflow. Check that your stacksize can handle the buffers you define.

Posted on December 11, 2012 at 17:07

You should sanity check the parameters passed to memcpy(), if the addresses start off pointing to illegal locations, of if the size is excessive it will cause a fault when the bad addresses are hit.

Suggest also you use a better Hard Fault Handler, like the one documented by Joseph Yiu, which will give some better ideas about the exact location, and register settings surrounding the fault.

Posted on December 12, 2012 at 09:51

You should have a look at your dissassembly generated.

If you use opt level 1, and if you use memcopy for <= 8 Bytes, then possibly memcpy will NOT be invoked, but a LDR / STR sequence, which of course is much faster - Keil compiler really is very smart. (I am not sure if Keil even would do this already at opt level 0 - I never use opt level 0).

Depending on your basic CortexM Core settings (usually in stm32f4xx-startup.s), hardfault will be generated on half-word (16bit) address or not (ARM has possibility to support 16-bit access for certain operations like LDR and STR - check the ARM v7m TRM A3.2 ''Alignment behaviour'') . If you do not want half-word access, you have to tell the compiler (compiler switch --no_unaligned_access in Keil).

Posted on December 12, 2012 at 13:52

If you use opt level 1, and if you use memcopy for <= 8 Bytes, then possibly memcpy will NOT be invoked, but a LDR / STR sequence, which of course is much faster - Keil compiler really is very smart. (I am not sure if Keil even would do this already at opt level 0 - I never use opt level 0).

That type of optimization only occurs when size is a constant. On ARM7/9 parts memcpy() was frequently used when unaligned memory accesses would fault. So memcpy was used in place of casted pointer accesses used on most other platforms.

Posted on December 12, 2012 at 14:31

hello forum thank you for the answers

when I tried to compile the project it compiles however

it gives following warning

can it have something to do with the above mentioned hardfault error ?

Posted on December 12, 2012 at 14:45

If you want to define aligned data, you can also use the following define:

#define ALIGN4 __attribute((aligned(4)))

char c ALIGN4;

char ac[3] ALIGN4;

Then c and ac[0] will be address aligned on 4-byte.

Posted on December 12, 2012 at 15:12

If you want to define aligned data, you can also use the following define:

 

#define ALIGN4 __attribute((aligned(4)))

 

You should add that #pragmas in general are compiler-dependant.

They are reserved by the C standard for exactly such implementation-dependant settings.

The 'offending' code was probably implementing using another toolchain. When reading of Olimex, I guess it was IAR.

__attribute is the usual gcc method.

Posted on December 16, 2012 at 19:05

hello  forum,

I made a trap in my code and see where the code hangs ( hardfault handler )

as you can see in the picture

the code was at the memcpy function just before the hardfault handler becouse the trackerr stops at  value 10

I set other variables to see what the dest, source and size variables value are just before the

memcpy was called

lastly I set a scan variable which counts the scan count at the time of where the code hangs

this scan count takes different values like 0x95a85 , 0xb7eaa , 0x423e each time I run the code from the start

it last about 1- 2 sec before the code hangs - as you can see I set a blink led ( 1 Hz )

in the infinite loop - I see only blinking 2 - 3 times before the led freezes 

what do you suggest me to look at ? 

thank you

 

Posted on December 16, 2012 at 21:23

what do you suggest me to look at ?

Well obviously you should perhaps start by looking at the uip_buf, how big it is, and how it's situation with respect to the stack.

You should be looking at the processor registers, and disassembly of the code that is actually faulting. This might at least allow you to see if the fault is due to the copy, or that the LR or stack are being compromised. Until you know exactly what the processor state is you're going to keep drowning.

Get a precise idea of what's wrong, and work backward. Ask yourself how the system arrived at the condition, and what code it travelled through to get there.

Posted on December 18, 2012 at 22:36

The original post was too long to process during our migration. Please click on the provided URL to read the original post. https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006I6cB&d=%2Fa%2F0X0000000brq%2FgK3RcuemLbz74rV.n4LI5dj.K02IfByU_BxYF96vPNY&asPdf=false