Debuggin problem

[planeetmaa]

Posted on June 20, 2006 at 15:37

Debuggin problem

[planeetmaa]

Posted on June 20, 2006 at 09:16

Hi all!

My ST board has got really strange behavoiour. Maybe you can suggest me something, I have no glue from where to dig.

Firstly, Im using:

eclipse 3.1.2

CDT 3.0.2

arm-elf-gcc 4.0.2

arm-elf-gdb 6.4.0

openocd rev 62

selfmade usb dongle (FTDI chip, usbjtag)

While debugging the code, somehing really strange happens to function calls. If Im stepping in assembler (tried insight and eclipse both over the openocd) everything seems to be ok. But If I step in C, first three lines of the target fuction (three lines in asm) are skipped. But as these three lines modify sp to make room for local variables, target function ruins the stack and local variables for host function (as last three lines where sp is modified back are excecuted just normally). So after the target function exits, sp is changed (and all the local variables) and everything crashes.

My question is, how come is it possible that everything works while stepping in asm? I guess core has to excecute the instructions loaded into ram the same way no matter if I step in asm or C? Just has to stop in different place? Otherwise I could consider it a ''debugger bug'' and live with it, but it seems that same thing sometimes happen while core is ''free running''. I.e. it gets abort. And why it is skipping exactly three lines...?

asm looks like the following:

0x00002330 : ldr r3, [pc, #84] ; 0x238c

0x00002334 : ldr r3, [r3]

0x00002338 : add r2, sp, #3 ; 0x3

0x0000233c : mov r0, r3

0x00002340 : mov r1, r2

0x00002344 : bl 0x2b7c

and UART_ByteSend entry:

0x00002b7c : sub sp, sp, #8 ; 0x8 <---ASM jups to here

0x00002b80 : str r0, [sp, #4]

0x00002b84 : str r1, [sp]

/* if FIFO ENABLED */

if (UARTx->CR & 0x0400)

0x00002b88 : ldr r3, [sp, #4] <----C jups to here

0x00002b8c : ldrh r3, [r3, #12]

0x00002b90 : mov r3, r3, lsl #16

0x00002b94 : mov r3, r3, lsr #16

If I monitor the sp, stepping in C really seems to skip first three lines as sp remains unchanged...

Any advice? Thank you.

Madis

[sjo]

Posted on June 20, 2006 at 11:29

I would guess your code has been built with gcc optimisation on (eg. -O2), this will cause problems with debugging in gdb/insight.

The code will be executing ok but the debugger cannot match line numbers etc.

As a test turn off any optimisation.

This should not be as bad as pre gcc4 as gcc now uses location lists as the default.

Regards

sjo

[planeetmaa]

Posted on June 20, 2006 at 11:37

Thanks for your reply,

I checked all the makefiles, I have -O0 specified in every of them. I did it once (debugging optimised code) then the code was really excecuting ok but debugger jumped around the source file. But as the result, optimised code was excecuting ok, as you said.

But this time I have no optimisation. And as I pointed out:

0x00002b7c : sub sp, sp, #8 ; 0x8 <---ASM jups to here

0x00002b80 : str r0, [sp, #4]

0x00002b84 : str r1, [sp]

these three lines are skipped while stepping in C as sp remains unchanged (sub sp, sp, #8) not excecuted. Im really stuck here...

BR, Madis

[sjo]

Posted on June 20, 2006 at 11:42

I do not use eclipse as i find it harder than insight to debug. Try using insight.

Is you application working ok ?

Regards

sjo

[planeetmaa]

Posted on June 20, 2006 at 11:59

Hi,

I tried it with both insight and eclipse (loaded the elf file to insight and used the insight to load it to target ram). But the result is exactly the same, unfortunatelly... And I used two separate boards: original board designed for that project (STR710) and IAR sample board (STR711)...

Br, Madis

[planeetmaa]

Posted on June 20, 2006 at 13:17

one strange thing I noticed:

If I dont excecute EIC_IRQConfig(ENABLE); (dont enable EIC global bit, function taken from the ST website), i.e. no interrupt can occour, problem dissapears...

But in every interrupt function (all written directly in asm) I have:

sub lr, lr, #4

stmdb sp!,{r0-r12,lr} /*save content*/

in the beginning, and

ldmia sp!, {r0-r12,pc}^ /*restore content*/

in the end. So it should not ruin the stack no matter how many interrupts occour...? IVR is read direcly as I have:

ldr pc,[pc,#-0x808]

in place of IRQ vector. And pending bit (EIC and peripheral) clearing should be fine too... Any commants...?

BR, Madis

[sjo]

Posted on June 20, 2006 at 13:54

Sounds like you need to double check your irq handlers.

Regards

sjo

[planeetmaa]

Posted on June 20, 2006 at 14:08

Yes,

Im debugging these functions at the moment.

it seems to be that only the sub sp, sp, #0x08 is skipped after returing from the interrupt. And it seems to be that debugger allows (insight and eclipse) processor to king of ''free run'' in case of C function call. Inerrupt occours and it returs one step too far. Sp remains unmodified somehow...

BR, Madis

[planeetmaa]

Posted on June 20, 2006 at 14:59

But dont you agree with me, that having

sub lr, lr, #4

stmdb sp!,{r0-r12,lr} /*save content*/

ISR code

ldmia sp!, {r0-r12,pc}^ /*restore content*/

in the ISR function prevents ISR to change/modify/prevent system mode from modifying the sustem mode sp? As sp is banked in IRQ mode... I just dont understand why the sub sp instuction is skipped after IRQ (sub lr. lr, #4 should return to correct address...?). So after restoring content in ISR pc has to return to correct place without skipping anything. But thats the situation I just have, one instruction seems to be skipped and system mode stack gets corrupted. Tried also openocd rev59 instead of 62 with no success...

BR, Madis

[planeetmaa]

Posted on June 20, 2006 at 15:37

ok,

problem solved. Once again, the problem was situated between the monitor and the chair (and it was not the target board):-)

Just to let everybody know, there was a bug in interrupt handler registration:

sub lr, lr, #4

got never excecuted and one instruction got skipped on return. Handler was rigistrated +4 too far.

Thanks for your effort,

Madis