Strange GDB behaviour with Cortex-M3

Rainer Guest 2012-06-21 18:41 #2725689

Rate this post

•	▲ useful ▼ not useful

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

Attached files:

openocd.zip (16.9 KB)

Reply Quote Edit Move Thread sperren Anmeldepflicht aktivieren Anpinnen Delete topic Thread mit anderem zusammenführen Report post

MacLyon Guest 2012-06-23 07:22 #2727462

Rate this post

•	▲ useful ▼ not useful

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

Reply Quote Edit Delete Report post

frame Guest 2012-06-24 20:08 #2729097

Rate this post

•	▲ useful ▼ not useful

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.

Reply Quote Edit Delete Report post

Rainer Guest 2012-06-25 09:09 #2729450

Rate this post

•	▲ useful ▼ not useful

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

Reply Quote Edit Delete Report post

loketak Guest 2012-10-25 05:31 #2886793

Rate this post

•	▲ useful ▼ not useful

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.

Reply Quote Edit Delete Report post

MacLyon Guest 2012-10-25 21:44 #2888059

Rate this post

•	▲ useful ▼ not useful

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

Reply Quote Edit Delete Report post