Hi all, I am observing a strange behaviour here. I am debugging a LM3S6753 with CodeSourcery Tools and Eclipse. I just updated to latest CodeSourcery with GDB 4.6.3, by the way. I have a FreeRTOS project and stripped it down to something rather simple with a malloc call. I am stopping at this code 184 if( ( xWantedSize > 0 ) && ( xWantedSize < configTOTAL_HEAP_SIZE ) ) 000038a8: pvPortMalloc+120 ldr r3, [r7, #4] 000038aa: pvPortMalloc+122 cmp r3, #0 000038ac: pvPortMalloc+124 beq.n 0x3964 <pvPortMalloc+308> 000038ae: pvPortMalloc+126 ldr r2, [r7, #4] 000038b0: pvPortMalloc+128 movw r3, #11999 ; 0x2edf 000038b4: pvPortMalloc+132 cmp r2, r3 000038b6: pvPortMalloc+134 bhi.n 0x3964 <pvPortMalloc+308> 188 pxPreviousBlock = &xStart; and switch to Instruction stepping mode The register contents are General Registers General Purpose and FPU Register Group r0 0x40 r1 0x4 r2 0x40 r3 0x0 r4 0x18d3672f r5 0x1 r6 0xa4b r7 0x200035ec r8 0x1c003812 r9 0xc9002302 r10 0xa6941002 r11 0xd129840c r12 0x36e10541 sp 0x200035ec lr 0x3cf3 pc 0x3d95 f0 0x0 f1 0x0 f2 0x0 f3 0x0 f4 0x0 f5 0x0 f6 0x0 f7 0x0 fps 0x0 cpsr 0x61000020 I can execute the first ldr r3... command, I see r3 updated with the correct value, but when I execute the next step command (cmp r3 ...), the processor gives me a hard fault and gets caught in the FaultISR handler. I can't see any reason, why a cmp r3, #0 command would cause this. When I stop the processor now, the register contents are General Registers General Purpose and FPU Register Group r0 0x0 r1 0x4 r2 0x40f0 r3 0x0 r4 0x18d3672f r5 0x1 r6 0xa4b r7 0x20001b08 r8 0x1c003812 r9 0xc9002302 r10 0xa6941002 r11 0xd129840c r12 0x36e10541 sp 0x2000360c lr 0xfffffff9 pc 0x3f41 f0 0x0 f1 0x0 f2 0x0 f3 0x0 f4 0x0 f5 0x0 f6 0x0 f7 0x0 fps 0x0 cpsr 0x21000023 I attach the openocd log for this session. The error seems to be here Debug: 1692 50691 cortex_m3.c:404 cortex_m3_examine_exception_reason(): HardFault SHCSR 0x0, SR 0x40000000, CFSR 0x1, AR 0xffffffff Debug: 1693 50691 cortex_m3.c:515 cortex_m3_debug_entry(): entered debug state in core mode: Handler at PC 0x3f40, target->state: halted Any ideas what might go wrong here? Best regards, Rainer
Hi, Good to have CFSR content - for me it says the bug is shown in the low byte of CFSR (=MFSR register). Since you have bit 0 of MFSR set to 1, this means "Violation to memory access protection" according to ARM documentation. This generic message can have four possible causes: a) branch to non-executable regions b) invalid exception return code c) invalid entry in exception vector code d) stacked PC corrupted during exception handling. Applying these to your case seems to correspond to a) and this can be caused by a non-initialized memory region - this means you failed somehow to init your heap memory. On TI site you have a document describing in more detail the powerful Fail mechanism in Cortex-M3 microcontrollers. Regards, MacLyon
Additionally, the instruction pipelining may come into play, and the hard fault actually belongs to the branch instruction. That would make more sense - at least to me.
Thanks for your replies it must be an issue with GDB or OpenOCD. When I do some old fashioned debugging (blinking LEDs) and just upload and execute the code, it runs fine. After I had found that, I tried to avoid debugging with breakpoints where possible. There still were situations where I had to use a debugger. I experienced other cases, where I just stopped at a breakpoint inbetween, continued executing the code afterwards (no single stepping) and got FaultISRs. Uploading and running the program also worked fine in this case. I used OpenOCD 0.5.0 and also the latest development version 0.6.0 Best regards, Rainer
Now I encounter the same problem with STM32F107. I cope with this problem by removing breakpoint after reach these particular breakpoint, but this is not solution.
Hi, To get benefit of the powerful fault mechanism in ARM/Cortex it it useful to look at the following registers when in fault: CFSR, HFSR, DFSR, MMAR, BFAR, AFSR. Just copy and post them and I will try to help you. MacLyon
Watch this topic
Disable multi-page viewPlease log in before posting. Registration is free and takes only a minute.
Existing account
Do you have a Google/GoogleMail account? No registration required!
Log in with Google account
Log in with Google account
No account? Register here.