2012-12-10 01:37 PM
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){
}
}
2012-12-10 11:34 PM
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.
2012-12-11 08:07 AM
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.2012-12-12 12:51 AM
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).2012-12-12 04:52 AM
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.2012-12-12 05:31 AM
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 ?2012-12-12 05:45 AM
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.2012-12-12 06:12 AM
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.
2012-12-16 10:05 AM
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 you2012-12-16 12:23 PM
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.