help ! memcpy causes hardfault

[mehmet.karakaya]

Posted on December 10, 2012 at 22:37

hello forum ,

I am trying to run a TCP/IP demo on a Olimex STM32F4 board with eclipse + yagarto however I cannot connect to the board with LAN when I stop the demo with JTAG to look where it hangs it shows below code I tried to set up breakpoint before the memcpy function as shown in the attached picture 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 please advice how can I proceed ? void

HardFault_Handler(

void

)

{

/* Go to infinite loop when Hard Fault exception occurs */

while

(1)

{

}

}

#stm32f4-memcpy-hardfault #makefile #memcpy-hardfault-stm32f4 #linkerscript

[frankmeyer9]

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.

[Tesla DeLorean]

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.

[flyer31]

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

[Tesla DeLorean]

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.

[mehmet.karakaya]

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 ?

[flyer31]

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.

[frankmeyer9]

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.

[mehmet.karakaya]

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  

[Tesla DeLorean]

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.