Hard Fault exception when incrementing pointer address?

[patrickbrataas9]

Posted on January 30, 2013 at 00:33

Hello!

I am making a GUI application on a touchscreen with STM32 F103VC. I have a problem with one of the funtions in the STM32 GUI library. When stepping through my program when debugging, the line to be executed next is: CursorBehindPointer++; But when it does I get thrown to the hard fault exception handler and I can see from my variables window that CursorBehindPointer get this error message: ''CursorBehindPointer'' <error(s)_during_the_evaluation> Target request failed: -var-create: unable to create variable object. From the code within the function:

uint16_t* CursorBehindPointer;
....
CursorBehindPointer = Cursor->BehindCursor; 
//Debugger variable window shows that they get the same value and points to the same address.
.....
if
(Temp & Mask)
{
/*Read pixel which is going to be behind cursor*/
*CursorBehindPointer = LCD_GetPixel(X + tmpX, Y + tmpY);
CursorBehindPointer++;
}

And BehindCursor in Cursor struct is a uint16_t* as well. Is there anyting illegal going on here? The file is from the ST GUI Library and should work? I have never had a hard fault exception before and don't know much about how to solve these nasty errors. Any help on where to find information on how to solve this or if you can provide some help yourself would be much appreciated. #hard-fault-pointer-stm32f103

[Tesla DeLorean]

Posted on January 30, 2013 at 00:51

I'd hazard that

LCD_GetPixel

is evaluated to an address beyond the region it should. You want to be looking at the assembler code and registers at the faulting address (placed on a stack context in handler), the high level abstraction masks too much of the underlying function. There are a couple of things which will cause a Hard Fault, most are read/write access to memory that isn't present, or attempts to execute 32-bit ARM instructions.

[patrickbrataas9]

Posted on January 30, 2013 at 23:47

Thanks for the answer clive1!

I have investigated LCD_GetPixel(), but according to the disassembly it does not crash within this function. Below you can see what the disassembly code looks like. I use GNU ARM 4.7 with CooCox CoIDE.

318 *CursorBehindPointer = LCD_GetPixel(X + tmpX, Y + tmpY);
080039ba: ldrb r3, [r7, #23]
080039bc: uxth r2, r3
080039be: ldrh r3, [r7, #6]
080039c0: adds r3, r2, r3
080039c2: uxth r2, r3
080039c4: ldrb r3, [r7, #22]
080039c6: uxth r1, r3
080039c8: ldrh r3, [r7, #4]
080039ca: adds r3, r1, r3
080039cc: uxth r3, r3
080039ce: mov r0, r2
080039d0: mov r1, r3
080039d2: bl 0x800285c <
LCD_GetPixel
>
080039d6: mov r3, r0
080039d8: mov r2, r3
080039da: ldr r3, [r7, #12]
080039dc: strh r2, [r3, #0]
319 CursorBehindPointer++;
080039de: ldr r3, [r7, #12] //This one fails!
080039e0: add.w r3, r3, #2
080039e4: str r3, [r7, #12]
322 Mask >>= 1;
080039e6: ldrb r3, [r7, #21]
080039e8: mov.w r3, r3, lsr #1
080039ec: strb r3, [r7, #21]
305 for (tmpX = 0x00 ; tmpX < 
CursorHeader-
>Width; tmpX++)
080039ee: ldrb r3, [r7, #23]
080039f0: add.w r3, r3, #1
080039f4: strb r3, [r7, #23]
080039f6: ldr r3, [r7, #8]
080039f8: ldrb r3, [r3, #0]
080039fa: ldrb r2, [r7, #23]
080039fc: cmp r2, r3
080039fe: bcc.n 0x8003994 <
CursorDraw
+320>
Jumps to:
HardFault_Handler:
080088b0: push {r7}
080088b2: add r7, sp, #0
62 } //Jumps to this line!
080088b4: b.n 0x80088b4 <
HardFault_Handler
+4>
71 {

I basically do not know assembly. Atleast I do not have any real experience with it. Any obvious errors from the disassembly? From what I understand from the instruction set for the cortex M3 the assembly line failing are to copy some register offset by a value (12 in this case) to some other register. So this might be some reference to a memory location not exsisting/allowed to access?

[Tesla DeLorean]

Posted on January 31, 2013 at 00:35

So what are the contents of registers R3 and R7?

I don't think it's the increment that is failing, as it just used R7+12 correctly, it's the preceding pointer write at R3+0 that is out of scope. You should range check that. ie

CursorBehindPointer

and by inference

Cursor->BehindPointer

are bogus.